Dynamically change enumeration list of DRM enumeration property

Hi, Is it possible to dynamically change enumeration list of DRM enumeration property ? Motivation behind this question is to understand whether it is possible to create connector enum property (e.g a property which will list supported output encodings - like yuv420, yuv422 etc) whose list of

Re: mmotm 2020-05-25-16-56 uploaded (drm/nouveau)

On Tue, 26 May 2020 at 13:50, Randy Dunlap wrote: > > On 5/25/20 4:57 PM, Andrew Morton wrote: > > The mm-of-the-moment snapshot 2020-05-25-16-56 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > >

Re: [PATCH 15/21] drm/rcar-du: Use GEM CMA object functions

Hi Thomas, On Mon, May 25, 2020 at 02:49:46PM +0200, Thomas Zimmermann wrote: > Am 22.05.20 um 22:12 schrieb Laurent Pinchart: > > On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote: > >> The rcar-du driver uses the default implementation for CMA functions; > >> except for the

[PATCH 19/27] drm: bridge: dw-hdmi: Split connector creation to a separate function

Isolate all the code related to connector creation to a new dw_hdmi_connector_create() function, to prepare for making connector creation optional. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 107 +- 1 file changed, 62 insertions(+), 45

[PATCH 26/27] drm: rcar-du: Use drm_bridge_connector_init() helper

Use the drm_bridge_connector_init() helper to create a drm_connector for each output, instead of relying on the bridge drivers doing so. Attach the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct them not to create a connector. Signed-off-by: Laurent Pinchart ---

[PATCH 24/27] drm: rcar-du: dw-hdmi: Set output port number

Report the DT output port number in dw_hdmi_plat_data to connect to the next bridge in the dw-hdmi driver. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c

[PATCH 10/27] drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()

When validating a mode, bridges may need to do so in the context of a display, as specified by drm_display_info. An example is the meson dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to perform clock calculations. Bridges that need the display info currently retrieve it from

[PATCH 21/27] drm: bridge: dw-hdmi: Pass drm_connector to internal functions as needed

To prepare for making connector creation optional in the driver, pass the drm_connector explicitly to the internal functions that require it. The functions that still access the connector from the dw_hdmi structure are dw_hdmi_connector_create() and __dw_hdmi_probe(). The former access is

[PATCH 27/27] drm: Add default modes for connectors in unknown state

The DRM CRTC helpers add default modes to connectors in the connected state if no mode can be retrieved from the connector. This behaviour is useful for VGA or DVI outputs that have no connected DDC bus. However, in such cases, the status of the output usually can't be retrieved and is reported as

[PATCH 18/27] drm: bridge: dw-hdmi: Pass drm_display_info to dw_hdmi_support_scdc()

To prepare for making connector creation optional in the driver, pass the drm_display_info explicitly to dw_hdmi_support_scdc(). The pointer is passed to the callers where required, particularly to the dw_hdmi_phy_ops .init() function. Signed-off-by: Laurent Pinchart ---

[PATCH 17/27] drm: bridge: dw-hdmi: Constify mode argument to internal functions

Several internal functions take a drm_display_mode argument to configure the HDMI encoder or the HDMI PHY. They must not modify the mode, make the pointer const to enforce that. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +--- 1 file changed, 5

[PATCH 22/27] drm: bridge: dw-hdmi: Make connector creation optional

Implement the drm_bridge_funcs .detect() and .get_edid() operations, and call drm_bridge_hpd_notify() notify to report HPD. This provides the necessary API to support disabling connector creation, do so by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in dw_hdmi_bridge_attach(). Signed-off-by: Laurent

[PATCH 23/27] drm: bridge: dw-hdmi: Attach to next bridge if available

On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings require a video output port connected to an HDMI sink (most likely an HDMI connector, in rare cases another bridges converting HDMI to another protocol). For those platforms, retrieve the next bridge and attach it from the dw-hdmi

[PATCH 15/27] drm: bridge: dw-hdmi: Pass drm_display_info to .mode_valid()

Replace the drm_connector pointer passed to the .mode_valid() function with a const drm_display_info pointer, as that's all the function should need. Use the display info passed to the bridge .mode_valid() operation instead of retrieving it from the connector, to prepare for make connector

[PATCH 25/27] drm: rcar-du: Fix error handling in rcar_du_encoder_init()

When attaching the bridge returns an error, the rcar_du_encoder_init() function calls drm_encoder_cleanup() manually instead of jumping to the error handling path that frees memory. Fix it. Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver") Signed-off-by: Laurent

[PATCH 11/27] drm: bridge: dw-hdmi: Pass private data pointer to .mode_valid()

Platform glue drivers for dw_hdmi may need to access device-specific data from their .mode_valid() implementation. They currently have no clean way to do so, and one driver hacks around it by accessing the dev_private data of the drm_device retrieved from the connector. Add a priv_data void

[PATCH 20/27] drm: bridge: dw-hdmi: Store current connector in struct dw_hdmi

Store the connector that the bridge is currently wired to in the dw_hdmi structure. This is currently identical to the connector field, but will differ once the driver supports disabling connector creation. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 18

[PATCH 07/27] drm: bridge: simple-bridge: Make connector creation optional

Make the connector creation optional to enable usage of the simple-bridge with the DRM bridge connector helper. Signed-off-by: Laurent Pinchart Acked-by: Sam Ravnborg --- drivers/gpu/drm/bridge/simple-bridge.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git

[PATCH 03/27] drm: bridge: adv7511: Implement bridge connector operations

Implement the bridge connector-related .get_edid(), .detect() and .hpd_notify() operations, and report the related bridge capabilities. Output status detection is implemented using the same backend as for the DRM connector, but requires making mode retrieval at detection time optional as no

[PATCH 16/27] drm: bridge: dw-hdmi: Constify mode argument to dw_hdmi_phy_ops .init()

The PHY .init() must not modify the mode it receives. Make the pointer const to enfore that. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-

[PATCH 01/27] drm: bridge: adv7511: Split EDID read to a separate function

To prepare for the implementation of the DRM bridge connector operations, move EDID read out of adv7511_get_modes() to a separate function. Signed-off-by: Laurent Pinchart Acked-by: Sam Ravnborg --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 23 ++-- 1 file changed, 16

[PATCH 14/27] drm: meson: dw-hdmi: Use dw_hdmi context to replace hack

The meson-dw-hdmi driver needs to access its own context from the .mode_valid() operation. It currently gets it from the dev_private field of the drm_device retrieved from the connector, which is a hack. Use the private data passed to the .mode_valid() operation instead. Signed-off-by: Laurent

[PATCH 13/27] drm: bridge: dw-hdmi: Remove unused field from dw_hdmi_plat_data

The input_bus_format field of struct dw_hdmi_plat_data is unused. Remove it. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 + include/drm/bridge/dw_hdmi.h | 1 - 2 files changed, 1 insertion(+), 5 deletions(-) diff --git

[PATCH 05/27] drm: bridge: Return NULL on error from drm_bridge_get_edid()

The drm_bridge_get_edid() function is documented to return an error pointer on error. The underlying .get_edid() operation, however, returns NULL on error, and so do the drm_get_edid() and drm_do_get_edid() functions upon which .get_edid() is usually implemented. Make drm_bridge_get_edid() return

[PATCH 06/27] drm: bridge: simple-bridge: Delegate operations to next bridge

Instead of poking into the DT node of the next bridge for its DDC bus and implementing the .get_modes() and .detect() connector operations manually, retrieve the next bridge in the chain and delegate these operations to it. Signed-off-by: Laurent Pinchart Acked-by: Sam Ravnborg --- Changes

[PATCH 08/27] drm: rcar-du: lvds: Convert to DRM panel bridge helper

Replace the manual panel handling with usage of the DRM panel bridge helper. This simplifies the driver, and brings support for DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 124 +++- 1 file

[PATCH 12/27] drm: bridge: dw-hdmi: Pass private data pointer to .configure_phy()

The .configure_phy() operation takes a dw_hdmi_plat_data pointer as a context argument. This differs from .mode_valid() that takes a custom private context pointer, causing possible confusion. Make the dw_hdmi_plat_data operations more consistent by passing the private context pointer to

[PATCH 00/27] Converter R-Car DU to the DRM bridge connector helper

Hello, This patch series converts the R-Car DU driver to use the DRM bridge connector helper drm_bridge_connector_init(). The bulk of the series is conversion of the adv7511, simple-bridge, rcar-lbds and dw-hdmi drivers to make connector creation optional (through the

[PATCH 02/27] drm: bridge: adv7511: Split connector creation to a separate function

To prepare for making the connector creation optional, move the related code out of adv7511_bridge_attach() to a separate function. Signed-off-by: Laurent Pinchart Acked-by: Sam Ravnborg --- Changes since v1: - Test for (ret < 0) instead of (ret) ---

[PATCH 09/27] drm: edid: Constify connector argument to infoframe functions

The drm_hdmi_avi_infoframe_from_display_mode(), drm_hdmi_vendor_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range() functions take a drm_connector that they don't modify. Mark it as const. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/drm_edid.c | 12 ++--

[PATCH 04/27] drm: bridge: adv7511: Make connector creation optional

Now that the driver supports all the connector-related bridge operations, make the connector creation optional. This enables usage of the adv7511 with the DRM bridge connector helper. Signed-off-by: Laurent Pinchart Acked-by: Sam Ravnborg --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13

[PATCH v2] drm/etnaviv: convert get_user_pages() --> pin_user_pages()

This code was using get_user_pages*(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a

[PATCH v2] tee: convert get_user_pages() --> pin_user_pages()

This code was using get_user_pages*(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a

Re: [PATCH 53/59] drm/arc: Move to drm/tiny

So, I've smoke tested it. Though it is working, it's really unstable and causes kernel crash in many cases. I.e: This kernel crash (due to invalid read in kernel mode by 0x007c address) happens on HDMI cable disconnection:

[pull] drm/msm: msm-next for 5.8

Hi Dave, Not too huge this time around, but a bunch of interesting new stuff: * new gpu support: a405, a640, a650 * dpu: clock and bandwidth scaling * dpu: color processing support * mdp5: support for msm8x36 (the thing with a405) * some prep work for per-context pagetables (ie the part

[Bug 207889] New: Unable to load nvidia package.

https://bugzilla.kernel.org/show_bug.cgi?id=207889 Bug ID: 207889 Summary: Unable to load nvidia package. Product: Drivers Version: 2.5 Kernel Version: 5.3.18-lp152.14.4(5.3.18-lp152.16.1) Hardware: All OS: Linux

Re: [PATCH 53/59] drm/arc: Move to drm/tiny

On Mon, May 25, 2020 at 6:36 PM Eugeniy Paltsev wrote: > > Hi Daniel, > > looks like I'll finally have some time for review of "drm/arc: Move to > drm/tiny". > So, is it possible to find all these changes in any public git repo? I have a horrible pile with everything here:

Re: [PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.

On Mon, May 25, 2020 at 5:34 PM Tetsuo Handa wrote: > > On 2020/05/26 0:21, Daniel Vetter wrote: > > On Mon, May 25, 2020 at 11:38:49PM +0900, Tetsuo Handa wrote: > >> Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by > >> hrtimers") introduced ret_overrun variable. And that

Re: [PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.

On Mon, May 25, 2020 at 5:34 PM Tetsuo Handa wrote: > > On 2020/05/26 0:21, Daniel Vetter wrote: > > On Mon, May 25, 2020 at 11:38:49PM +0900, Tetsuo Handa wrote: > >> Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by > >> hrtimers") introduced ret_overrun variable. And that

Re: Adaptive Sync enabling in Xorg Modesetting driver

On 2020-05-25 6:39 p.m., uday kiran pichika wrote: > Thanks for your quick check Michel. I had removed the condition in my local > source in ms_present_check_unflip() method and moved the assignment to > ms_present_check_flip() method. Below is the snippet. > > static Bool

Re: [PATCH 53/59] drm/arc: Move to drm/tiny

Hi Daniel, looks like I'll finally have some time for review of "drm/arc: Move to drm/tiny". So, is it possible to find all these changes in any public git repo? Thanks. --- Eugeniy Paltsev ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: Adaptive Sync enabling in Xorg Modesetting driver

Thanks for your quick check Michel. I had removed the condition in my local source in ms_present_check_unflip() method and moved the assignment to ms_present_check_flip() method. Below is the snippet. static Bool ms_present_check_flip(RRCrtcPtr crtc, WindowPtr window,

Re: Adaptive Sync enabling in Xorg Modesetting driver

On 2020-05-25 4:58 p.m., uday kiran pichika wrote: > Thanks Michel.. > > sorry if my description is not clear. > Yes I have used with glxgears in fullscreen mode and also a simple glxapp > which actually opens in fullscreen by default. > > In both the cases, the issue is same. > > Just wanted

Re: [RFC 02/17] dma-fence: basic lockdep annotations

On Tue, May 12, 2020 at 11:04 AM Chris Wilson wrote: > > Quoting Daniel Vetter (2020-05-12 09:59:29) > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > > this explicit

Re: [PATCH 15/21] drm/rcar-du: Use GEM CMA object functions

On 25/05/2020 13:49, Thomas Zimmermann wrote: > Hi > > Am 22.05.20 um 22:12 schrieb Laurent Pinchart: >> Hi Thomas, >> >> Thank you for the patch. >> >> On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote: >>> The rcar-du driver uses the default implementation for CMA functions; >>>

Re: [RFC 08/17] drm/scheduler: use dma-fence annotations in main thread

On Tue, May 12, 2020 at 11:00 AM Daniel Vetter wrote: > > If the scheduler rt thread gets stuck on a mutex that we're holding > while waiting for gpu workloads to complete, we have a problem. > > Add dma-fence annotations so that lockdep can check this for us. > > I've tried to quite carefully

Re: Adaptive Sync enabling in Xorg Modesetting driver

Hi Daniel, We are trying to enable this feature in the Modesetting driver based on AMD DDX driver as a reference. Do you have any pointers to make this work ? Thanks Uday Kiran On Mon, May 25, 2020 at 8:45 PM Daniel Vetter wrote: > On Mon, May 25, 2020 at 07:01:21PM +0530, uday kiran pichika

Re: Adaptive Sync enabling in Xorg Modesetting driver

Thanks for the input simon. Sway Compositor is based on the wayland protocol right !! But we are trying to do it through Xorg modesetting driver.. On Mon, May 25, 2020 at 8:50 PM Simon Ser wrote: > On Monday, May 25, 2020 5:15 PM, Daniel Vetter wrote: > > > On Mon, May 25, 2020 at 07:01:21PM

Re: Adaptive Sync enabling in Xorg Modesetting driver

On Monday, May 25, 2020 5:15 PM, Daniel Vetter wrote: > On Mon, May 25, 2020 at 07:01:21PM +0530, uday kiran pichika wrote: > > > Hello, > > Am working on enabling the Adaptive sync feature as part of the > > Xorg/Modesetting DDX driver by taking the reference of AMD DDX Driver > >

Re: [PATCH] drm/vkms: Don't warn hrtimer_forward_now failure.

On Mon, May 25, 2020 at 11:38:49PM +0900, Tetsuo Handa wrote: > Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by > hrtimers") introduced ret_overrun variable. And that variable was an > unused-but-set-variable until commit 09ef09b4ab95dc40 ("drm/vkms: > WARN when

Re: Adaptive Sync enabling in Xorg Modesetting driver

On Mon, May 25, 2020 at 07:01:21PM +0530, uday kiran pichika wrote: > Hello, > > Am working on enabling the Adaptive sync feature as part of the > Xorg/Modesetting DDX driver by taking the reference of AMD DDX Driver > (xf86-video-amdgpu). Below is the commit which i submitted. >

Re: [RESEND PATCH] drm/vc4: hdmi: Silence pixel clock error on -EPROBE_DEFER

On Sun, May 24, 2020 at 07:28:59PM -0600, James Hilliard wrote: > If the vc4 hdmi driver loads before the pixel clock is available we > see a spurious "*ERROR* Failed to get pixel clock" error. > > Signed-off-by: James Hilliard > --- > no response in over 2 weeks Thanks for poking again, not

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Mon, May 25, 2020 at 05:55:19PM +0300, Pekka Paalanen wrote: > On Mon, 25 May 2020 16:28:04 +0200 > Daniel Vetter wrote: > > > On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote: > > > > > > On 5/20/20 8:46 AM, Daniel Vetter wrote: > > > > On Wed, May 20, 2020 at 02:19:08PM

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

On Mon, 25 May 2020 16:30:17 +0200 Daniel Vetter wrote: > On Mon, May 25, 2020 at 09:51:30AM -0400, Andrey Grodzovsky wrote: > > On 5/25/20 8:46 AM, Pekka Paalanen wrote: > > > > > From: Pekka Paalanen > > > > > > Set up the expectations on how hot-unplugging a DRM device should look > > >

Re: Adaptive Sync enabling in Xorg Modesetting driver

Thanks Michel.. sorry if my description is not clear. Yes I have used with glxgears in fullscreen mode and also a simple glxapp which actually opens in fullscreen by default. In both the cases, the issue is same. Just wanted to know if AMD has done anything different apart from the

Re: MIPI DSI, DBI, and tinydrm drivers

Hi, On 24/05/2020 21:50, Paul Cercueil wrote: > Hi Daniel, > > Le dim. 24 mai 2020 à 20:35, Daniel Vetter a écrit : >> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote: >>> >>> >>> >>>  Den 24.05.2020 18.13, skrev Paul Cercueil: >>>  > Hi list, >>>  > >>>  > I'd like to open a discussion

Re: [PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4

On Mon, May 25, 2020 at 04:34:28PM +0200, Daniel Vetter wrote: > On Sat, May 23, 2020 at 11:49:07AM +0800, chenxb_99...@126.com wrote: > > From: Xuebing Chen > > > > The provides drm_for_each_plane_mask macro and > > plane_mask is defined as bitmask of plane indices, such as > > 1< > in

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Mon, 25 May 2020 16:28:04 +0200 Daniel Vetter wrote: > On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote: > > > > On 5/20/20 8:46 AM, Daniel Vetter wrote: > > > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote: > > > > On Tue, 19 May 2020 10:37:12 -0400 > >

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

On Mon, 25 May 2020 09:51:30 -0400 Andrey Grodzovsky wrote: > On 5/25/20 8:46 AM, Pekka Paalanen wrote: > > > From: Pekka Paalanen > > > > Set up the expectations on how hot-unplugging a DRM device should look like > > to > > userspace. > > > > Written by Daniel Vetter's request and largely

Re: [PATCH][next] drm/auth: remove redundant assignment to variable ret

On Sun, May 24, 2020 at 11:27:15PM +0100, Colin King wrote: > From: Colin Ian King > > The variable ret is being initialized with a value that is > never read and it is being updated later with a new value. The > initialization is redundant and can be removed. > > Addresses-Coverity: ("Unused

Re: [PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4

On Sat, May 23, 2020 at 11:49:07AM +0800, chenxb_99...@126.com wrote: > From: Xuebing Chen > > The provides drm_for_each_plane_mask macro and > plane_mask is defined as bitmask of plane indices, such as > 1< in pan_display_atomic() function. > > Signed-off-by: Xuebing Chen What kernel is

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

On Mon, May 25, 2020 at 09:51:30AM -0400, Andrey Grodzovsky wrote: > On 5/25/20 8:46 AM, Pekka Paalanen wrote: > > > From: Pekka Paalanen > > > > Set up the expectations on how hot-unplugging a DRM device should look like > > to > > userspace. > > > > Written by Daniel Vetter's request and

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Fri, May 22, 2020 at 12:54:32PM +0300, Pekka Paalanen wrote: > On Wed, 20 May 2020 16:19:00 +0200 > Daniel Vetter wrote: > > > On Wed, May 20, 2020 at 3:20 PM Simon Ser wrote: > > > > > > On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter wrote: > > > > > > > Maybe we should add an

Re: [PATCH] drm/doc: device hot-unplug for userspace

On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote: > > On 5/20/20 8:46 AM, Daniel Vetter wrote: > > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote: > > > On Tue, 19 May 2020 10:37:12 -0400 > > > Andrey Grodzovsky wrote: > > > > > > > Thanks for the summary, does

Re: [PATCH v2] drm: add docs for standard CRTC properties

On Thu, 21 May 2020 11:09:31 + Simon Ser wrote: > This patch adds docs for the ACTIVE and MODE_ID CRTC properties. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Michel Dänzer > Cc: Daniel Stone > --- > > Thanks for the review Daniel!

Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function

On 25/05/2020 12:38, Dennis-YC Hsieh wrote: > > On Mon, 2020-05-25 at 10:39 +0200, Matthias Brugger wrote: >> >> On 25/05/2020 04:27, Dennis-YC Hsieh wrote: >>> >>> On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote: On 24/05/2020 19:31, Dennis-YC Hsieh wrote: > Hi

Re: Adaptive Sync enabling in Xorg Modesetting driver

On 2020-05-25 3:31 p.m., uday kiran pichika wrote: > Hello, > > Am working on enabling the Adaptive sync feature as part of the > Xorg/Modesetting DDX driver by taking the reference of AMD DDX Driver > (xf86-video-amdgpu). Below is the commit which i submitted. >

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

On 5/25/20 8:46 AM, Pekka Paalanen wrote: From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from

Adaptive Sync enabling in Xorg Modesetting driver

Hello, Am working on enabling the Adaptive sync feature as part of the Xorg/Modesetting DDX driver by taking the reference of AMD DDX Driver (xf86-video-amdgpu). Below is the commit which i submitted. https://gitlab.freedesktop.org/pichika/xserver/-/commit/682565a645bda7371cc3731ee805cc4a0ace80db

Re: [PATCH 12/21] drm/mcde: Use GEM CMA object functions

Hi Am 25.05.20 um 15:08 schrieb Linus Walleij: > On Mon, May 25, 2020 at 2:51 PM Thomas Zimmermann wrote: >> Am 25.05.20 um 13:36 schrieb Linus Walleij: >>> On Fri, May 22, 2020 at 3:52 PM Thomas Zimmermann >>> wrote: >>> The mcde driver uses the default implementation for CMA functions.

Re: MIPI DSI, DBI, and tinydrm drivers

Den 25.05.2020 04.05, skrev Paul Cercueil: > > > Le lun. 25 mai 2020 à 2:46, Noralf Trønnes a écrit : >> >> >> Den 24.05.2020 23.33, skrev Paul Cercueil: >>> >>> >>>  Le dim. 24 mai 2020 à 23:24, Noralf Trønnes a >>> écrit :  Den 24.05.2020 22.42, skrev Paul Cercueil: >

Re: [PATCH 12/21] drm/mcde: Use GEM CMA object functions

On Mon, May 25, 2020 at 2:51 PM Thomas Zimmermann wrote: > Am 25.05.20 um 13:36 schrieb Linus Walleij: > > On Fri, May 22, 2020 at 3:52 PM Thomas Zimmermann > > wrote: > > > >> The mcde driver uses the default implementation for CMA functions. The > >> DRM_GEM_CMA_DRIVER_OPS macro now sets

Re: [PATCH 12/21] drm/mcde: Use GEM CMA object functions

Hi Am 25.05.20 um 13:36 schrieb Linus Walleij: > On Fri, May 22, 2020 at 3:52 PM Thomas Zimmermann wrote: > >> The mcde driver uses the default implementation for CMA functions. The >> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver. >> All remaining operations are

Re: [PATCH 15/21] drm/rcar-du: Use GEM CMA object functions

Hi Am 22.05.20 um 22:12 schrieb Laurent Pinchart: > Hi Thomas, > > Thank you for the patch. > > On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote: >> The rcar-du driver uses the default implementation for CMA functions; >> except for the .dumb_create callback. The

[PATCH v2] drm/doc: device hot-unplug for userspace

From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . Signed-off-by: Pekka

Re: [PATCH 07/21] drm/hisilicon/kirin: Use GEM CMA object functions

Hi Emil Am 22.05.20 um 20:11 schrieb Emil Velikov: > Hi Thomas, > > On Fri, 22 May 2020 at 14:53, Thomas Zimmermann wrote: >> >> The kirin driver uses the default implementation for CMA functions; except >> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets >> these

Re: [PATCH 05/21] drm/atmel-hlcdc: Use GEM CMA object functions

Hi Am 22.05.20 um 21:25 schrieb Sam Ravnborg: > Hi Thomas. > > On Fri, May 22, 2020 at 03:52:30PM +0200, Thomas Zimmermann wrote: >> The atmel-hlcdc driver uses the default implementation for CMA functions. The >> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver. >> All

Re: [PATCH v5 6/8] drm/panel: Add ilitek ili9341 panel driver

On Mon, May 25, 2020 at 5:46 AM wrote: > From: dillon min > > This driver combine tiny/ili9341.c mipi_dbi_interface driver > with mipi_dpi_interface driver, can support ili9341 with serial > mode or parallel rgb interface mode by register configuration. > > Changes since V3: > >

[Bug 201957] amdgpu: ring gfx timeout

https://bugzilla.kernel.org/show_bug.cgi?id=201957 udo (udo...@xs4all.nl) changed: What|Removed |Added CC||udo...@xs4all.nl --- Comment

Re: [PATCH v5 4/8] dt-bindings: display: panel: Add ilitek ili9341 panel bindings

On Mon, May 25, 2020 at 5:46 AM wrote: > From: dillon min > > Add documentation for "ilitek,ili9341" panel. > > Signed-off-by: dillon min This looks good to me! Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list

Re: [PATCH] drm/doc: device hot-unplug for userspace

Ping on the question bellow Andrey On 5/20/20 10:50 AM, Andrey Grodzovsky wrote: On 5/20/20 8:46 AM, Daniel Vetter wrote: On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote: On Tue, 19 May 2020 10:37:12 -0400 Andrey Grodzovsky wrote: Thanks for the summary, does put things in

Re: [PATCH 05/21] drm/atmel-hlcdc: Use GEM CMA object functions

Hi Am 22.05.20 um 20:08 schrieb Sam Ravnborg: > Hi Thomas. > > On Fri, May 22, 2020 at 03:52:30PM +0200, Thomas Zimmermann wrote: >> The atmel-hlcdc driver uses the default implementation for CMA functions. The >> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver. >> All

Re: [PATCH 01/21] drm/cma-helper: Rework DRM_GEM_CMA_VMAP_DRIVER_OPS macro

Hi Sam Am 22.05.20 um 19:48 schrieb Sam Ravnborg: > Hi Thomas. > > On Fri, May 22, 2020 at 03:52:26PM +0200, Thomas Zimmermann wrote: >> Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM >> helpers. > This part is fine, I like that the naming is somehow consistent. > >> An internal

Re: [PATCH v4 3/8] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4

On Sat, May 23, 2020 at 09:35:06AM +0800, dillon min wrote: > - if (ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) { > + if ((ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) > && > + !(msg->spi->mode & SPI_3WIRE)) { >

Re: [PATCH 20/21] drm/tv200: Use GEM CMA object functions

On Fri, May 22, 2020 at 3:53 PM Thomas Zimmermann wrote: > The tve200 driver uses the default implementation for CMA functions. The > DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver. > All remaining operations are provided by CMA GEM object functions. > > Signed-off-by:

Re: [PATCH 12/21] drm/mcde: Use GEM CMA object functions

On Fri, May 22, 2020 at 3:52 PM Thomas Zimmermann wrote: > The mcde driver uses the default implementation for CMA functions. The > DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver. > All remaining operations are provided by CMA GEM object functions. > > Signed-off-by:

Re: [PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats

Hi, On 2020-05-15 15:37, Brian Starkey wrote: > Hi Ben, > > On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote: >> Hi all, any feedback on this patch? >> Thanks, Ben >> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote: >>> DRM_FORMAT_NV15 is a 2 plane format suitable for linear

Re: [PATCH v1 0/2] drm: update drm_vblank logging

Hi Sam Am 23.05.20 um 09:12 schrieb Sam Ravnborg: > Replace all logging functions in vblank with their drm_ counterparts. > As cocinelle and I are not yet good friends this was a pure mechanical > replacement. > > It adds more lines because the added argument required some more lines > to be

Re: [PATCH v1 1/2] drm/vblank: use drm_* functions for logging

Hi Am 23.05.20 um 09:12 schrieb Sam Ravnborg: > Replace all DRM_* logging functions with their drm_ counterparts. > checkpatch emits a few "quoted string split across lines", > which is left as is. The strings was already split in the original code > base and it would not increase readability to

Re: [PATCH v2 01/16] video: amba-clcd: use devm_of_find_backlight

Hi Linus. > For this driver (drivers/video/fbdev/amba-clcd.c) there are zero > users after the merge window (all users moved over to DRM) so > I plan to retire it completely. Sounds like a brilliant plan. Sam ___ dri-devel mailing list

Re: [PATCH v5 10/13] soc: mediatek: cmdq: export finalize function

Hi, Matthias: Matthias Brugger 於 2020年5月25日 週一 下午4:38寫道： > > > > On 25/05/2020 02:23, Chun-Kuang Hu wrote: > > Hi, Matthias: > > > > Matthias Brugger 於 2020年5月17日 週日 上午2:22寫道： > >> > >> > >> > >> On 08/03/2020 11:52, Dennis YC Hsieh wrote: > >>> Export finalize function to client which helps

Re: [PATCH v2] drm/fourcc: Add bayer formats and modifiers

Hi Niklas, Thank you for the update. On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote: > Bayer formats are used with cameras and contain green, red and blue > components, with alternating lines of red and green, and blue and green > pixels in different orders. For each block of

Re: MIPI DSI, DBI, and tinydrm drivers

Den 24.05.2020 20.35, skrev Daniel Vetter: > On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote: >> >> >> >> Den 24.05.2020 18.13, skrev Paul Cercueil: >>> Hi list, >>> >>> I'd like to open a discussion about the current support of MIPI DSI and >>> DBI panels. >>> >>> Both are standards from

Re: [PATCH v2 01/16] video: amba-clcd: use devm_of_find_backlight

On Mon, May 18, 2020 at 12:16 PM Sam Ravnborg wrote: > Hi Linus. > > On Mon, May 18, 2020 at 10:10:12AM +0200, Linus Walleij wrote: > > On Sun, May 17, 2020 at 9:01 PM Sam Ravnborg wrote: > > > > > Look up backlight device using devm_of_find_backlight(). > > > This simplifies the code and

Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function

On 25/05/2020 04:27, Dennis-YC Hsieh wrote: > > On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote: >> >> On 24/05/2020 19:31, Dennis-YC Hsieh wrote: >>> Hi Matthias, >>> >>> Thanks for your comment. >>> >>> On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote: On

Re: [PATCH v5 10/13] soc: mediatek: cmdq: export finalize function

On 25/05/2020 02:23, Chun-Kuang Hu wrote: > Hi, Matthias: > > Matthias Brugger 於 2020年5月17日 週日 上午2:22寫道： >> >> >> >> On 08/03/2020 11:52, Dennis YC Hsieh wrote: >>> Export finalize function to client which helps append eoc and jump >>> command to pkt. Let client decide call finalize or not.

[PATCH v5 4/8] dt-bindings: display: panel: Add ilitek ili9341 panel bindings

From: dillon min Add documentation for "ilitek,ili9341" panel. Signed-off-by: dillon min --- .../bindings/display/panel/ilitek,ili9341.yaml | 69 ++ 1 file changed, 69 insertions(+) create mode 100644

Re: [PATCH v4 1/2] mtd: rawnand: brcmnand: fix hamming oob layout

On Tue, 2020-05-12 at 07:57:32 UTC, =?utf-8?q?=C3=81lvaro_Fern=C3=A1ndez_Rojas?= wrote: > First 2 bytes are used in large-page nand. > > Fixes: ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops") > Cc: sta...@vger.kernel.org > Signed-off-by: Álvaro Fernández Rojas Applied to

[PATCH v5 3/8] ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on stm32429-disco board

From: dillon min Enable the ltdc & ili9341, gyro l3gd20 on stm32429-disco board. Signed-off-by: dillon min --- arch/arm/boot/dts/stm32f429-disco.dts | 48 +++ 1 file changed, 48 insertions(+) diff --git a/arch/arm/boot/dts/stm32f429-disco.dts

Re: [PATCH v4 4/5] dt: bindings: brcmnand: add v2.1 and v2.2 support

Álvaro Fernández Rojas wrote on Sun, 24 May 2020 21:13:41 +: > Thanks for merging the patches :). > > BTW, is there something wrong with patch 5? > I can see patches 1-4 applied in > https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/log/?h=nand/next, > but I can’t see patch

  1   2   >