On Tue, May 26, 2020 at 6:31 AM Yogish Kulkarni
wrote:
>
> 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
>
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
su
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:
> >
> > http://www
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 .dumb
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 del
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
---
drivers/gpu/drm
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
b/drivers/gpu/drm/rcar
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 th
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 expected,
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
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
---
drivers/gpu/drm/bridge/s
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 insertio
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
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 b
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 creation
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 Pinc
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 pointe
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 ++
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 a/drive
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 pointe
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 +-
drivers/g
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 inser
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 Pin
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 a/drivers/gpu/drm/bri
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 N
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 since
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 cha
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 .configure
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 DRM_BRIDGE_ATTACH_NO_CONNECT
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)
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.
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 ++--
includ
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 ++
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
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
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:
--->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 that
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
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:
https://cgit.freedesk
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 varia
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 varia
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 ms_present_check_flip(RR
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
ht
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,
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 to
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 annotation
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;
>>>
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 rev
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 w
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 +
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
> > (xf86-video-am
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 hrtimer_forward_n
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.
> https://gitlab.fr
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 sur
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 +
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
> > >
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
configuration
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 ab
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 pan_disp
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
> > >
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 ba
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 va
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 this
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 lar
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 explicit
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 p
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! I
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 Matthias
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.
> https://gitlab.freedesktop.org/pic
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
https://nam11.safelinks.protection.outlook.com/?url=ht
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
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. T
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:
>
>>>
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 these
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 prov
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 __DRM_GEM_CMA_D
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 Paalan
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 defau
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 r
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:
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=201957
udo (udo...@xs4all.nl) changed:
What|Removed |Added
CC||udo...@xs4all.nl
--- Comment #33
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
dri-devel@li
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 o
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 r
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
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)) {
> ma
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:
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: Th
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 an
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 divi
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 f
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
dri-deve
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 app
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 2x
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 t
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 prevent
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 08/03/20
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.
>>>
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
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
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 https://g
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
b/arch/arm/boot/d
1 - 100 of 156 matches
Mail list logo