AgeCommit message (Collapse)AuthorFilesLines
39 hoursMerge tag 'drm-intel-fixes-2020-10-29' of ↵drm-fixes-2020-10-30-1drm-fixesDave Airlie5-2/+84
git:// into drm-fixes - Fix max memory region size calculation (Matt) - Restore ILK-M RPS support, restoring performance (Ville) - Reject 90/270 degreerotated initial fbs (Ville) Signed-off-by: Dave Airlie <> From: Rodrigo Vivi <> Link:
41 hoursMerge branch 'linux-5.10' of git:// into drm-fixesdrm-fixes-2020-10-30Dave Airlie11-68/+145
Fixes an endian regression on older GPUs, a refcount overflow, a migration fix and 3 display fixes. Signed-off-by: Dave Airlie <> From: Ben Skeggs <> Link:
42 hoursMerge tag 'drm-misc-fixes-2020-10-29' of ↵Dave Airlie16-64/+82
git:// into drm-fixes First round of drm-misc-fixes with a couple of leftovers from drm-misc-fixes next. Some reset fixes for the mantix panel, some fixes for a scaler issue on sun4i, many kernel-doc fixes and various fixes for vc4 (mostly HDMI audio related) Signed-off-by: Dave Airlie <> From: Maxime Ripard <> Link:
42 hoursdrm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()Lyude Paul1-10/+11
While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max data rate supported by the DP encoder. So, limiting it to the output of ds_clock (which refers to the maximum dotclock of the downstream DP device) doesn't make any sense. Additionally, since we're using the connector's bpc as the canonical BPC we should use this in mode_valid until we support dynamically setting the bpp based on bandwidth constraints. For more info. So, let's rewrite this using Ville's advice. v2: * Ville pointed out I mixed up the dotclock and the link rate. So fix that... * ...and also rename all the variables in this function to be more appropriately labeled so I stop mixing them up. * Reuse the bpp from the connector for now until we have dynamic bpp selection. * Use use DIV_ROUND_UP for calculating the mode rate like i915 does, which we should also have been doing from the start Signed-off-by: Lyude Paul <> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation") Cc: Ville Syrjälä <> Cc: Lyude Paul <> Cc: Ben Skeggs <> Signed-off-by: Ben Skeggs <>
42 hoursdrm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()Lyude Paul2-31/+21
Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place. Signed-off-by: Lyude Paul <> Fixes: d6a9efece724 ("drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST") Cc: Ville Syrjälä <> Cc: <> # v5.8+ Signed-off-by: Ben Skeggs <>
42 hoursdrm/nouveau/device: fix changing endianess code to work on older GPUsKarol Herbst1-13/+26
With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") Signed-off-by: Karol Herbst <> Cc: <> # v5.8+ Signed-off-by: Ben Skeggs <>
42 hoursdrm/nouveau/gem: fix "refcount_t: underflow; use-after-free"Karol Herbst1-1/+2
we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <> Signed-off-by: Ben Skeggs <>
42 hoursdrm/nouveau/kms/nv50-: Program notifier offset before requesting disp capsLyude Paul6-5/+85
Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier offset programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix this by doing that, and also perform an update afterwards to prevent racing with the GPU when reading capabilities. v2: * Don't just program the DMA notifier offset, make sure to actually perform an update v3: * Don't call UPDATE() * Actually read the correct notifier fields, as apparently the CAPABILITIES_DONE field lives in a different location than the main NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different CAPABILITIES_DONE field then pre-907d cards. v4: * Don't forget to check the return value of core507d_read_caps() v5: * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY * Disable notifier after calling GetCapabilities() Signed-off-by: Lyude Paul <> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support") Cc: <> # v5.8+ Signed-off-by: Ben Skeggs <>
42 hoursdrm/nouveau/nouveau: fix the start/end range for migrationRalph Campbell1-11/+3
The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <> Signed-off-by: Ben Skeggs <>
42 hoursMerge tag 'amd-drm-fixes-5.10-2020-10-29' of ↵Dave Airlie13-76/+69
git:// into drm-fixes amd-drm-fixes-5.10-2020-10-29: amdgpu: - Add new navi1x PCI ID - GPUVM reserved area fixes - Misc display fixes - Fix bad interactions between display code and CONFIG_KGDB - Fixes for SMU manual fan control and i2c Signed-off-by: Dave Airlie <> From: Alex Deucher <> Link:
47 hoursdrm/i915: Reject 90/270 degree rotated initial fbsVille Syrjälä1-0/+4
We don't currently handle the initial fb readout correctly for 90/270 degree rotated scanout. Reject it. Cc: Signed-off-by: Ville Syrjälä <> Link: Reviewed-by: Chris Wilson <> (cherry picked from commit a40a8305a732f4ecc2186ac7ca132ba062ed770d) Signed-off-by: Rodrigo Vivi <>
47 hoursdrm/i915: Restore ILK-M RPS supportVille Syrjälä1-0/+1
Restore RPS for ILK-M. We lost it when an extra HAS_RPS() check appeared in intel_rps_enable(). Unfortunaltey this just makes the performance worse on my ILK because intel_ips insists on limiting the GPU freq to the minimum. If we don't do the RPS init then intel_ips will not limit the frequency for whatever reason. Either it can't get at some required information and thus makes wrong decisions, or we mess up some weights/etc. and cause it to make the wrong decisions when RPS init has been done, or the entire thing is just wrong. Would require a bunch of reverse engineering to figure out what's going on. Cc: Cc: Chris Wilson <> Fixes: 9c878557b1eb ("drm/i915/gt: Use the RPM config register to determine clk frequencies") Signed-off-by: Ville Syrjälä <> Link: Reviewed-by: Chris Wilson <> (cherry picked from commit 2bf06370bcfb0dea5655e9a5ad460c7f7dca7739) Signed-off-by: Rodrigo Vivi <>
47 hoursdrm/i915/region: fix max size calculationMatthew Auld3-2/+79
We are incorrectly limiting the max allocation size as per the mm max_order, which is effectively the largest power-of-two that we can fit in the region size. However, it's normal to setup the region or allocator with a non-power-of-two size(for example 3G), which we should already handle correctly, except it seems for the early too-big-check. v2: make sure we also exercise the I915_BO_ALLOC_CONTIGUOUS path, which is quite different, since for that we are actually limited by the largest power-of-two that we can fit within the region size. (Chris) Fixes: b908be543e44 ("drm/i915: support creating LMEM objects") Signed-off-by: Matthew Auld <> Cc: Chris Wilson <> Cc: CQ Tang <> Reviewed-by: Chris Wilson <> Signed-off-by: Chris Wilson <> Link: (cherry picked from commit 83ebef47f8ebe320d5c5673db82f9903a4f40a69) Signed-off-by: Rodrigo Vivi <>
2 daysdrm/vc4: Rework the structure conversion functionsMaxime Ripard1-6/+6
Most of the helpers to retrieve vc4 structures from the DRM base structures rely on the fact that the first member of the vc4 structure is the DRM one and just cast the pointers between them. However, this is pretty fragile especially since there's no check to make sure that the DRM structure is indeed at the offset 0 in the structure, so let's use container_of to make it more robust. Signed-off-by: Maxime Ripard <> Reviewed-by: Dave Stevenson <> Link:
2 daysdrm/vc4: hdmi: Add a name to the codec DAI componentMaxime Ripard1-0/+1
Since the components for a given device in ASoC are identified by their name, it makes sense to add one even though it's not strictly necessary. Signed-off-by: Maxime Ripard <> Reviewed-by: Dave Stevenson <> Link:
3 daysdrm/shme-helpers: Fix dma_buf_mmap forwarding bugDaniel Vetter2-3/+8
When we forward an mmap to the dma_buf exporter, they get to own everything. Unfortunately drm_gem_mmap_obj() overwrote vma->vm_private_data after the driver callback, wreaking the exporter complete. This was noticed because vb2_common_vm_close blew up on mali gpu with panfrost after commit 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf"). Unfortunately drm_gem_mmap_obj also acquires a surplus reference that we need to drop in shmem helpers, which is a bit of a mislayer situation. Maybe the entire dma_buf_mmap forwarding should be pulled into core gem code. Note that the only two other drivers which forward mmap in their own code (etnaviv and exynos) get this somewhat right by overwriting the gem mmap code. But they seem to still have the leak. This might be a good excuse to move these drivers over to shmem helpers completely. Reviewed-by: Boris Brezillon <> Acked-by: Christian König <> Cc: Christian König <> Cc: Sumit Semwal <> Cc: Lucas Stach <> Cc: Russell King <> Cc: Christian Gmeiner <> Cc: Inki Dae <> Cc: Joonyoung Shim <> Cc: Seung-Woo Kim <> Cc: Kyungmin Park <> Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf") Cc: Boris Brezillon <> Cc: Thomas Zimmermann <> Cc: Gerd Hoffmann <> Cc: Rob Herring <> Cc: Cc: Cc: Cc: <> # v5.9+ Reported-and-tested-by: Cc: Signed-off-by: Daniel Vetter <> Link:
4 daysdrm/vc4: hdmi: Avoid sleeping in atomic contextMaxime Ripard1-2/+3
When running the trigger hook, ALSA by default will take a spinlock, and thus will run the trigger hook in atomic context. However, our HDMI driver will send the infoframes as part of the trigger hook, and part of that process is to wait for a bit to be cleared for up to 100ms. To be nicer to the system, that wait has some usleep_range that interact poorly with the atomic context. There's several ways we can fix this, but the more obvious one is to make ALSA take a mutex instead by setting the nonatomic flag on the DAI link. That doesn't work though, since now the cyclic callback installed by the dmaengine helpers in ALSA will take a mutex, while that callback is run by dmaengine's virt-chan code in a tasklet where sleeping is not allowed either. Given the delay we need to poll the bit for, changing the usleep_range for a udelay and keep running it from a context where interrupts are disabled is not really a good option either. However, we can move the infoframe setup code in the hw_params hook, like is usually done in other HDMI controllers, that isn't protected by a spinlock and thus where we can sleep. Infoframes will be sent on a regular basis anyway, and since hw_params is where the audio parameters that end up in the infoframes are setup, this also makes a bit more sense. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Suggested-by: Mark Brown <> Signed-off-by: Maxime Ripard <> Reviewed-by: Mark Brown <> Reviewed-by: Takashi Iwai <> Link:
4 daysdrm/amdgpu/pm: fix the fan speed in fan1_input in manual mode for navi1xAlex Deucher1-8/+3
It has been confirmed that the SMU metrics table should always reflect the current fan speed even in manual mode. Fixes: 3033e9f1c2de ("drm/amdgpu/swsmu: handle manual fan readback on SMU11") Reviewed-by: Evan Quan <> Signed-off-by: Alex Deucher <>
4 daysdrm/amd/pm: fix the wrong fan speed in fan1_inputKenneth Feng1-8/+3
fix the wrong fan speed in fan1_input when the fan control mode is manual. the fan speed value is not correct when we set manual mode to fan1_enalbe - 1. since the fan speed in the metrics table always reflects the real fan speed,we can fetch the fan speed for both auto and manual mode. Signed-off-by: Kenneth Feng <> Reviewed-by: Likun Gao <> Signed-off-by: Alex Deucher <>
4 daysdrm/amdgpu/swsmu: drop smu i2c bus on navi1xAlex Deucher1-25/+0
Stop registering the SMU i2c bus on navi1x. This leads to instability issues when userspace processes mess with the bus and also seems to cause display stability issues in some cases. Bug: Bug: Reviewed-by: Evan Quan <> Signed-off-by: Alex Deucher <> Cc:
4 daysdrm/vc4: drv: Add error handding for bindHoegeun Kwon1-0/+1
There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon <> Signed-off-by: Maxime Ripard <> Link:
4 daysdrm: drm_print.h: fix kernel-doc markupsMauro Carvalho Chehab1-3/+17
A kernel-doc markup should start with the identifier on its first line. Signed-off-by: Mauro Carvalho Chehab <> Signed-off-by: Daniel Vetter <> Link:
4 daysdrm: kernel-doc: drm_dp_helper.h: fix a typoMauro Carvalho Chehab1-1/+1
Right now, kernel-doc generates a warning: ./include/drm/drm_dp_helper.h:1786: warning: Function parameter or member 'hbr2_reset' not described in 'drm_dp_phy_test_params' This is due to a typo: @hb2_reset -> @hbr2_reset Signed-off-by: Mauro Carvalho Chehab <> Signed-off-by: Daniel Vetter <> Link:
4 daysdrm: kernel-doc: add description for a new function parameterMauro Carvalho Chehab1-0/+1
As reported by "make htmldocs": ./drivers/gpu/drm/drm_prime.c:808: warning: Function parameter or member 'dev' not described in 'drm_prime_pages_to_sg' Add a description for the new parameter. Fixes: 707d561f77b5 ("drm: allow limiting the scatter list size.") Signed-off-by: Mauro Carvalho Chehab <> Acked-by: Gerd Hoffmann <> Signed-off-by: Daniel Vetter <> Link:
4 daysdrm: drm_edid: remove a duplicated kernel-doc declarationMauro Carvalho Chehab1-7/+0
It is not possible to create cross-references for duplicated symbols. While Sphinx always detected it, on Sphinx 3 it generates warnings like this: .../Documentation/gpu/drm-kms-helpers:326: ../drivers/gpu/drm/drm_edid.c:1626: WARNING: Duplicate C declaration, also defined in 'gpu/drm-kms-helpers'. Declaration is 'bool drm_edid_are_equal (const struct edid *edid1, const struct edid *edid2)'. So, get rid of the duplicated kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <> Signed-off-by: Daniel Vetter <> Link:
4 daysdrm/dp: fix a kernel-doc issue at drm_edid.cMauro Carvalho Chehab1-1/+1
The name of the argument is different, causing those warnings: ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic' ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic' Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()") Reviewed-by: Lyude Paul <> Signed-off-by: Mauro Carvalho Chehab <> Signed-off-by: Daniel Vetter <> Link:
4 daysdrm/dp: fix kernel-doc warnings at drm_dp_helper.cMauro Carvalho Chehab1-0/+5
As warned by kernel-doc: ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or member 'type' not described in 'drm_dp_downstream_is_type' ./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or member 'dev' not described in 'drm_dp_downstream_mode' Some function parameters weren't documented. Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port types") Reviewed-by: Lyude Paul <> Signed-off-by: Mauro Carvalho Chehab <> Signed-off-by: Daniel Vetter <> Link:
4 daysdrm: kernel-doc: document drm_dp_set_subconnector_property() paramsMauro Carvalho Chehab1-1/+6
Changeset e5b92773287c ("drm: report dp downstream port type as a subconnector property") added a new function to the kAPI, but didn't add any documentation for the parameters for drm_dp_set_subconnector_property(). Fixes: e5b92773287c ("drm: report dp downstream port type as a subconnector property") Signed-off-by: Mauro Carvalho Chehab <> Signed-off-by: Daniel Vetter <> Link:
5 daysdrm/amd/display: Clean up debug macrosTakashi Iwai2-21/+13
This patch simplifies the ASSERT*() and BREAK_TO_DEBUGGER() macros: - Move the dependency check of CONFIG_KGDB into Kconfig - Unify the kgdb_breakpoint() call - Drop the non-existing CONFIG_HAVE_KGDB Also align the behavior of ASSERT() macro in both cases with and without CONFIG_DEBUG_KERNEL_DC. Acked-by: Alex Deucher <> Reviewed-by: Nicholas Kazlauskas <> Signed-off-by: Takashi Iwai <> Signed-off-by: Alex Deucher <>
5 daysdrm/amd/display: Don't invoke kgdb_breakpoint() unconditionallyTakashi Iwai1-1/+1
ASSERT_CRITICAL() invokes kgdb_breakpoint() whenever either CONFIG_KGDB or CONFIG_HAVE_KGDB is set. This, however, may lead to a kernel panic when no kdb stuff is attached, since the kgdb_breakpoint() call issues INT3. It's nothing but a surprise for normal end-users. For avoiding the pitfall, make the kgdb_breakpoint() call only when CONFIG_DEBUG_KERNEL_DC is set. Cc: <> Acked-by: Alex Deucher <> Reviewed-by: Nicholas Kazlauskas <> Signed-off-by: Takashi Iwai <> Signed-off-by: Alex Deucher <>
5 daysdrm/amd/display: Fix kernel panic by dal_gpio_open() errorTakashi Iwai1-2/+2
Currently both error code paths handled in dal_gpio_open_ex() issues ASSERT_CRITICAL(), and this leads to a kernel panic unnecessarily if CONFIG_KGDB is enabled. Since basically both are non-critical errors and can be recovered, drop those assert calls and use a safer one, BREAK_TO_DEBUGGER(), for allowing the debugging, instead. BugLink: Cc: <> Acked-by: Alex Deucher <> Reviewed-by: Nicholas Kazlauskas <> Signed-off-by: Takashi Iwai <> Signed-off-by: Alex Deucher <>
5 daysdrm/amdgpu/display: use kvzalloc again in dc_create_stateAlex Deucher1-2/+2
It looks this was accidently lost in a follow up patch. dc context is large and we don't need contiguous pages. Fixes: e4863f118a7d ("drm/amd/display: Multi display cause system lag on mode change") Reviewed-by: Nicholas Kazlauskas <> Signed-off-by: Alex Deucher <> Cc: Aric Cyr <> Cc: Alex Xu <> Reported-by: Alex Xu (Hello71) <> Tested-by: Alex Xu (Hello71) <> Cc:
5 daysdrm/amd/display: adding ddc_gpio_vga_reg_list to ddc reg def'nsMartin Leung1-0/+12
why: oem-related ddc read/write fails without these regs how: copy from hw_factory_dcn20.c Signed-off-by: Martin Leung <> Acked-by: Aurabindo Pillai <> Signed-off-by: Alex Deucher <>
5 daysdrm/amd/display: prevent null pointer accessDmytro Laktyushkin1-5/+7
Prevent null pointer access when checking odm tree. Signed-off-by: Dmytro Laktyushkin <> Acked-by: Aurabindo Pillai <> Signed-off-by: Alex Deucher <> Cc: <>
5 daysdrm/amdgpu: increase the reserved VM size to 2MBChristian König1-2/+2
Ideally this should be a multiple of the VM block size. 2MB should at least fit for Vega/Navi. Signed-off-by: Christian König <> Reviewed-by: Madhav Chauhan <> Reviewed-by: Felix Kuehling <> Signed-off-by: Alex Deucher <> Cc:
5 daysdrm/amd/display: Fixed panic during seamless boot.David Galiffi1-1/+2
[why] get_pixel_clk_frequency_100hz is undefined in clock_source_funcs. [how] set function pointer: ".get_pixel_clk_frequency_100hz = get_pixel_clk_frequency_100hz" Signed-off-by: David Galiffi <> Reviewed-by: Bhawanpreet Lakha <> Acked-by: Aurabindo Pillai <> Signed-off-by: Alex Deucher <>
5 daysdrm/amdgpu: don't map BO in reserved regionMadhav Chauhan1-0/+10
2MB area is reserved at top inside VM. Suggested-by: Christian König <> Signed-off-by: Madhav Chauhan <> Reviewed-by: Christian König <> Signed-off-by: Alex Deucher <> Cc:
5 daysdrm/amdgpu: add DID for navi10 blockchain SKUTianci.Yin1-0/+1
Reviewed-by: Alex Deucher <> Reviewed-by: Guchun Chen <> Signed-off-by: Tianci.Yin <> Signed-off-by: Alex Deucher <>
5 daysdrm/amdgpu: disable DCN and VCN for navi10 blockchain SKU(v3)Tianci.Yin1-2/+12
The blockchain SKU has no display and video support, remove them. Reviewed-by: Alex Deucher <> Signed-off-by: Tianci.Yin <> Signed-off-by: Alex Deucher <>
5 daysdrm/v3d: Fix double free in v3d_submit_cl_ioctl()Dan Carpenter1-1/+0
Originally this error path used to leak "bin" but then we accidentally applied two separate commits to fix it and ended up with a double free. Signed-off-by: Dan Carpenter <> Signed-off-by: Maxime Ripard <> Link:
5 daysdrm/sun4i: frontend: Fix the scaler phase on A33Maxime Ripard1-1/+1
The A33 has a different phase parameter in the Allwinner BSP on the channel1 than the one currently applied. Fix this. Signed-off-by: Maxime Ripard <> Acked-by: Jernej Skrabec <> Link:
5 daysdrm/sun4i: frontend: Reuse the ch0 phase for RGB formatsMaxime Ripard1-3/+5
When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko <> Signed-off-by: Maxime Ripard <> Acked-by: Jernej Skrabec <> Link:
5 daysdrm/sun4i: frontend: Rework a bit the phase dataMaxime Ripard2-31/+9
The scaler filter phase setup in the allwinner kernel has two different cases for setting up the scaler filter, the first one using different phase parameters for the two channels, and the second one reusing the first channel parameters on the second channel. The allwinner kernel has a third option where the horizontal phase of the second channel will be set to a different value than the vertical one (and seems like it's the same value than one used on the first channel). However, that code path seems to never be taken, so we can ignore it for now, and it's essentially what we're doing so far as well. Since we will have always the same values across each components of the filter setup for a given channel, we can simplify a bit our frontend structure by only storing the phase value we want to apply to a given channel. Signed-off-by: Maxime Ripard <> Acked-by: Jernej Skrabec <> Link:
5 daysMerge remote-tracking branch 'drm-misc/drm-misc-next-fixes' into drm-misc-fixesMaxime Ripard2-8/+21
We have a few leftovers from the merge window period in drm-misc-next-fixes, let's bring them into drm-misc-fixes Signed-off-by: Maxime Ripard <>
6 daysLinux 5.10-rc1Linus Torvalds1-2/+2
6 daystreewide: Convert macro and uses of __section(foo) to __section("foo")Joe Perches117-196/+196
Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Conversion done using the script at: Signed-off-by: Joe Perches <> Reviewed-by: Nick Desaulniers <> Reviewed-by: Miguel Ojeda <> Signed-off-by: Linus Torvalds <>
6 dayskernel/sys.c: fix prototype of prctl_get_tid_address()Rasmus Villemoes1-3/+3
tid_addr is not a "pointer to (pointer to int in userspace)"; it is in fact a "pointer to (pointer to int in userspace) in userspace". So sparse rightfully complains about passing a kernel pointer to put_user(). Reported-by: kernel test robot <> Signed-off-by: Rasmus Villemoes <> Signed-off-by: Linus Torvalds <>
6 daysmm: remove kzfree() compatibility definitionEric Biggers6-8/+6
Commit 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()") renamed kzfree() to kfree_sensitive(), but it left a compatibility definition of kzfree() to avoid being too disruptive. Since then a few more instances of kzfree() have slipped in. Just get rid of them and remove the compatibility definition once and for all. Signed-off-by: Eric Biggers <> Signed-off-by: Linus Torvalds <>
6 dayscheckpatch: enable GIT_DIR environment use to set git repository locationJoe Perches1-5/+7
If set, use the environment variable GIT_DIR to change the default .git location of the kernel git tree. If GIT_DIR is unset, keep using the current ".git" default. Link: Signed-off-by: Joe Perches <> Tested-by: Geert Uytterhoeven <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
6 daysMerge tag 'timers-urgent-2020-10-25' of ↵Linus Torvalds3-1/+116
git:// Pull timer fixes from Thomas Gleixner: "A time namespace fix and a matching selftest. The futex absolute timeouts which are based on CLOCK_MONOTONIC require time namespace corrected. This was missed in the original time namesapce support" * tag 'timers-urgent-2020-10-25' of git:// selftests/timens: Add a test for futex() futex: Adjust absolute futex timeouts with per time namespace offset