Make the interface more symmetric by providing and using a
ttm_resource_cursor_init().
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +++-
drivers/gpu/drm/ttm/ttm_resource.c | 34 +-
Use the LRU walker for eviction. This helps
removing a lot of code with weird locking
semantics.
The functionality is slightly changed so that
when trylocked buffer objects are exhausted, we
continue to interleave walks with ticket-locks while
there is still progress made. The list walks are
not
Rework the TTM swapping to use the LRU walker helper.
This helps fixing up the ttm_bo_swapout() interface
to be consistent about not requiring any locking.
For now mimic the current behaviour of using trylock
only. We could be using ticket-locks here but defer
that until it's deemed necessary.
To make the transition to using lru hitches easier,
simplify the ttm_resource_manager_next() interface to only take
the cursor and reuse ttm_resource_manager_next() functionality
from ttm_resource_manager_first().
Cc: Christian König
Cc: Somalapuram Amaranath
Cc: Matthew Brost
Cc:
Provide a generic LRU walker in TTM, in the spirit of drm_gem_lru_scan()
but building on the restartable TTM LRU functionality.
The LRU walker optionally supports locking objects as part of
a ww mutex locking transaction, to mimic to some extent the
current functionality in ttm. However any
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point. Due to
the way LRU bumping works in TTM, newly
To address the problem with hitches moving when bulk move
sublists are lru-bumped, register the list cursors with the
ttm_lru_bulk_move structure when traversing its list, and
when lru-bumping the list, move the cursor hitch to the tail.
This also means it's mandatory for drivers to call
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the
These are cherry-picks from the xe shrinker series here:
https://patchwork.freedesktop.org/series/131815/
extracted to speed up review progress and inclusion.
The series provides a restartable LRU walk and makes it possible
resume the walk after dropping the lock to evict or swap out.
Patch
Hi Jeremy,
Am 05.07.24 um 17:03 schrieb Lukas Wunner:
On Fri, Jul 05, 2024 at 12:22:33PM +0200, Stefan Wahren wrote:
Am 05.07.24 um 10:48 schrieb Lukas Wunner:
The real question is whether BCM2848 platforms likewise cannot disable
the clock of the dwc2 controller or whether this is specific
Adding dri-devel
On Fri, 5 Jul 2024 at 17:14, Stefan Wahren wrote:
> Hi,
> last year my Raspberry Pi 3B Plus died, so i didn't noticed this sooner.
> If I ran Raspberry Pi OS Bullseye with X11 and a recent Mainline Kernel
> (arm/multi_v7_defconfig) on my new Raspberry Pi 3 B+, i'm getting the
>
Hi Krzysztof, Daniel, and Maxime,
On Fri, Jul 05, 2024 at 03:41:26PM +0200, Daniel Vetter wrote:
> On Fri, Jul 05, 2024 at 01:33:38PM +0200, Krzysztof Kozlowski wrote:
> > On 05/07/2024 13:22, Maxime Ripard wrote:
> > > On Fri, Jul 05, 2024 at 01:19:50PM GMT, Daniel Vetter wrote:
> > >> On Fri,
Hi Linus,
Dave is on vacations, should be back next week. Just small fixes all over
here, all quiet as it should.
Cheers, Sima
drm-fixes-2024-07-05:
drm-fixes for v6.10-rc7
drivers:
- amd: mostly amdgpu display fixes + radeon vm NULL deref fix
- xe: migration error handling + typoed register
On Fri, Jul 05, 2024 at 12:22:33PM +0200, Stefan Wahren wrote:
> Am 05.07.24 um 10:48 schrieb Lukas Wunner:
> > A similar issue was reported for Agilex platforms back in 2021:
> >
> > https://lore.kernel.org/all/5e8cbce0-3260-2971-484f-fc73a3b2b...@synopsys.com/
> >
> > It was fixed by commit
On Thu, Jul 04, 2024 at 06:45:36PM GMT, Marc Gonzalez wrote:
> From: Arnaud Vrac
>
> Ported from the downstream driver.
Please write some sensible commit message.
>
> Signed-off-by: Arnaud Vrac
> Signed-off-by: Marc Gonzalez
> ---
> drivers/gpu/drm/msm/Makefile | 1 +
>
On Thu, Jul 04, 2024 at 02:24:49PM GMT, Maxime Ripard wrote:
> On Fri, Jun 28, 2024 at 04:42:35PM GMT, Thierry Reding wrote:
> > On Fri, Jun 28, 2024 at 03:08:46PM GMT, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Fri, Jun 28, 2024 at 01:29:17PM GMT, Thierry Reding wrote:
> > > > On Tue, May 21,
On Fri, Jul 05, 2024 at 01:33:38PM +0200, Krzysztof Kozlowski wrote:
> On 05/07/2024 13:22, Maxime Ripard wrote:
> > On Fri, Jul 05, 2024 at 01:19:50PM GMT, Daniel Vetter wrote:
> >> On Fri, Jul 05, 2024 at 12:03:56PM +0200, Krzysztof Kozlowski wrote:
> >>> Patches to STI DRM are not being picked
On Fri, 2024-07-05 at 14:41 +0200, Christian König wrote:
> Am 03.07.24 um 17:51 schrieb Thomas Hellström:
> > On Wed, 2024-07-03 at 15:25 +0200, Christian König wrote:
> > > Some contended objects might never be locked again in the case of
> > > eviction
> > > handling for example.
> > >
> > >
The caching mode for buffer objects with VRAM as a possible
placement was forced to write-combined, regardless of placement.
However, write-combined system memory is expensive to allocate and
even though it is pooled, the pool is expensive to shrink, since
it involves global CPU TLB flushes.
Hello Liu,
On Fri, Jul 05, 2024 at 05:09:22PM +0800, Liu Ying wrote:
> This patch series aims to add Freescale i.MX8qxp Display Controller support.
I really appreciate your work here, I am looking forward for a better
support in mainline Linux for both i.MX8QXP and i.MX8QP.
With that said,
Am 03.07.24 um 17:51 schrieb Thomas Hellström:
On Wed, 2024-07-03 at 15:25 +0200, Christian König wrote:
Some contended objects might never be locked again in the case of
eviction
handling for example.
Make sure that those doesn't show up in the list of locked objects
until
they are
Implement struct drm_crtc_funcs.get_vblank_timestamp with the DRM
helper drm_crtc_vblank_helper_get_vblank_timestamp() with its helper
get_scanout_position. Read the scanout position from the MGAREG_VCOUNT
register.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.h |
There's no VBLANK interrupt on Matrox chipsets. The workaround that is
being used here and in other free Matrox drivers is to program
to the value of and enable the VLINE interrupt. This triggers
an interrupt at the time when VBLANK begins.
VLINE uses separate registers for enabling and
Replace the line-compare value of with a dedicated variable
. Improves readability and prepares for vblank support.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
In mgag200_set_mode_regs(), align variable names with the field names
given in the Matrox programming manuals. Makes the code and docs grep-
able.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 56 +-
1 file changed, 28 insertions(+), 28
Represent fields for horizontal and vertical blanking with ,
, and . Aligns the code with the Matrox
programming manuals.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 29 ++
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git
Use the values with the crtc_ prefix from struct drm_display_mode to
program hardware. The DRM core adjusted these values to the requirements
of CRTC hardware.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 16
1 file changed, 8 insertions(+), 8
In mgag200_set_mode_regs(), use hexadecimal indices for accessing
registers. Aligns the code with the register indices in the Matrox
programming manuals. Also convert to lower-case hexadecimal values.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 50
(was: Rate-limit shadow-FB-to-console-update to screen refresh)
Implement support for VBLANK events in mgag200.
Patches 1 to 5 prepare mgag200's modesetting code by renaming or
adding variables for various hardware fields. This makes the code
more readable and aligns it with the programming
On 05/07/2024 13:14, Maxime Ripard wrote:
> +Alain
>
> On Tue, Jun 04, 2024 at 03:18:55PM GMT, Krzysztof Kozlowski wrote:
>> On 27/05/2024 16:47, Alain Volmat wrote:
>>> Hi Krzysztof,
>>>
>>> thanks for your patch, sorry for the delay.
>>>
...
>>>
>>> Acked-by: Alain Volmat
>>
>> What does
On 05/07/2024 13:22, Maxime Ripard wrote:
> On Fri, Jul 05, 2024 at 01:19:50PM GMT, Daniel Vetter wrote:
>> On Fri, Jul 05, 2024 at 12:03:56PM +0200, Krzysztof Kozlowski wrote:
>>> Patches to STI DRM are not being picked up, so even though there is
>>> maintainer activity, it seems that these
On Thu, 4 Jul 2024 22:17:08 +0300, Dmitry Baryshkov wrote:
> Currently the DRM DSC functions are selected by the
> DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI
> code (both panel and host drivers) end up selecting the seemingly
> irrelevant DP helpers. Split the DSC
On Fri, Jul 05, 2024 at 01:19:50PM GMT, Daniel Vetter wrote:
> On Fri, Jul 05, 2024 at 12:03:56PM +0200, Krzysztof Kozlowski wrote:
> > Patches to STI DRM are not being picked up, so even though there is
> > maintainer activity, it seems that these drivers are not being actively
> > looked at.
On Sat, 30 Mar 2024 21:38:28 +0100, Krzysztof Kozlowski wrote:
> Core in platform_driver_register() already sets the .owner, so driver
> does not need to. Whatever is set here will be anyway overwritten by
> main driver calling platform_driver_register().
>
>
Applied to misc/kernel.git
On Fri, Jul 05, 2024 at 12:03:56PM +0200, Krzysztof Kozlowski wrote:
> Patches to STI DRM are not being picked up, so even though there is
> maintainer activity, it seems that these drivers are not being actively
> looked at. Reflect this in maintainer status.
Note that since the driver is in
+Alain
On Tue, Jun 04, 2024 at 03:18:55PM GMT, Krzysztof Kozlowski wrote:
> On 27/05/2024 16:47, Alain Volmat wrote:
> > Hi Krzysztof,
> >
> > thanks for your patch, sorry for the delay.
> >
> > On Sat, Mar 30, 2024 at 09:57:21PM +0100, Krzysztof Kozlowski wrote:
> >> Core in
Hi Carlos,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.10-rc6 next-20240703]
[If
On 05/07/2024 12:37, Dmitry Baryshkov wrote:
> Acked-by: Alain Volmat
What does this ack mean? You are the maintainer, so what is supposed to
happen now? If maintainer does not take patches, then the DRM STI looks
orphaned.
>>>
>>> +Cc Neil, Dmitry,
>>>
>>> I pinged and
On Wed, Jul 03, 2024 at 02:47:23PM -0400, Alex Deucher wrote:
> Hi Dave, Sima,
>
> Fixes for 6.10.
>
> The following changes since commit 22a40d14b572deb80c0648557f4bd502d7e83826:
>
> Linux 6.10-rc6 (2024-06-30 14:40:44 -0700)
>
> are available in the Git repository at:
>
>
On Thu, Jul 04, 2024 at 08:48:18AM -0700, Rob Clark wrote:
> Hi Dave, Sima,
>
> This is the main pull for v6.11. It includes a merge of the immutable
> tag qcom/20240430-a750-raytracing-v3-2-7f57c5ac0...@gmail.com to pick
> up dependencies for raytracing and SMEM speedbin.
>
> Further
On Thu, Jul 04, 2024 at 03:17:09PM +0200, Maxime Ripard wrote:
> Hi,
>
> Here's this week drm-misc-next PR, and the last PR for the 6.11 release cycle.
>
> Thanks!
> Maxime
>
> drm-misc-next-2024-07-04:
> drm-misc-next for $kernel-version:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
>
>
On Fri, 5 Jul 2024 at 13:04, Neil Armstrong wrote:
>
> On 05/07/2024 11:59, Krzysztof Kozlowski wrote:
> > On 04/06/2024 15:18, Krzysztof Kozlowski wrote:
> >> On 27/05/2024 16:47, Alain Volmat wrote:
> >>> Hi Krzysztof,
> >>>
> >>> thanks for your patch, sorry for the delay.
> >>>
> >>> On Sat,
On Thu, Jul 04, 2024 at 08:40:26AM -0700, Rob Clark wrote:
> On Thu, Jul 4, 2024 at 7:08 AM Daniel Vetter wrote:
> >
> > On Tue, Jul 02, 2024 at 05:32:39AM -0700, Rob Clark wrote:
> > > On Fri, Jun 28, 2024 at 10:44 AM Daniel Vetter wrote:
> > > >
> > > > On Thu, Jun 27, 2024 at 11:51:37AM
On Fri, Jul 05, 2024 at 05:28:00PM +0800, Chen Ni wrote:
> Add check for the return value of spi_setup() and return the error
> if it fails in order to catch the error.
>
> Signed-off-by: Chen Ni
Reviewed-by: Daniel Thompson
Daniel.
Am 05.07.24 um 10:48 schrieb Lukas Wunner:
On Thu, Jul 04, 2024 at 03:14:50PM +0100, Florian Fainelli wrote:
On 6/30/2024 4:36 PM, Stefan Wahren wrote:
On resume of the Raspberry Pi the dwc2 driver fails to enable
HCD_FLAG_HW_ACCESSIBLE before re-enabling the interrupts.
This causes a
On Thu, Jul 04, 2024 at 07:31:54AM +, Tvrtko Ursulin wrote:
>
> Hi Dave, Sima,
>
> The final pull for 6.11 is quite small and only contains a handful of
> fixes in areas such as stolen memory probing on ATS-M, GuC priority
> handling, out of memory reporting noise downgrade and fence
On 05/07/2024 11:59, Krzysztof Kozlowski wrote:
On 04/06/2024 15:18, Krzysztof Kozlowski wrote:
On 27/05/2024 16:47, Alain Volmat wrote:
Hi Krzysztof,
thanks for your patch, sorry for the delay.
On Sat, Mar 30, 2024 at 09:57:21PM +0100, Krzysztof Kozlowski wrote:
Core in
Patches to STI DRM are not being picked up, so even though there is
maintainer activity, it seems that these drivers are not being actively
looked at. Reflect this in maintainer status.
Link:
https://lore.kernel.org/all/77b4e4ad-2b1e-4b6d-bc3b-0c7b339bc...@linaro.org/
Link:
On Wed, Jul 03, 2024 at 05:13:13PM -0400, Alex Deucher wrote:
> Hi Dave, Sima,
>
> More new stuff for 6.11. There will be a few additional patches next
> week for new IPs that were added in this cycle just to get them tied off,
> but this should be it for general changes.
>
> The following
On Fri, Jun 28, 2024 at 05:31:35PM -0400, Alex Deucher wrote:
> Hi Dave, Sima,
>
> More stuff for 6.11.
>
> The following changes since commit a78313bb206e0c456a989f380c4cbd8af8af7c76:
>
> Merge tag 'drm-intel-gt-next-2024-06-12' of
> https://gitlab.freedesktop.org/drm/i915/kernel into
On 04/06/2024 15:18, Krzysztof Kozlowski wrote:
> On 27/05/2024 16:47, Alain Volmat wrote:
>> Hi Krzysztof,
>>
>> thanks for your patch, sorry for the delay.
>>
>> On Sat, Mar 30, 2024 at 09:57:21PM +0100, Krzysztof Kozlowski wrote:
>>> Core in platform_driver_register() already sets the .owner,
Add check for the return value of spi_setup() and return the error
if it fails in order to catch the error.
Signed-off-by: Chen Ni
---
Changelog:
v1 -> v2:
1. Use dev_err_probe() to match other error paths
---
drivers/video/backlight/l4f00242t03.c | 5 -
1 file changed, 4 insertions(+), 1
On Fri, Jun 28, 2024 at 01:46:32PM +, Chun-Kuang Hu wrote:
> Hi, Dave & Daniel:
>
> This includes:
>
> 1. Convert to platform remove callback returning void
> 2. Drop chain_mode_fixup call in mode_valid()
> 3. Fixes the errors of MediaTek display driver found by IGT.
> 4. Add display support
On Fri, Jun 28, 2024 at 12:39:33PM +0200, Lucas Stach wrote:
> Hi Dave, hi Sima,
>
> please pull the following changes for the next merge window. Mostly
> fixes, but as they concern new hardware support there's no need to rush
> them into the current -rc.
>
> Regards,
> Lucas
>
> The following
On Wed, Jul 03, 2024 at 04:59:12PM +0900, Inki Dae wrote:
> Hi Dave and Daniel,
>
>Just three cleanup patches to Exynos Virtual Display driver
>for improved management.
>
> Please kindly let me know if there is any problem.
>
> Thanks,
> Inki Dae
>
>
> The following changes since
On Fri, 5 Jul 2024 at 12:15, Aleksandr Mishin wrote:
>
> In adreno_request_fw() when debugging information is printed to the log
> after firmware load, an incorrect filename is printed. 'newname' is used
> instead of 'fwname', so prefix "qcom/" is being added to filename.
> Looks like
In adreno_request_fw() when debugging information is printed to the log
after firmware load, an incorrect filename is printed. 'newname' is used
instead of 'fwname', so prefix "qcom/" is being added to filename.
Looks like "copy-paste" mistake.
Fix this mistake by replacing 'newname' with
Load the lut values during pipe enable.
v2: Add the display version check
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_crtc.c| 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
drivers/gpu/drm/i915/display/skl_scaler.c| 13 -
3 files
The sharpness property requires the use of one of the scaler
so need to set the sharpness scaler coefficient values.
These values are based on experiments and vary for different
tap value/win size. These values are normalized by taking the
sum of all values and then dividing each value with a sum.
Add new registers and related bits. Compute the strength
value and tap value based on display mode.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +-
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_sharpen_filter.c | 105
As only second scaler can be used for sharpness check if it
is available and if panel fitting is also not enabled, the
set the sharpness. Panel fitting will have the preference
over sharpness property.
v2: Added the panel fitting check before enabling sharpness
Signed-off-by: Nemesa Garg
---
Introduces the new crtc property "SHARPNESS_STRENGTH" that allows
the user to set the intensity so as to get the sharpness effect.
The value of this property can be set from 0-255.
It is useful in scenario when the output is blurry and user
want to sharpen the pixels. User can increase/decrease
Many a times images are blurred or upscaled content is also not as
crisp as original rendered image. Traditional sharpening techniques often
apply a uniform level of enhancement across entire image, which sometimes
result in over-sharpening of some areas and potential loss of natural details.
Add myself as the maintainer of i.MX8qxp Display Controller.
Signed-off-by: Liu Ying
---
MAINTAINERS | 19 +++
1 file changed, 19 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 35db18d26c11..29c9d52e74d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7379,6 +7379,25
i.MX8qxp Display Controller(DC) is comprised of three main components that
include a blit engine for 2D graphics accelerations, display controller for
display output processing, as well as a command sequencer. Add kernel
mode setting support for the display controller part with two CRTCs and
two
i.MX8qxp Display Controller has a built-in interrupt controller to support
Enable/Status/Preset/Clear interrupt bit. Add driver for it.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/dc/Kconfig | 1 +
drivers/gpu/drm/imx/dc/Makefile | 2 +-
drivers/gpu/drm/imx/dc/dc-drv.c | 1 +
i.MX8qxp Display Controller pixel engine consists of all processing
units that operate in the AXI bus clock domain. Add drivers for
ConstFrame, ExtDst, FetchLayer, FetchWarp and LayerBlend units, as
well as a pixel engine driver, so that two displays with primary
planes can be supported. The
i.MX8qxp Display Controller display engine consists of all processing
units that operate in a display clock domain. Add minimal feature
support with FrameGen and TCon so that the engine can output display
timings. The display engine driver as a master binds FrameGen and
TCon drivers as
i.MX8qxp Display Controller(DC) is comprised of three main components that
include a blit engine for 2D graphics accelerations, display controller for
display output processing, as well as a command sequencer.
Signed-off-by: Liu Ying
---
.../bindings/display/imx/fsl,imx8qxp-dc.yaml | 243
i.MX8qxp Display Controller has a built-in interrupt controller to support
Enable/Status/Preset/Clear interrupt bit.
Signed-off-by: Liu Ying
---
.../fsl,imx8qxp-dc-intc.yaml | 321 ++
1 file changed, 321 insertions(+)
create mode 100644
i.MX8qxp Display Controller pixel engine consists of all processing units
that operate in the AXI bus clock domain. Command sequencer and interrupt
controller of the Display Controller work with AXI bus clock, but they are
not in pixel engine.
Signed-off-by: Liu Ying
---
i.MX8qxp Display Controller display engine consists of all processing units
that operate in a display clock domain.
Signed-off-by: Liu Ying
---
.../imx/fsl,imx8qxp-dc-display-engine.yaml| 166 ++
1 file changed, 166 insertions(+)
create mode 100644
Freescale i.MX8qxp Display Controller is implemented as construction set of
building blocks with unified concept and standardized interfaces.
Document some processing units to support two display outputs.
ConstFrame, ExtDst, FetchLayer, FetchWarp and LayerBlend processing units
are in pixel
Hi,
This patch series aims to add Freescale i.MX8qxp Display Controller support.
The controller is comprised of three main components that include a blit
engine for 2D graphics accelerations, display controller for display output
processing, as well as a command sequencer.
Previous patch series
On Thu, Jul 04, 2024 at 03:14:50PM +0100, Florian Fainelli wrote:
> On 6/30/2024 4:36 PM, Stefan Wahren wrote:
> > On resume of the Raspberry Pi the dwc2 driver fails to enable
> > HCD_FLAG_HW_ACCESSIBLE before re-enabling the interrupts.
> > This causes a situation where both handler ignore a
On Fri, Jul 05, 2024 at 04:38:34PM +0800, Chen Ni wrote:
> Add check for the return value of spi_setup() and return the error
> if it fails in order to catch the error.
>
> Signed-off-by: Chen Ni
> ---
> drivers/video/backlight/l4f00242t03.c | 5 -
> 1 file changed, 4 insertions(+), 1
On Thu, 4 Jul 2024, at 3:28 AM, Conor Dooley wrote:
>> Add display engine bus, clock and mixer bindings for the DE33.
>>
>> Signed-off-by: Ryan Walklin
>
> Probably this should be 3 patches given 3 subsystems, but the content is
> Acked-by: Conor Dooley
>
> Cheers,
> Conor.
>
Thanks Conor, will
On Thu, 4 Jul 2024, at 3:38 AM, Conor Dooley wrote:
> I forgot to reply to, or somehow didn't notice your reply to my comments
> on this patch. I would just drop this change as I think it's a tooling
> issue. I checked the version of dt-schema etc that I have here locally
> and there were no
Hi Stephen, thanks for reviewing.
On Thu, 4 Jul 2024, at 11:02 AM, Stephen Boyd wrote:
> Quoting Ryan Walklin (2024-07-03 03:51:09)
>> +#include
>
> What is this include for?
>
for writel, however have confirmed this should instead be #include ,
will correct for v3.
>> + if
Add check for the return value of spi_setup() and return the error
if it fails in order to catch the error.
Signed-off-by: Chen Ni
---
drivers/video/backlight/l4f00242t03.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/l4f00242t03.c
The caching mode for buffer objects with VRAM as a possible
placement was forced to write-combined, regardless of placement.
However, write-combined system memory is expensive to allocate and
even though it is pooled, the pool is expensive to shrink, since
it involves global CPU TLB flushes.
On Tue, Jul 02, 2024 at 03:02:22PM -0400, Rodrigo Vivi wrote:
> Hi Dave and Sima,
>
> Here goes our actual last PR towards 6.11.
> One extra to make the drm-xe-next-fixes smoother.
>
> Mostly with fixes that would be anyway part of the
> drm-xe-next-fixes, plus some more SRIOV preparation
> and
Hi Carlos,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.10-rc6 next-20240703]
[If
On Wednesday, July 3rd, 2024 at 17:11, Olsak, Marek wrote:
> Alex publishes the amd-staging-drm-next branch regularly where all our kernel
> commits go.
I know. That's what I use as a base when I send amdgpu patches.
This doesn't contain any more relevant changes.
> See the gfx12 modifiers
Hi Joao,
First of all, thanks for your patch. Follows some of my comments:
> On 6/13/24 10:05 AM, Joao Paulo Pereira da Silva wrote:
You can drop the dc part in the commit title. Also, the title should
highlight that you are decoupling one part of the code in a single place
to avoid
Currently the DRM DSC functions are selected by the
DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI
code (both panel and host drivers) end up selecting the seemingly
irrelevant DP helpers. Split the DSC code to be guarded by the separate
DRM_DISPLAY_DSC_HELPER Kconfig
On Fri, Jun 28, 2024 at 9:43 AM Mina Almasry wrote:
>
Hi Mina,
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> rx queues on the netdevice. On the binding, the dma_buf_attach
> & dma_buf_map_attachment will
Hi Jonas,
[ + Diederik who has already done some testing ]
On Sat, 2024-06-15 at 17:03 +, Jonas Karlman wrote:
> This prepares and enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228,
> RK3328, RK3399 and RK356x.
>
> Patch 1-3 fixes some issues to help support use of high-resolution modes.
On 01/07/2024 15:50, Maxime Ripard wrote:
> The i2c register access (and the whole behaviour of the device) is
> constrained on the I2C_EN pin status, and you can't read it from the
> device, so it's also something we need to have in the DT.
I think the purpose of the I2C_EN pin might have been
On Thu, Jul 04, 2024 at 03:29:57PM +0800, Zhaoxiong Lv wrote:
> The starry-er88577 is a 10.1" WXGA TFT-LCD panel. Hence, we
> add a new compatible with panel specific config.
>
> Signed-off-by: Zhaoxiong Lv
> ---
> Changes between V5 and V4:
> - 1. We are compatible with starry-er88577 panels
From: Arnaud Vrac
Ported from the downstream driver.
Signed-off-by: Arnaud Vrac
Signed-off-by: Marc Gonzalez
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 1 +
drivers/gpu/drm/msm/hdmi/hdmi.h| 8 +
On Fri, Jun 28, 2024 at 9:38 AM Mina Almasry wrote:
>
Hi Mina,
Thank you so much for this work!
> ncdevmem is a devmem TCP netcat. It works similarly to netcat, but it
> sends and receives data using the devmem TCP APIs. It uses udmabuf as
> the dmabuf provider. It is compatible with a regular
On Fri, Jun 28, 2024 at 9:43 AM Mina Almasry wrote:
>
Hi Mina,
Thanks a lot for this work!
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> rx queues on the netdevice. On the binding, the dma_buf_attach
> &
On Thu, Jul 04, 2024 at 04:55:54PM +0800, Zhaoxiong Lv wrote:
> The Elan ekth6a12nay touch screen chip same as Elan eKTH6915 controller
> has a reset gpio. The difference is that they have different
> post_power_delay_ms.
>
> Signed-off-by: Zhaoxiong Lv
Acked-by: Conor Dooley
signature.asc
Em 13/05/2024 13:46, André Almeida escreveu:
The Graphics and DRM Microconference was accepted for Linux Plumbers
2024! Please, submit your proposal in the following page:
https://lpc.events/event/18/abstracts/
Remember to select "Graphics & DRM MC" in the Track field. The deadline
for
Hi Peter,
Am 02.07.24 um 22:02 schrieb Peter Robinson:
Hi Stefan,
Suspend of VC4 HDMI will likely triggers a warning from
vc4_hdmi_connector_detect_ctx() during poll of connector status.
The power management will prevent the resume and keep the relevant
power domain disabled.
Since there is
Hi Dave, Sima,
This is the main pull for v6.11. It includes a merge of the immutable
tag qcom/20240430-a750-raytracing-v3-2-7f57c5ac0...@gmail.com to pick
up dependencies for raytracing and SMEM speedbin.
Further description below.
The following changes since commit
201 - 300 of 494626 matches
Mail list logo
