Hi,
On Thu, May 5, 2022 at 3:15 PM Dmitry Baryshkov
wrote:
>
> On 06/05/2022 00:24, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, May 5, 2022 at 1:56 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Thu, May 5, 2022 at 1:10
On 06/05/2022 00:24, Doug Anderson wrote:
Hi,
On Thu, May 5, 2022 at 1:56 PM Dmitry Baryshkov
wrote:
On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
Hi,
On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
wrote:
On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
Hi,
On Thu, May 5, 202
On Thu, May 5, 2022 at 2:41 PM Jessica Zhang wrote:
>
> There is a possibility for mdp5_get_global_state to return
> -EDEADLK when acquiring the modeset lock, but currently global_state in
> mdp5_mixer_release doesn't check for if an error is returned.
>
> To avoid a NULL dereference error, let's
On Thu, May 5, 2022 at 2:41 PM Jessica Zhang wrote:
>
> mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
> the modeset lock, but currently mdp5_pipe_release doesn't check for if
> an error is returned. Because of this, there is a possibility of
> mdp5_pipe_release hitting a
There is a possibility for mdp5_get_global_state to return
-EDEADLK when acquiring the modeset lock, but currently global_state in
mdp5_mixer_release doesn't check for if an error is returned.
To avoid a NULL dereference error, let's have mdp5_mixer_release
check if an error is returned and propag
mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
the modeset lock, but currently mdp5_pipe_release doesn't check for if
an error is returned. Because of this, there is a possibility of
mdp5_pipe_release hitting a NULL dereference error.
To avoid this, let's have mdp5_pipe_r
Hi,
On Thu, May 5, 2022 at 1:56 PM Dmitry Baryshkov
wrote:
>
> On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
> > > >
> > > > Hi,
> > > >
> > > > On T
On Thu, 5 May 2022 at 23:21, Doug Anderson wrote:
>
> Hi,
>
> On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
> wrote:
> >
> > On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Thu, May 05,
Hi,
On Thu, May 5, 2022 at 1:10 PM Dmitry Baryshkov
wrote:
>
> On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> > wrote:
> > >
> > > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On
Hi,
On Thu, May 5, 2022 at 12:19 PM Ville Syrjälä
wrote:
>
> On Thu, May 05, 2022 at 08:53:12AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> > wrote:
> > >
> > > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > >
On Thu, 5 May 2022 at 18:53, Doug Anderson wrote:
>
> Hi,
>
> On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> wrote:
> >
> > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Wed, May 0
So I think if Ville is OK with it (an ack at least) I'm fine with this
documentation change. I think it's worth me noting for other reviewers I made
this decision based on the fact that the documentation is for the transfer()
function - which I agree shouldn't need to be responsible for powering th
On Thu, May 05, 2022 at 08:53:12AM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
> wrote:
> >
> > On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On
Quoting Sankeerth Billakanti (QUIC) (2022-05-05 11:47:20)
> >Quoting Sankeerth Billakanti (2022-05-05 11:02:36)
> >>
> >> Our internal power grid documents list the regulators as VDD_A_*_1P2
> >> and VDD_A_*_0P9 for all the platforms.
> >
> >Do your internal power grid documents indicate what these
>We're supposed to list the supplies in the dt bindings but there are none in
>the eDP PHY bindings.
>
>Looking at the driver in Linux, I can see that there seem to be two relevant
>supplies: "vdda-phy" and "vdda-pll". Let's add those to the bindings.
>
>NOTE: from looking at the Qualcomm datasheet
>Quoting Sankeerth Billakanti (2022-05-05 11:02:36)
>> >>
>> >> Quoting Douglas Anderson (2022-04-25 14:06:42)
>> >>
>> >> Having 'a' in 'vdda' typically means 'analog' for 'analog'
>> >> circuits, so I'd expect this to only matter for the phy that
>> >> contains the analog circuitry. It would be g
Quoting Sankeerth Billakanti (2022-05-05 11:02:36)
> >>
> >> Quoting Douglas Anderson (2022-04-25 14:06:42)
> >>
> >> Having 'a' in 'vdda' typically means 'analog' for 'analog' circuits,
> >> so I'd expect this to only matter for the phy that contains the analog
> >> circuitry. It would be great to
Hi Doug,
>>
>> Quoting Douglas Anderson (2022-04-25 14:06:42)
>> > We're supposed to list the supplies in the dt bindings but there are
>> > none in the DP controller bindings. Looking at the Linux driver and
>> > existing device trees, we can see that two supplies are expected:
>> > - vdda-0p9-su
On 5/5/2022 1:48 AM, Dmitry Baryshkov wrote:
On Thu, 5 May 2022 at 05:06, Rob Clark wrote:
On Wed, May 4, 2022 at 6:55 PM Jessica Zhang wrote:
mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
the modeset lock, but currently mdp5_pipe_release doesn't check for if
a
Hi,
On Thu, May 5, 2022 at 8:29 AM Ville Syrjälä
wrote:
>
> On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
> > wrote:
> > >
> > > On Wed, May 04, 2022 at 02:10:08PM -0400, Lyude Paul wrote:
> > > > On Wed, 2022-05-04 at
On Thu, May 05, 2022 at 08:00:20AM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
> wrote:
> >
> > On Wed, May 04, 2022 at 02:10:08PM -0400, Lyude Paul wrote:
> > > On Wed, 2022-05-04 at 09:04 -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Wed, May
Hi,
On Thu, May 5, 2022 at 7:46 AM Ville Syrjälä
wrote:
>
> On Wed, May 04, 2022 at 02:10:08PM -0400, Lyude Paul wrote:
> > On Wed, 2022-05-04 at 09:04 -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Wed, May 4, 2022 at 5:21 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, May 03, 2022
Hi,
On Wed, May 4, 2022 at 11:10 AM Lyude Paul wrote:
>
> On Wed, 2022-05-04 at 09:04 -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, May 4, 2022 at 5:21 AM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, May 03, 2022 at 04:21:08PM -0700, Douglas Anderson wrote:
> > > > When doing DP AUX transf
On Wed, May 04, 2022 at 02:10:08PM -0400, Lyude Paul wrote:
> On Wed, 2022-05-04 at 09:04 -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, May 4, 2022 at 5:21 AM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, May 03, 2022 at 04:21:08PM -0700, Douglas Anderson wrote:
> > > > When doing DP AUX tr
Struct mdp4_platform_config is a relict from the DT-conversion time.
Move the max_clk field to the mdp4_kms_init(), the place where it is
used and drop the struct mdp4_platform_config and the mdp4_get_config()
function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop it from struct mdp4_cfg_platform which
remained from the pre-DT days.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 8
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.
The struct mdp4_platform_config is a remnant from pre-DT times. It
serves no particular purpose nowadays. So let's get rid of it.
Dmitry Baryshkov (2):
drm/msm/mdp4: move iommu_domain_alloc() call close to its usage
drm/msm/mdp4: get rid of struct mdp4_platform_config
drivers/gpu/drm/msm/dis
On Sun, May 1, 2022 at 9:50 AM Andy Shevchenko
wrote:
>
> On Sat, Apr 30, 2022 at 3:00 PM Douglas Anderson
> wrote:
> >
> > Due to a subtle typo, instead of commit 87ffea09470d ("device
> > property: Introduce fwnode_for_each_parent_node()") being a no-op
> > change, it ended up causing the disp
On Thu, 5 May 2022 at 13:27, Robin Murphy wrote:
>
> On 2022-05-05 01:16, Dmitry Baryshkov wrote:
> > Change msm_kms_init_aspace() to use generic function
> > device_iommu_mapped() instead of the fwnode-specific interface
> > dev_iommu_fwspec_get(). While we are at it, stop referencing
> > platfor
The msm_gem_prime_get_sg_table() needs to return error pointers on
error. This is called from drm_gem_map_dma_buf() and returning a
NULL will lead to a crash in that function.
Fixes: ac45146733b0 ("drm/msm: fix msm_gem_prime_get_sg_table()")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/msm/
On 2022-05-05 01:16, Dmitry Baryshkov wrote:
Change msm_kms_init_aspace() to use generic function
device_iommu_mapped() instead of the fwnode-specific interface
dev_iommu_fwspec_get(). While we are at it, stop referencing
platform_bus_type directly and use the bus of the IOMMU device.
FWIW, I'd
On Thu, 5 May 2022 at 05:06, Rob Clark wrote:
>
> On Wed, May 4, 2022 at 6:55 PM Jessica Zhang
> wrote:
> >
> > mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
> > the modeset lock, but currently mdp5_pipe_release doesn't check for if
> > an error is returned. Because of
32 matches
Mail list logo
