Hi Sam,
Thanks for the feedback.
> Subject: Re: [PATCH v4 1/2] dt-bindings: display: bridge: Document
> RZ/G2L MIPI DSI TX bindings
>
> Hi Biju,
>
> On Fri, Jul 22, 2022 at 08:19:23PM +0100, Biju Das wrote:
> > The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's.
> > It can
Currently the driver only handles panel directly connected to the DPI output.
Handle the case where a bridge is connected past DPI output of this bridge.
This could be e.g. DPI to LVDS encoder chip.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime
On 7/24/22 22:10, Dmitry Baryshkov wrote:
> On Sun, 24 Jul 2022 at 22:51, Javier Martinez Canillas
> wrote:
>>
>> On 7/24/22 20:47, Javier Martinez Canillas wrote:
>>> Hello Dmitry,
>>
>> [...]
>>
Now there is no point in having this as a separate function. Could you
>>>
>>> The only reason
On Sun, 24 Jul 2022 at 22:51, Javier Martinez Canillas
wrote:
>
> On 7/24/22 20:47, Javier Martinez Canillas wrote:
> > Hello Dmitry,
>
> [...]
>
> >> Now there is no point in having this as a separate function. Could you
> >
> > The only reason why I kept this was to avoid duplicating the same
On 7/24/22 20:47, Javier Martinez Canillas wrote:
> Hello Dmitry,
[...]
>> Now there is no point in having this as a separate function. Could you
>
> The only reason why I kept this was to avoid duplicating the same comment
> in two places. I thought that an inline function would be better than
Hello Dmitry,
Thanks for your feedback.
On 7/24/22 20:36, Dmitry Baryshkov wrote:
> On Sun, 24 Jul 2022 at 14:13, Javier Martinez Canillas
> wrote:
[...]
>>
>> +/*
>> + * Shutdown the hw if we're far enough along where things might be on.
>> + * If we run this too early, we'll end up
Hello Thomas,
Thanks for your feedback.
On 7/24/22 20:24, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 24.07.22 um 14:37 schrieb Javier Martinez Canillas:
>> DRM drivers initialize the mode configuration with drmm_mode_config_init()
>> and that function (among other things) initializes mutexes
On 7/24/2022 1:42 PM, Jason Wang wrote:
The double `be' is duplicated in the comment, remove one.
Signed-off-by: Jason Wang
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
1 file changed, 1
On Sun, 24 Jul 2022 at 14:13, Javier Martinez Canillas
wrote:
>
> Drivers' .remove and .shutdown callbacks are executed on different code
> paths. The former is called when a device is removed from the bus, while
> the latter is called at system shutdown time to quiesce the device.
>
> This means
Hi Javier
Am 24.07.22 um 14:37 schrieb Javier Martinez Canillas:
DRM drivers initialize the mode configuration with drmm_mode_config_init()
and that function (among other things) initializes mutexes that are later
used by modeset helpers.
But the helpers should only attempt to grab those locks
https://bugzilla.kernel.org/show_bug.cgi?id=216277
--- Comment #2 from dark_syl...@yahoo.com.ar ---
Created attachment 301480
--> https://bugzilla.kernel.org/attachment.cgi?id=301480=edit
Xorg log when it succeeds
--
You may reply to this email to add a comment.
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=216277
--- Comment #1 from dark_syl...@yahoo.com.ar ---
Created attachment 301479
--> https://bugzilla.kernel.org/attachment.cgi?id=301479=edit
Xorg log when it fails
--
You may reply to this email to add a comment.
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=216277
Bug ID: 216277
Summary: X11 doesn't wait for amdgpu driver to be up
Product: Drivers
Version: 2.5
Kernel Version: 5.18.11+
Hardware: All
OS: Linux
Tree:
DRM drivers initialize the mode configuration with drmm_mode_config_init()
and that function (among other things) initializes mutexes that are later
used by modeset helpers.
But the helpers should only attempt to grab those locks if the mode config
was properly initialized. Otherwise it can lead
Drivers' .remove and .shutdown callbacks are executed on different code
paths. The former is called when a device is removed from the bus, while
the latter is called at system shutdown time to quiesce the device.
This means that some overlap exists between the two, because both have to
take care
Hi Uwe,
On Sun, Jul 24, 2022 at 11:40:22AM +0200, Sam Ravnborg wrote:
> Hi Uwe,
>
> On Sun, Jul 24, 2022 at 12:02:18AM +0200, Uwe Kleine-König wrote:
> > Hi Sam,
> >
> > On Sat, Jul 23, 2022 at 09:23:43PM +0200, Sam Ravnborg wrote:
> > > On Sat, Jul 23, 2022 at 07:57:17PM +0200, Uwe
Hi Uwe,
On Sun, Jul 24, 2022 at 12:02:18AM +0200, Uwe Kleine-König wrote:
> Hi Sam,
>
> On Sat, Jul 23, 2022 at 09:23:43PM +0200, Sam Ravnborg wrote:
> > On Sat, Jul 23, 2022 at 07:57:17PM +0200, Uwe Kleine-König wrote:
> > > No source file but the driver itself includes the header containing
On 7/24/22 11:06, Javier Martinez Canillas wrote:
[...]
>
> I guess one option is to do the if (dev->registered) check in the callers but
> then it won't really be worth it to have a helper and we could just add that
> check in msm_drv_shutdown() to conditionally call
>
On 7/24/22 10:53, Dmitry Baryshkov wrote:
> On Sun, 24 Jul 2022 at 00:09, Javier Martinez Canillas
[...]
>> -
>> /*
>> * Shutdown the hw if we're far enough along where things might be
>> on.
>> * If we run this too early, we'll end up panicking in any variety of
>> @@
On Sun, 24 Jul 2022 at 00:09, Javier Martinez Canillas
wrote:
>
> Drivers' .remove and .shutdown callbacks are executed on different code
> paths. The former is called when a device is removed from the bus, while
> the latter is called at system shutdown time to quiesce the device.
>
> This means
20 matches
Mail list logo
