> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with
> syncing
>
On 2024-02-23 08:06, Christian König wrote:
> Am 22.02.24 um 18:28 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> Pinning the BO storage to VRAM for scanout would make it inaccessible
>> to non-P2P dma-buf importers.
>
> Thinking more about it I don't think we can do this.
>
> Using the BO
On Thu, Feb 22, 2024 at 09:02:53PM +0100, Jernej Škrabec wrote:
> Dne sreda, 21. februar 2024 ob 14:45:20 CET je Maxime Ripard napisal(a):
> > Hi,
> >
> > On Fri, Feb 16, 2024 at 08:04:26PM +0100, Ondřej Jirman wrote:
> > > From: Ondrej Jirman
> > >
> > > Identical configurations of planes can l
Hi,
Am 21.02.24 um 23:17 schrieb Pavel Machek:
Hi!
so after more feedback from the OpenRGB maintainers I came up with an even
more generic proposal:
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
evaluate-set-command ioctl taking:
{
enum command /
On 2024-02-23 09:11, Michel Dänzer wrote:
> On 2024-02-23 08:06, Christian König wrote:
>>
>> So rejecting things during CS and atomic commit is the best thing we can do.
>
> It's problematic for a Wayland compositor:
>
> The CS ioctl failing is awkward. With GL, I'm pretty sure it means the
> c
This commit includes several checkpatch for drm_connector.c:
- SPDX license
- Spaces before tabs
- Unnecessary brackets
- unsigned int is preferred over unsigned
---
drivers/gpu/drm/drm_connector.c | 142
1 file changed, 71 insertions(+), 71 deletions(-)
diff --gi
On 22/02/2024 23:31, Belgaumkar, Vinay wrote:
On 2/22/2024 7:32 AM, Tvrtko Ursulin wrote:
On 21/02/2024 21:28, Rodrigo Vivi wrote:
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Vinay Belgaumkar wrote:
Allow user to provide a context hint. When this
On Thu, 22 Feb 2024 18:38:16 +0100
Pavel Machek wrote:
> Hi!
>
> > > > so after more feedback from the OpenRGB maintainers I came up with an
> > > > even
> > > > more generic proposal:
> > > > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> > > >
> > >
> > > >
el,lcd-wiring-mode = <1>;
+
+ display-timings {
+native-mode = <&timing0>;
+timing0: timing0 {
+ clock-frequency = <900>;
+ hactive = <480>;
+ vactive = <272>;
+ hback-porch = <1>;
+ hfront-porch = <1>;
+ vback-porch = <40>;
+ vfront-porch = <1>;
+ hsync-len = <45>;
+ vsync-len = <1>;
+};
+ };
+};
---
base-commit: ffd2cb6b718e189e7e2d5d0c19c25611f92e061a
change-id: 20240223-lcdc-fb-b8d2e2f3c914
Best regards,
--
Dharma Balasubiramani
Hi
Am 22.02.24 um 18:38 schrieb Pavel Machek:
Hi!
so after more feedback from the OpenRGB maintainers I came up with an even
more generic proposal:
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
evaluate-set-command ioctl taking:
{
enum command /*
On Thu, 22 Feb 2024 19:14:07 +0100
Maxime Ripard wrote:
> The i915 driver has a property to force the RGB range of an HDMI output.
> The vc4 driver then implemented the same property with the same
> semantics. KWin has support for it, and a PR for mutter is also there to
> support it.
>
> Both d
Am 23.02.24 um 09:11 schrieb Michel Dänzer:
On 2024-02-23 08:06, Christian König wrote:
Am 22.02.24 um 18:28 schrieb Michel Dänzer:
From: Michel Dänzer
Pinning the BO storage to VRAM for scanout would make it inaccessible
to non-P2P dma-buf importers.
Thinking more about it I don't think we
Am Donnerstag, 22. Februar 2024, 19:14:17 CET schrieb Maxime Ripard:
> The new HDMI connector infrastructure allows to remove some boilerplate,
> especially to generate infoframes. Let's switch to it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchi
On 1/18/24 19:39, Marek Vasut wrote:
In case the LCDIF is enabled in DT but unused, the clock used by the
LCDIF are not enabled. Those clock may even have a use count of 0 in
case there are no other users of those clock. This can happen e.g. in
case the LCDIF drives HDMI bridge which has no panel
On 2024-02-23 10:34, Christian König wrote:
> Am 23.02.24 um 09:11 schrieb Michel Dänzer:
>> On 2024-02-23 08:06, Christian König wrote:
>>> Am 22.02.24 um 18:28 schrieb Michel Dänzer:
From: Michel Dänzer
Pinning the BO storage to VRAM for scanout would make it inaccessible
to
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check
> BW limi
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
>
> Handle DP tunnel IRQs a sink (or rather
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
>
> Suspend and resume DP tunnels durin
On Tue, 20 Feb 2024, dharm...@microchip.com wrote:
> Hi Lee,
>
> On 20/02/24 1:50 pm, Lee Jones wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Tue, 20 Feb 2024, dharm...@microchip.com wrote:
> >
> >> Hi Krzysztof,
> >>
> >>
On Thu, 22 Feb 2024, Rob Herring wrote:
> On Tue, Feb 20, 2024 at 08:30:38AM +, dharm...@microchip.com wrote:
> > Hi Lee,
> >
> > On 20/02/24 1:50 pm, Lee Jones wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > the content is safe
> > >
> > > On Tue,
Il 22/02/24 16:41, Chun-Kuang Hu ha scritto:
In order to distinguish absolute jump and relative jump,
cmdq_pkt_jump() append absolute jump command, so rename it to
cmdq_pkt_jump_abs().
Signed-off-by: Chun-Kuang Hu
Reviewed-by: AngeloGioacchino Del Regno
Il 22/02/24 16:41, Chun-Kuang Hu ha scritto:
For cmdq jump command, offset 0 means relative jump and offset 1
means absolute jump. cmdq_pkt_jump() is absolute jump, so fix the
typo of CMDQ_JUMP_RELATIVE in cmdq_pkt_jump().
Fixes: 946f1792d3d7 ("soc: mediatek: cmdq: add jump function")
Signed-off
Il 22/02/24 16:41, Chun-Kuang Hu ha scritto:
cmdq_pkt_jump_rel() append relative jump command to the packet.
Relative jump change PC to the target address with offset from
current PC.
Signed-off-by: Chun-Kuang Hu
Reviewed-by: AngeloGioacchino Del Regno
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
>
> The TBT DP tunnel BW reques
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
>
> Detect DP tunnels and ena
On Wed, 21 Feb 2024, Thomas Zimmermann wrote:
> Framebuffer drivers for devices with dedicated backlight are supposed
> to set struct fb_info.bl_dev to the backlight's respective device. Use
> the value to match backlight and framebuffer in the backlight core code.
>
> Signed-off-by: Thomas Zimme
On 17/02/2024 16:02, Johan Hovold wrote:
The two device node references taken during allocation need to be
dropped when the auxiliary device is freed.
Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge
drivers")
Cc: Dmitry Baryshkov
Cc: Neil Armstrong
Signed-off-by: Jo
On 17/02/2024 16:02, Johan Hovold wrote:
The two device node references taken during allocation need to be
dropped when the auxiliary device is freed.
Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge
drivers")
Cc: Dmitry Baryshkov
Cc: Neil Armstrong
Signed-off-by: Jo
On Wed, 21 Feb 2024, Thomas Zimmermann wrote:
> cc'ing backlight maintainers
I cannot review/accept patches like this.
Please submit a [RESEND].
> Am 19.02.24 um 10:37 schrieb Thomas Zimmermann:
> > Resolves the proxy include via , which does not require the
> > backlight header.
> >
> > Signe
Hi,
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
> Starting with 6.8-rc1 the internal display sometimes fails to come up on
> machines like the Lenovo ThinkPad X13s and the logs indicate that this
> is due to a regression in the DRM subsystem [1].
>
> This series fixes a race in the pm
On 23/02/2024 12:02, Neil Armstrong wrote:
Hi,
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
Starting with 6.8-rc1 the internal display sometimes fails to come up on
machines like the Lenovo ThinkPad X13s and the logs indicate that this
is due to a regression in the DRM subsystem [1].
On 17/02/2024 16:02, Johan Hovold wrote:
From: Rob Clark
We need to bail out before adding/removing devices if we are going to
-EPROBE_DEFER. Otherwise boot can get stuck in a probe deferral loop due
to a long-standing issue in driver core (see fbc35b45f9f6 ("Add
documentation on meaning of -EP
This patchset is the second version of [1]. It is almost a complete
rewrite to use a line-by-line algorithm for the composition.
It can be divided in three parts:
- PATCH 1 to 4: no functional change is intended, only some formatting and
documenting
(PATCH 2 is taken from [2])
- PATCH 5: main pat
Few no-op changes to remove double spaces and fix wrong alignments.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 10 +-
drivers/gpu/drm/vkms/vkms_crtc.c | 6 ++
drivers/gpu/drm/vkms/vkms_drv.c | 3 +--
drivers/gpu/drm/vkms/vkms_plane.c| 9 ++
From: Arthur Grillo
Remove intermidiary variables and access the variables directly from
drm_frame. These changes should be noop.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_drv.h | 3 ---
drivers/gpu/drm/vkms/vkms_formats.c | 12 +++---
Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
compiler to check if the passed functions take the correct arguments.
Such typedefs will help ensuring consistency across the code base in
case of update of these prototypes.
Introduce a check around the get_pixel_*_functions to
Re-introduce a line-by-line composition algorithm for each pixel format.
This allows more performance by not requiring an indirection per pixel
read. This patch is focussed on readability of the code.
Line-by-line composition was introduced by [1] but rewritten back to
pixel-by-pixel algorithm in
From: Arthur Grillo
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentati
Add some documentation on pixel conversion functions.
Update of outdated comments for pixel_write functions.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 +++
drivers/gpu/drm/vkms/vkms_drv.h | 13
drivers/gpu/drm/vkms/vkms_formats.c | 58 +
From: Arthur Grillo
Add support to the YUV formats bellow:
- NV12
- NV16
- NV24
- NV21
- NV61
- NV42
- YUV420
- YUV422
- YUV444
- YVU420
- YVU422
- YVU444
The conversion matrices of each encoding and range were obtained by
rounding the values of the original conversion matrices multiplied by
2^
From: Arthur Grillo
Create range and encoding properties. This should be noop, as none of
the conversion functions need those properties.
Signed-off-by: Arthur Grillo
[Louis Chauvet: retained only relevant parts]
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_plane.c | 9 +
From: Arthur Grillo
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
Signed-off-by: Arthur Grillo
[Louis Chauvet: fix minor formating issues (whitespace, double line)]
Signed-off-by: Louis Chauvet
---
drivers/gp
Am 23.02.24 um 12:37 schrieb Louis Chauvet:
From: Arthur Grillo
Add support to the YUV formats bellow:
- NV12
- NV16
- NV24
- NV21
- NV61
- NV42
- YUV420
- YUV422
- YUV444
- YVU420
- YVU422
- YVU444
The conversion matrices of each encoding and range were obtained by
rounding the values of
Hi Louis,
On 2/23/24 08:37, Louis Chauvet wrote:
Re-introduce a line-by-line composition algorithm for each pixel format.
This allows more performance by not requiring an indirection per pixel
read. This patch is focussed on readability of the code.
s/focussed/focused
Line-by-line compositi
On 2/23/24 01:09, Rob Herring wrote:
> On Sat, Feb 17, 2024 at 12:02:58PM +0100, Raphael Gallais-Pou wrote:
>> Setting a panel-timing in the device-tree overwrite the one specified in
>> the driver and set it as preferred. In that case 'height-mm',
>> 'width-mm' and 'panel-timing' are properties
On 17-02-24, 16:02, Johan Hovold wrote:
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> This could potentially
On 17-02-24, 16:02, Johan Hovold wrote:
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> Move registration of th
On Sat, 17 Feb 2024 10:39:37 +0100, Krzysztof Kozlowski wrote:
> The xlate callbacks are supposed to translate of_phandle_args to proper
> provider without modifying the of_phandle_args. Make the argument
> pointer to const for code safety and readability.
>
>
Applied, thanks!
[1/1] phy: con
On Thu, 22 Feb 2024 23:42:11 +0200
andy.shevche...@gmail.com wrote:
> Thu, Feb 22, 2024 at 03:58:37PM +0100, Marek Behún kirjoitti:
> > A few drivers are doing resource-managed mutex initialization by
> > implementing ad-hoc one-liner mutex dropping functions and using them
> > with devm_add_actio
STM32MP13x SoC family embeds a new version of LTDC (Liquid crystal
display - Thin film transistor) Display Controller.
It provides a parallel digital RGB (red, green, blue) and signals for
horizontal, vertical synchronization, pixel clock and data enable as
output to interface directly to a variet
This serie aims to enable display support for the stm32mp135f-dk board
Those are only patches of the device-tree since the driver support has
already been added [1].
It respectivelly:
- adds support for the display controller on stm32mp135
- adds pinctrl for the display controller
Link panel and display controller.
Enable panel, backlight and display controller.
Signed-off-by: Raphael Gallais-Pou
---
Changes in v2:
- Fixed dtbs_check warnings :
arch/arm/boot/dts/st/stm32mp135f-dk.dtb: panel-backlight:
'default-brightness-level' does not match any of the regexes: 'pinct
This device inherits properties from panel-common. Those should be allowed
to use, instead of specifying properties to true for each specific use.
Signed-off-by: Raphael Gallais-Pou
---
Changes in v3:
- Allow every properties instead of adding each properties to true as
Rob suggested
- Re
Adds LTDC pinctrl support and assigns dedicated GPIO pins.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm/boot/dts/st/stm32mp13-pinctrl.dtsi | 57 +
1 file changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/st/stm32mp13-pinctrl.dtsi
b/arch/arm/boot/dts/st/stm
From: Paul Cercueil
Use the functions provided by the buffer-dma core to implement the
DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
Since we want to be able to transfer an arbitrary number of bytes and
not necesarily the full DMABUF, the associated scatterlist is conve
On Thu, Feb 22, 2024 at 10:57:07PM +0200, Dmitry Baryshkov wrote:
> On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
> >
> > Combining allocation and registration is an anti-pattern that should be
> > avoided. Add two new functions for allocating and registering an dp-hpd
> > bridge with a proper
On Fri, 23 Feb 2024 02:42:22 +0100
Erhard Furtner wrote:
> Greetings!
>
> Looks like my Talos II (running a BE kernel+system) fails some of the kernels
> internal unit tests. At running drm_gem_shmem_test via 'modprobe -v
> drm_gem_shmem_test' I get:
KASAN gets some additional information out
On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> On 23/02/2024 12:02, Neil Armstrong wrote:
> > Hi,
> >
> > On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
> >> Starting with 6.8-rc1 the internal display sometimes fails to come up on
> >> machines like the Lenovo ThinkPad
From: Paul Cercueil
Add implementation of the .device_prep_peripheral_dma_vec() callback.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
drivers/dma/dma-axi-dmac.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/dma/dma-axi-dmac.c
Hi Louis,
On 2/23/24 08:37, Louis Chauvet wrote:
This patchset is the second version of [1]. It is almost a complete
rewrite to use a line-by-line algorithm for the composition.
It can be divided in three parts:
- PATCH 1 to 4: no functional change is intended, only some formatting and
documenti
/* Only for suspend resume context */
u32 vid_context;
};
+enum am65_cpsw_tx_buf_type {
+ AM65_CPSW_TX_BUF_TYPE_SKB,
+ AM65_CPSW_TX_BUF_TYPE_XDP,
+};
+
struct am65_cpsw_host {
struct am65_cpsw_common *common;
void
pted patch for the changes made in patch 1.
Patchset based on next-20240223.
---
Paul Cercueil (6):
dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec
iio: core: Add new DMABUF interface infrastruct
Hi,
On 2024/2/23 02:14, Maxime Ripard wrote:
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
Acked-by: Sui Jingfeng
From: Paul Cercueil
Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
DMA buffer implementations.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
drivers/iio/buffer/industrialio-buffer-dma.c
On Thu, 08 Feb 2024, Andy Shevchenko wrote:
> Allow to use driver on non-OF platforms and other cleanups.
>
> Changelog v3:
> - rebased on top of the last changes against this driver (Lee)
> - added tags to patch 2 (Daniel, Flavio)
>
> Changelog v2:
> - rename pm3309c_parse_dt_node() --> mp3309c
From: Paul Cercueil
This function can be used to initiate a scatter-gather DMA transfer,
where the address and size of each segment is located in one entry of
the dma_vec array.
The major difference with dmaengine_prep_slave_sg() is that it supports
specifying the lengths of each DMA transfer; a
On Thu, 01 Feb 2024 17:14:12 +0200, Andy Shevchenko wrote:
> Allow to use driver on non-OF platforms and other cleanups.
>
> Changelog v2:
> - rename pm3309c_parse_dt_node() --> mp3309c_parse_fwnode() (Daniel)
> - add tags (Daniel, Flavio)
> - new patch 2
>
> [...]
Applied, thanks!
[1/3] backli
On Thu, 08 Feb 2024 20:42:25 +0200, Andy Shevchenko wrote:
> Allow to use driver on non-OF platforms and other cleanups.
>
> Changelog v3:
> - rebased on top of the last changes against this driver (Lee)
> - added tags to patch 2 (Daniel, Flavio)
>
> Changelog v2:
> - rename pm3309c_parse_dt_node
On Fri, 23 Feb 2024, Lee Jones wrote:
> On Thu, 08 Feb 2024, Andy Shevchenko wrote:
>
> > Allow to use driver on non-OF platforms and other cleanups.
> >
> > Changelog v3:
> > - rebased on top of the last changes against this driver (Lee)
> > - added tags to patch 2 (Daniel, Flavio)
> >
> > Cha
On 23/02/2024 13:51, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
On 23/02/2024 12:02, Neil Armstrong wrote:
Hi,
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
Starting with 6.8-rc1 the internal display sometimes fails to come up on
machines lik
From: Paul Cercueil
Document the new DMABUF based API.
Signed-off-by: Paul Cercueil
Signed-off-by: Nuno Sa
---
Documentation/iio/dmabuf_api.rst | 54
Documentation/iio/index.rst | 2 ++
2 files changed, 56 insertions(+)
diff --git a/Documentatio
On Fri, 23 Feb 2024 at 15:52, Neil Armstrong wrote:
>
> On 23/02/2024 13:51, Johan Hovold wrote:
> > On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> >> On 23/02/2024 12:02, Neil Armstrong wrote:
> >>> Hi,
> >>>
> >>> On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
>
On Fri, Feb 23, 2024 at 02:52:28PM +0100, Neil Armstrong wrote:
> On 23/02/2024 13:51, Johan Hovold wrote:
> > On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> >> On 23/02/2024 12:02, Neil Armstrong wrote:
> >>> Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.g
On Fri, Feb 23, 2024 at 04:18:08PM +0200, Dmitry Baryshkov wrote:
> On Fri, 23 Feb 2024 at 15:52, Neil Armstrong
> wrote:
> > On 23/02/2024 13:51, Johan Hovold wrote:
> > > On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> > >> On 23/02/2024 12:02, Neil Armstrong wrote:
> > >>> T
Am 06.02.24 um 13:56 schrieb Christian König:
Am 06.02.24 um 13:53 schrieb Thomas Hellström:
Hi, Christian,
On Fri, 2024-01-26 at 15:09 +0100, Christian König wrote:
Previously we would never try to move a BO into the preferred
placements
when it ever landed in a busy placement since those wer
On Fri, Feb 23, 2024 at 08:25:38AM +0200, Shankar, Uma wrote:
> [...]
> > diff --git a/drivers/gpu/drm/display/Kconfig
> > b/drivers/gpu/drm/display/Kconfig
> > index 09712b88a5b83..c0f56888c3280 100644
> > --- a/drivers/gpu/drm/display/Kconfig
> > +++ b/drivers/gpu/drm/display/Kconfig
> [...]
> >
On 23/02/2024 15:21, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 02:52:28PM +0100, Neil Armstrong wrote:
On 23/02/2024 13:51, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
On 23/02/2024 12:02, Neil Armstrong wrote:
Thanks, Applied to https://anongit.fre
On Sat, 10 Feb 2024 17:16:17 +0100, Duje Mihanović wrote:
> The struct containing the KTD2801 timing can be made static as it's not
> referenced outside the KTD2801 driver. Do this to prevent sparse
> complaints.
>
>
Applied, thanks!
[1/1] backlight: ktd2801: make timing struct static
com
On Fri, Feb 23, 2024 at 03:38:13PM +0100, Neil Armstrong wrote:
> On 23/02/2024 15:21, Johan Hovold wrote:
> > But it is *not* standalone as I tried to explain above.
> >
> > So you have to drop it again as the later patches depend on it and
> > cannot be merged (through a different tree) without
On 17/02/2024 16:02, Johan Hovold wrote:
Starting with 6.8-rc1 the internal display sometimes fails to come up on
machines like the Lenovo ThinkPad X13s and the logs indicate that this
is due to a regression in the DRM subsystem [1].
This series fixes a race in the pmic_glink_altmode driver whic
On 23/02/2024 15:52, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 03:38:13PM +0100, Neil Armstrong wrote:
On 23/02/2024 15:21, Johan Hovold wrote:
But it is *not* standalone as I tried to explain above.
So you have to drop it again as the later patches depend on it and
cannot be merged (throu
From: Thierry Reding
Tegra DRM doesn't support display on Tegra234 and later, so make sure
not to remove any existing framebuffers in that case.
v2: - add comments explaining how this situation can come about
- clear DRIVER_MODESET and DRIVER_ATOMIC feature bits
Signed-off-by: Thierry Redin
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
> Starting with 6.8-rc1 the internal display sometimes fails to come up on
> machines like the Lenovo ThinkPad X13s and the logs indicate that this
> is due to a regression in the DRM subsystem [1].
>
> This series fixes a race in the pmic_gl
On Fri, 23 Feb 2024 at 16:55, Neil Armstrong wrote:
>
> On 23/02/2024 15:52, Johan Hovold wrote:
> > On Fri, Feb 23, 2024 at 03:38:13PM +0100, Neil Armstrong wrote:
> >> On 23/02/2024 15:21, Johan Hovold wrote:
> >
> >>> But it is *not* standalone as I tried to explain above.
> >>>
> >>> So you ha
On 2/22/2024 6:06 PM, Jeff Johnson wrote:
MHI allows the channel configs to be const, so constify
aic100_channels to prevent runtime modification.
Signed-off-by: Jeff Johnson
Reviewed-by: Jeffrey Hugo
I plan to apply to drm-misc-next before the rc6 freeze.
From: Paul Cercueil
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
With this new interface, DMABUF objects (externally created) can be
attached to a IIO buffer, and subsequently used for data transfer.
A userspace application can then use this
Thierry Reding writes:
Hello Thierry,
> From: Thierry Reding
>
> Tegra DRM doesn't support display on Tegra234 and later, so make sure
> not to remove any existing framebuffers in that case.
>
> v2: - add comments explaining how this situation can come about
> - clear DRIVER_MODESET and DRI
On February 22, 2024 8:29:28 PM PST, kernel test robot wrote:
>tree/branch:
>https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>branch HEAD: e31185ce00a9623230838db193416ceb9769 Add linux-next specific
>files for 20240222
>
>Error/Warning reports:
>
>https://lore
With the x86_64_defconfig I see the following when building drm-misc-next:
CC drivers/gpu/drm/i915/display/intel_crt.o
CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
CC drivers/gpu/drm/i915/display/intel_ddi.o
CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
CC
On Fri, 16 Feb 2024 22:15:42 +0100, Duje Mihanović wrote:
> LEDS_EXPRESSWIRE does not depend on NEW_LEDS in practice but still does
> in Kconfig. Fix up its Kconfig entry to reflect this and fix a Kconfig
> warning.
>
>
Applied, thanks!
[1/2] Revert "leds: Only descend into leds directory when
On Fri, 2024-02-23 at 07:46 -0800, Kees Cook wrote:
> > arch/sh/boot/compressed/../../../../lib/decompress_unxz.c:350:(.text+0x20b4):
> > undefined reference to `__ubsan_handle_out_of_bounds'
> > sh4-linux-ld:
> > arch/sh/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:751:(.text+0x904):
> > u
On 2/22/2024 6:06 PM, Jeff Johnson wrote:
MHI allows the channel configs to be const, so constify
aic100_channels to prevent runtime modification.
Signed-off-by: Jeff Johnson
Applied to drm-misc-next
-Jeff
On Tue, 20 Feb 2024 15:35:27 +, Daniel Thompson wrote:
> props is stack allocated and, although this driver initializes all the
> fields that are not "owned" by the framework, we'd still like to ensure
> it is zeroed to avoid problems from this driver if the fields change.
>
>
Applied, thank
On Fri, 02 Feb 2024 11:01:51 -0700, Jeffrey Hugo wrote:
> Bjorn is no longer at Linaro. Update his email address to @kernel to
> match the .mailmap entry.
>
> The servers for @codeaurora are long retired and messages sent there
> will bounce. Update Kiran's email address to match the .mailmap en
On Tue, 20 Feb 2024, Daniel Thompson wrote:
> [Sorry for the RESEND so soon... embarrassingly I got Lee's e-mail
> address wrong the first time!]
>
> Luca Weiss recently shared a patch to zero the properties structure for
> lm3630a... and shortly afterwards I realized I should probably scan for
On 2024-02-23 11:04, Michel Dänzer wrote:
> On 2024-02-23 10:34, Christian König wrote:
>> Am 23.02.24 um 09:11 schrieb Michel Dänzer:
>>> On 2024-02-23 08:06, Christian König wrote:
Am 22.02.24 um 18:28 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> Pinning the BO storage to VR
On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
> With the x86_64_defconfig I see the following when building drm-misc-next:
>
> CC drivers/gpu/drm/i915/display/intel_crt.o
> CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
> CC drivers/gpu/drm/i915/display/intel_
On Fri, Feb 23, 2024 at 10:14:53AM +1000, Dave Airlie wrote:
> On Fri, 23 Feb 2024 at 00:45, Danilo Krummrich wrote:
> >
> > Using the kernel global workqueue to signal fences can lead to
> > unexpected deadlocks. Some other work (e.g. from a different driver)
> > could directly or indirectly depe
On Tue, 20 Feb 2024 00:11:18 +0100, Luca Weiss wrote:
> On the MSM8974 Nexus 5 and OnePlus One phones (latter doesn't have
> display upstream) the display backlight was turning off whenever you
> would write a brightness to sysfs since a recent commit to the driver
> (kernel v6.5).
>
> backlight
On Wed, 21 Feb 2024, Manikandan Muralidharan wrote:
> From: Durai Manickam KR
>
> The register address of the XLCDC IP used in SAM9X7 SoC family
> are different from the previous HLCDC. Defining those address
> space with valid macros.
>
> Signed-off-by: Durai Manickam KR
> [manikanda...@micro
1 - 100 of 169 matches
Mail list logo
