[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99403

--- Comment #10 from Roman Elshin  ---
so it may be closed?
p.s. thanks a lot to all participated

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106471] Radeon HD 3450 acceleration not working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106471

--- Comment #2 from Joshua Cogliati  ---
The other video card is integrated into the motherboard, and the disabling the
integrated video with bios causes the boot to fail.

I could try the video card in a different computer, but that computer would
have to be booted from usb since I don't want to change its os.

Would a dmesg.txt from a different computer with the same video card with say a
4.15 kernel be useful?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #197 from Sandeep  ---
Anyway, thanks for fixing the bug, AMD devs! (or whoever else did it).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #196 from Sandeep  ---
Ah, I didn't know that. I thought it just disabled/enabled dpm...well,
it works so that's good.

It would be great if it worked out of the box though, without having to add
kernel parameters.

On Fri, May 11, 2018, 14:39  wrote:

> *Comment # 195 
> on bug 91880  from Alex
> Deucher  *
>
> (In reply to Sandeep from comment #194 
> )> So, I had never 
> used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
> > testing earlier.
> >
> > I tried using them now, with the 4.16.7 kernel, and replayed the APItrace
> > file. No crashes! Finally.
> >
> > Well, this is still a workaround, but atleast it works. I doubt it has
> > anything to do with DC, although it's possible..
>
> setting dpm=1 uses the new powerplay code rather than the old dpm code for
> power management on CI parts.
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106287] 18.0.1 introduced glitches in Dying Light

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106287

--- Comment #3 from stu...@gmail.com ---
This is fixed in 15.0.3 on my machine.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #195 from Alex Deucher  ---
(In reply to Sandeep from comment #194)
> So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
> testing earlier.
> 
> I tried using them now, with the 4.16.7 kernel, and replayed the APItrace
> file. No crashes! Finally.
> 
> Well, this is still a workaround, but atleast it works. I doubt it has
> anything to do with DC, although it's possible..

setting dpm=1 uses the new powerplay code rather than the old dpm code for
power management on CI parts.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #194 from Sandeep  ---
So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when
testing earlier.

I tried using them now, with the 4.16.7 kernel, and replayed the APItrace file.
No crashes! Finally.

Well, this is still a workaround, but atleast it works. I doubt it has anything
to do with DC, although it's possible..

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Ville Syrjälä]

On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 20:29:48 +0300
> Ville Syrjälä  wrote:
> 
> > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 19:54:02 +0300
> > > Ville Syrjälä  wrote:
> > >   
> > > > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:  
> > > > > On Fri, 11 May 2018 18:34:50 +0300
> > > > > Ville Syrjälä  wrote:
> > > > > 
> > > > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > > > > > Applying an underscan setup is just a matter of scaling all planes
> > > > > > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > > > > > horizontal and vertical border.
> > > > > > > 
> > > > > > > Create an vc4_plane_underscan_adj() function doing that and call 
> > > > > > > it from
> > > > > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to 
> > > > > > > attach
> > > > > > > underscan properties to the HDMI connector.
> > > > > > > 
> > > > > > > Signed-off-by: Boris Brezillon 
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > - Take changes on hborder/vborder meaning into account
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
> > > > > > > -
> > > > > > >  1 file changed, 48 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
> > > > > > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > > index 71d44c357d35..61ed60841cd6 100644
> > > > > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct 
> > > > > > > drm_plane_state *state, int plane)
> > > > > > >   }
> > > > > > >  }
> > > > > > >  
> > > > > > > +static int vc4_plane_underscan_adj(struct drm_plane_state 
> > > > > > > *pstate)
> > > > > > > +{
> > > > > > > + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > > > > > + struct drm_connector_state *conn_state = NULL;
> > > > > > > + struct drm_connector *conn;
> > > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + for_each_new_connector_in_state(pstate->state, conn, 
> > > > > > > conn_state, i) {
> > > > > > > + if (conn_state->crtc == pstate->crtc)
> > > > > > > + break;
> > > > > > > + }
> > > > > > > +
> > > > > > > + if (i == pstate->state->num_connector)
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > > > > > +pstate->crtc);
> > > > > > > +
> > > > > > > + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay 
> > > > > > > ||
> > > > > > > + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > > > > > + return -EINVAL;  
> > > > > > 
> > > > > > border * 2 ?
> > > > > 
> > > > > Oops, indeed. I'll fix that.
> > > > > 
> > > > > > 
> > > > > > > +
> > > > > > > + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > > > > > + vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > > > > > > + vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > > > > > > +   (crtc_state->mode.hdisplay -
> > > > > > > +(conn_state->underscan.hborder * 2))) /
> > > > > > > +  crtc_state->mode.hdisplay;
> > > > > > > + vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > > > > > > +   (crtc_state->mode.vdisplay -
> > > > > > > +(conn_state->underscan.vborder * 2))) /
> > > > > > > +  crtc_state->mode.vdisplay;  
> > > > > > 
> > > > > > So you're now scaling all planes? The code seems to reject scaling 
> > > > > > for
> > > > > > the cursor plane, how are you dealing with that? Or just no cursor
> > > > > > allowed when underscanning?
> > > > > 
> > > > > No, I just didn't test with a cursor plane. We should probably avoid
> > > > > scaling the cursor plane and just adjust its position. Eric any 
> > > > > opinion
> > > > > on that?
> > > > 
> > > > I don't think you can just not scale it. The user asked for the cursor
> > > > to be at a specific place with a specific size. Can't just ignore
> > > > that and do something else. Also eg. i915 would definitely scale the
> > > > cursor since we'd just scale the entire crtc instead of scaling
> > > > individual planes. Different drivers doing different things wouldn't
> > > > be good.  
> > > 
> > > Except in our case the scaling takes place before the composition, so
> > > we don't have a choice.  
> > 
> > The choice is to 

Re: [PULL] drm-misc-next

[Eric Anholt]

Maarten Lankhorst  writes:

> Hey,
>
> Another pull request for drm-misc-next. Previous one was not applied yet,
> but only sending delta since last request:
> https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html

Note, I think this PR has a UABI regression in it:

https://patchwork.freedesktop.org/patch/221618/


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdkfd: Integer overflows in ioctl

[Oded Gabbay]

On Tue, Apr 24, 2018 at 9:58 PM, Felix Kuehling  wrote:
> Reviewed-by: Felix Kuehling 
>
> We could probably add a sanity check for n_devices to avoid user mode
> causing excessive memory allocations in the kernel. There is no good
> reason for this to be bigger than the number of GPUs in the system. The
> maximum number of GPUs supported due to device minor limit in DRM is 128.
>
> Regards,
>   Felix
>
>
> On 2018-04-24 09:35 AM, Dan Carpenter wrote:
>> args->n_devices is a u32 that comes from the user.  The multiplication
>> could overflow on 32 bit systems possibly leading to privilege
>> escalation.
>>
>> Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management")
>> Signed-off-by: Dan Carpenter dan.carpen...@oracle.com>
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
>> index cd679cf1fd30..ce36e556da38 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
>> @@ -1295,8 +1295,8 @@ static int kfd_ioctl_map_memory_to_gpu(struct file 
>> *filep,
>>   return -EINVAL;
>>   }
>>
>> - devices_arr = kmalloc(args->n_devices * sizeof(*devices_arr),
>> -   GFP_KERNEL);
>> + devices_arr = kmalloc_array(args->n_devices, sizeof(*devices_arr),
>> + GFP_KERNEL);
>>   if (!devices_arr)
>>   return -ENOMEM;
>>
>> @@ -1404,8 +1404,8 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file 
>> *filep,
>>   return -EINVAL;
>>   }
>>
>> - devices_arr = kmalloc(args->n_devices * sizeof(*devices_arr),
>> -   GFP_KERNEL);
>> + devices_arr = kmalloc_array(args->n_devices, sizeof(*devices_arr),
>> + GFP_KERNEL);
>>   if (!devices_arr)
>>   return -ENOMEM;
>>
>

Thanks!
Patch applied to amdkfd-fixes

Oded
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Eric Anholt]

Ville Syrjälä  writes:

> On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
>> On Fri, 11 May 2018 19:54:02 +0300
>> Ville Syrjälä  wrote:
>> 
>> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
>> > > On Fri, 11 May 2018 18:34:50 +0300
>> > > Ville Syrjälä  wrote:
>> > >   
>> > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:  
>> > > > > Applying an underscan setup is just a matter of scaling all planes
>> > > > > appropriately and adjusting the CRTC X/Y offset to account for the
>> > > > > horizontal and vertical border.
>> > > > > 
>> > > > > Create an vc4_plane_underscan_adj() function doing that and call it 
>> > > > > from
>> > > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
>> > > > > underscan properties to the HDMI connector.
>> > > > > 
>> > > > > Signed-off-by: Boris Brezillon 
>> > > > > ---
>> > > > > Changes in v2:
>> > > > > - Take changes on hborder/vborder meaning into account
>> > > > > ---
>> > > > >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
>> > > > > -
>> > > > >  1 file changed, 48 insertions(+), 1 deletion(-)
>> > > > > 
>> > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
>> > > > > b/drivers/gpu/drm/vc4/vc4_plane.c
>> > > > > index 71d44c357d35..61ed60841cd6 100644
>> > > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
>> > > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
>> > > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct 
>> > > > > drm_plane_state *state, int plane)
>> > > > >  }
>> > > > >  }
>> > > > >  
>> > > > > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
>> > > > > +{
>> > > > > +struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
>> > > > > +struct drm_connector_state *conn_state = NULL;
>> > > > > +struct drm_connector *conn;
>> > > > > +struct drm_crtc_state *crtc_state;
>> > > > > +int i;
>> > > > > +
>> > > > > +for_each_new_connector_in_state(pstate->state, conn, 
>> > > > > conn_state, i) {
>> > > > > +if (conn_state->crtc == pstate->crtc)
>> > > > > +break;
>> > > > > +}
>> > > > > +
>> > > > > +if (i == pstate->state->num_connector)
>> > > > > +return 0;
>> > > > > +
>> > > > > +if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
>> > > > > +return 0;
>> > > > > +
>> > > > > +crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
>> > > > > +   pstate->crtc);
>> > > > > +
>> > > > > +if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay 
>> > > > > ||
>> > > > > +conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
>> > > > > +return -EINVAL;
>> > > > 
>> > > > border * 2 ?  
>> > > 
>> > > Oops, indeed. I'll fix that.
>> > >   
>> > > >   
>> > > > > +
>> > > > > +vc4_pstate->crtc_x += conn_state->underscan.hborder;
>> > > > > +vc4_pstate->crtc_y += conn_state->underscan.vborder;
>> > > > > +vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
>> > > > > +  (crtc_state->mode.hdisplay -
>> > > > > +   (conn_state->underscan.hborder * 2))) /
>> > > > > + crtc_state->mode.hdisplay;
>> > > > > +vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
>> > > > > +  (crtc_state->mode.vdisplay -
>> > > > > +   (conn_state->underscan.vborder * 2))) /
>> > > > > + crtc_state->mode.vdisplay;
>> > > > 
>> > > > So you're now scaling all planes? The code seems to reject scaling for
>> > > > the cursor plane, how are you dealing with that? Or just no cursor
>> > > > allowed when underscanning?  
>> > > 
>> > > No, I just didn't test with a cursor plane. We should probably avoid
>> > > scaling the cursor plane and just adjust its position. Eric any opinion
>> > > on that?  
>> > 
>> > I don't think you can just not scale it. The user asked for the cursor
>> > to be at a specific place with a specific size. Can't just ignore
>> > that and do something else. Also eg. i915 would definitely scale the
>> > cursor since we'd just scale the entire crtc instead of scaling
>> > individual planes. Different drivers doing different things wouldn't
>> > be good.
>> 
>> Except in our case the scaling takes place before the composition, so
>> we don't have a choice.
>
> The choice is to either do what userspace asked, or return an error.
>
>> 
>> > 
>> > >   
>> > > > 
>> > > > I'm also wondering if there's any way we can reconcile these border
>> > > > props with the scaling mode prop, should we ever wish to expose
>> > > > these props on connectors that already have the scaling mode prop.  
>> > > 
>> > > Nouveau seems to expose both, and I don't see why we couldn't.  
>> > 
>> > 

[PATCH 3/6] drm/psr: Fix missed entry in PSR setup time table.

[Dhinakaran Pandiyan]

Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.

I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.

Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Jose Roberto de Souza 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_helper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 36c7609a4bd5..a7ba602a43a8 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1159,6 +1159,7 @@ int drm_dp_psr_setup_time(const u8 
psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
static const u16 psr_setup_time_us[] = {
PSR_SETUP_TIME(330),
PSR_SETUP_TIME(275),
+   PSR_SETUP_TIME(220),
PSR_SETUP_TIME(165),
PSR_SETUP_TIME(110),
PSR_SETUP_TIME(55),
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Boris Brezillon]

On Fri, 11 May 2018 20:29:48 +0300
Ville Syrjälä  wrote:

> On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> > On Fri, 11 May 2018 19:54:02 +0300
> > Ville Syrjälä  wrote:
> >   
> > > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:  
> > > > On Fri, 11 May 2018 18:34:50 +0300
> > > > Ville Syrjälä  wrote:
> > > > 
> > > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > > > > Applying an underscan setup is just a matter of scaling all planes
> > > > > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > > > > horizontal and vertical border.
> > > > > > 
> > > > > > Create an vc4_plane_underscan_adj() function doing that and call it 
> > > > > > from
> > > > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to 
> > > > > > attach
> > > > > > underscan properties to the HDMI connector.
> > > > > > 
> > > > > > Signed-off-by: Boris Brezillon 
> > > > > > ---
> > > > > > Changes in v2:
> > > > > > - Take changes on hborder/vborder meaning into account
> > > > > > ---
> > > > > >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
> > > > > > -
> > > > > >  1 file changed, 48 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
> > > > > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > index 71d44c357d35..61ed60841cd6 100644
> > > > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct 
> > > > > > drm_plane_state *state, int plane)
> > > > > > }
> > > > > >  }
> > > > > >  
> > > > > > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> > > > > > +{
> > > > > > +   struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > > > > +   struct drm_connector_state *conn_state = NULL;
> > > > > > +   struct drm_connector *conn;
> > > > > > +   struct drm_crtc_state *crtc_state;
> > > > > > +   int i;
> > > > > > +
> > > > > > +   for_each_new_connector_in_state(pstate->state, conn, 
> > > > > > conn_state, i) {
> > > > > > +   if (conn_state->crtc == pstate->crtc)
> > > > > > +   break;
> > > > > > +   }
> > > > > > +
> > > > > > +   if (i == pstate->state->num_connector)
> > > > > > +   return 0;
> > > > > > +
> > > > > > +   if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > > > > +   return 0;
> > > > > > +
> > > > > > +   crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > > > > +  pstate->crtc);
> > > > > > +
> > > > > > +   if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay 
> > > > > > ||
> > > > > > +   conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > > > > +   return -EINVAL;  
> > > > > 
> > > > > border * 2 ?
> > > > 
> > > > Oops, indeed. I'll fix that.
> > > > 
> > > > > 
> > > > > > +
> > > > > > +   vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > > > > +   vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > > > > > +   vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > > > > > + (crtc_state->mode.hdisplay -
> > > > > > +  (conn_state->underscan.hborder * 2))) /
> > > > > > +crtc_state->mode.hdisplay;
> > > > > > +   vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > > > > > + (crtc_state->mode.vdisplay -
> > > > > > +  (conn_state->underscan.vborder * 2))) /
> > > > > > +crtc_state->mode.vdisplay;  
> > > > > 
> > > > > So you're now scaling all planes? The code seems to reject scaling for
> > > > > the cursor plane, how are you dealing with that? Or just no cursor
> > > > > allowed when underscanning?
> > > > 
> > > > No, I just didn't test with a cursor plane. We should probably avoid
> > > > scaling the cursor plane and just adjust its position. Eric any opinion
> > > > on that?
> > > 
> > > I don't think you can just not scale it. The user asked for the cursor
> > > to be at a specific place with a specific size. Can't just ignore
> > > that and do something else. Also eg. i915 would definitely scale the
> > > cursor since we'd just scale the entire crtc instead of scaling
> > > individual planes. Different drivers doing different things wouldn't
> > > be good.  
> > 
> > Except in our case the scaling takes place before the composition, so
> > we don't have a choice.  
> 
> The choice is to either do what userspace asked, or return an error.

Come on! If we can't use underscan when there's a cursor plane enabled
this feature is pretty much useless. But let's take a real use case to
show you how negligible the lack of scaling on the cursor plane 

Re: [PATCH] drm/psr: Fix missed entry in PSR setup time table.

[Dhinakaran Pandiyan]

On Fri, 2018-05-11 at 18:03 +, Souza, Jose wrote:
> On Thu, 2018-05-10 at 17:54 -0700, Dhinakaran Pandiyan wrote:
> > 
> > Entry corresponding to 220 us setup time was missing. I am not
> > aware
> > of
> > any specific bug this fixes, but this could potentially result in
> > enabling
> > PSR on a panel with a higher setup time requirement than supported
> > by
> > the
> > hardware.
> It should be 'a lower setup time'.
> Sink sets 2h requesting 220us but source will only wait 165us.

By hardware, I meant source :) We'll end up enabling PSR on a sink with
a higher setup time requirement (220us) than supported by the source
hardware (let's say 200 us) because we read the sink requirement as 165
us.


> 
> Other than that looks good:
> Reviewed-by: José Roberto de Souza 
> 
Thanks!

I'll resend this along the other PSR patch you reviewed.

> > 
> > 
> > I verified the value is present in eDP spec versions 1.3, 1.4 and
> > 1.4a.
> > 
> > Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
> > Cc: sta...@vger.kernel.org
> > Cc: Ville Syrjälä 
> > Cc: Jose Roberto de Souza 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 36c7609a4bd5..a7ba602a43a8 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -1159,6 +1159,7 @@ int drm_dp_psr_setup_time(const u8
> > psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
> >     static const u16 psr_setup_time_us[] = {
> >     PSR_SETUP_TIME(330),
> >     PSR_SETUP_TIME(275),
> > +   PSR_SETUP_TIME(220),
> >     PSR_SETUP_TIME(165),
> >     PSR_SETUP_TIME(110),
> >     PSR_SETUP_TIME(55),
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[Sean Paul]

On Fri, May 11, 2018 at 11:05:24AM -0600, Jordan Crouse wrote:
> On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:
> > SoCs containing dpu have a MDSS top level wrapper
> > which includes sub-blocks as dpu, dsi, phy, dp etc.
> > MDSS top level wrapper manages common resources like
> > common clocks, power and irq for its sub-blocks.
> > 
> > Currently, in dpu driver, all the power resource
> > management is part of power_handle which manages
> > these resources via a custom implementation. And
> > the resource relationships are not modelled properly
> > in dt.  Moreover the irq domain handling code is part
> > of dpu device (which is a child device) due to lack
> > of a dedicated driver for MDSS top level wrapper
> > device.
> > 
> > This change adds dpu_mdss top level driver to handle
> > common clock like - core clock, ahb clock
> > (for register access), main power supply (i.e. gdsc)
> > and irq management.
> > The top level mdss device/driver acts as an interrupt
> > controller and manage hwirq mapping for its child
> > devices.
> > 
> > It implements runtime_pm support for resource management.
> > Child nodes can control these resources via runtime_pm
> > get/put calls on their corresponding devices due to parent
> > child relationship defined in dt.
> > 
> > Changes in v2:
> > - merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
> > - merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
> > - fix indentation for irq_find_mapping call (Sean Paul)
> > - remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
> > - remove redundant param checks from
> >   dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
> > - remove redundant param checks from
> >   dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
> > - return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
> > Crouse)
> > - remove redundant param check from dpu_mdss_destroy (Sean Paul)
> > - remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
> > - remove compatibility check from dpu_mdss_init as
> >   it is conditionally called from msm_drv (Sean Paul)
> > - reworked msm_dss_parse_clock() to add return checks for
> >   of_property_read_* calls, fix log message and
> >   fix alignment issues (Sean Paul/Jordan Crouse)
> > - remove extra line before dpu_mdss_init (Sean Paul)
> > - remove redundant param checks from __intr_offset and
> >   make it a void function to avoid unnecessary error
> >   handling from caller (Jordan Crouse)
> > - remove redundant param check from dpu_mdss_irq (Jordan Crouse)
> > - change mdss address space log message to debug and use %pK for
> >   kernel pointers (Jordan Crouse)
> > - remove unnecessary log message from msm_dss_parse_clock (Jordan 
> > Crouse)
> > - don't export msm_dss_parse_clock since it is used
> >   only by dpu driver (Jordan Crouse)
> > 
> > Signed-off-by: Rajesh Yadav 
> 
> Reviewed-by: Jordan Crouse 
> 
> I know you'll get a hundred different opinions from a hundred different people

I'll interpret this as solicitation of my opinion :-)

I find this level of detail _extremely_ useful when reviewing, especially on
sets as big as this one.

It's a pretty good strategy to make reviews go as smoothly as possible, since
it's generally more difficult to read code than to write it.

Sean

/opinion

> but you don't need to credit me for every change - just a single line "fixed
> bugs" works for me.
> 
> > ---
> >  drivers/gpu/drm/msm/Makefile  |   1 +
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 254 
> > ++
> >  drivers/gpu/drm/msm/dpu_io_util.c |  57 +
> >  drivers/gpu/drm/msm/msm_drv.c |  26 ++-
> >  drivers/gpu/drm/msm/msm_drv.h |   2 +-
> >  drivers/gpu/drm/msm/msm_kms.h |   1 +
> >  include/linux/dpu_io_util.h   |   2 +
> >  16 files changed, 339 insertions(+), 226 deletions(-)
> >  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> > 
> > diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> > index d7558ed..d9826c1 100644
> > --- a/drivers/gpu/drm/msm/Makefile
> > +++ b/drivers/gpu/drm/msm/Makefile
> > @@ -81,6 +81,7 @@ msm-y := \
> > 

[PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

[Alexandru Gheorghe]

Status register contains a lot of bits for reporting internal errors
inside Mali DP. Currently, we just silently ignore all of the erorrs,
that doesn't help when we are investigating different bugs, especially
on the FPGA models which have a lot of constrains, so we could easily
end up in AXI or underrun errors.

Add a new file called debug that contains an agregate of the
errors reported by the Mali DP hardware.

E.g:
[root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
[DE] num_errors : 167
[DE] last_error_status  : 0x0001
[DE] last_error_vblank : 385
[SE] num_errors : 3
[SE] last_error_status  : 0x00e23001
[SE] last_error_vblank : 201

This a morphosis of the patch presented here [1], where the errors
where reported continuously via trace_printk.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167042.html

Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/arm/malidp_drv.c  | 61 +++
 drivers/gpu/drm/arm/malidp_drv.h  | 15 ++
 drivers/gpu/drm/arm/malidp_hw.c   | 46 -
 drivers/gpu/drm/arm/malidp_hw.h   |  1 +
 drivers/gpu/drm/arm/malidp_regs.h |  6 
 5 files changed, 122 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 8d20faa..70ce19a 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -29,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "malidp_drv.h"
 #include "malidp_regs.h"
@@ -327,6 +329,62 @@ static int malidp_dumb_create(struct drm_file *file_priv,
return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
 }
 
+#ifdef CONFIG_DEBUG_FS
+
+static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
+{
+   atomic_set(_stats->num_errors, 0);
+   atomic_set(_stats->last_error_status, 0);
+   atomic64_set(_stats->last_error_vblank, -1);
+}
+
+void malidp_error(struct malidp_error_stats *error_stats, u32 status,
+ u64 vblank)
+{
+   atomic_set(_stats->last_error_status, status);
+   atomic64_set(_stats->last_error_vblank, vblank);
+   atomic_inc(_stats->num_errors);
+}
+
+void malidp_error_stats_dump(const char *prefix,
+struct malidp_error_stats *error_stats,
+struct seq_file *m)
+{
+   seq_printf(m, "[%s] num_errors : %d\n", prefix,
+  atomic_read(_stats->num_errors));
+   seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
+  atomic_read(_stats->last_error_status));
+   seq_printf(m, "[%s] last_error_vblank : %ld\n", prefix,
+  atomic64_read(_stats->last_error_vblank));
+}
+
+static int malidp_show_stats(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *drm = node->minor->dev;
+   struct malidp_drm *malidp = drm->dev_private;
+
+   malidp_error_stats_dump("DE", >de_errors, m);
+   malidp_error_stats_dump("SE", >se_errors, m);
+   return 0;
+}
+
+static struct drm_info_list malidp_debugfs_list[] = {
+   { "debug", malidp_show_stats, 0 },
+};
+
+static int malidp_debugfs_init(struct drm_minor *minor)
+{
+   struct malidp_drm *malidp = minor->dev->dev_private;
+
+   malidp_error_stats_init(>de_errors);
+   malidp_error_stats_init(>se_errors);
+   return drm_debugfs_create_files(malidp_debugfs_list,
+   ARRAY_SIZE(malidp_debugfs_list), minor->debugfs_root, minor);
+}
+
+#endif //CONFIG_DEBUG_FS
+
 static struct drm_driver malidp_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
   DRIVER_PRIME,
@@ -343,6 +401,9 @@ static struct drm_driver malidp_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
+#ifdef CONFIG_DEBUG_FS
+   .debugfs_init = malidp_debugfs_init,
+#endif
.fops = ,
.name = "mali-dp",
.desc = "ARM Mali Display Processor driver",
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index c70989b..c49056c 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -18,6 +18,12 @@
 #include 
 #include "malidp_hw.h"
 
+struct malidp_error_stats {
+   atomic_t num_errors;
+   atomic_t last_error_status;
+   atomic64_t last_error_vblank;
+};
+
 struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
@@ -25,6 +31,10 @@ struct malidp_drm {
struct drm_pending_vblank_event *event;
atomic_t config_valid;
u32 core_id;
+#ifdef CONFIG_DEBUG_FS
+   struct malidp_error_stats de_errors;
+   struct malidp_error_stats se_errors;

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105684

--- Comment #27 from Alex Deucher  ---
Can you post your kernel config?  I'm having trouble seeing how these crashes
are even possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Ville Syrjälä]

On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 19:54:02 +0300
> Ville Syrjälä  wrote:
> 
> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 18:34:50 +0300
> > > Ville Syrjälä  wrote:
> > >   
> > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:  
> > > > > Applying an underscan setup is just a matter of scaling all planes
> > > > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > > > horizontal and vertical border.
> > > > > 
> > > > > Create an vc4_plane_underscan_adj() function doing that and call it 
> > > > > from
> > > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> > > > > underscan properties to the HDMI connector.
> > > > > 
> > > > > Signed-off-by: Boris Brezillon 
> > > > > ---
> > > > > Changes in v2:
> > > > > - Take changes on hborder/vborder meaning into account
> > > > > ---
> > > > >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
> > > > > -
> > > > >  1 file changed, 48 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
> > > > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > index 71d44c357d35..61ed60841cd6 100644
> > > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct 
> > > > > drm_plane_state *state, int plane)
> > > > >   }
> > > > >  }
> > > > >  
> > > > > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> > > > > +{
> > > > > + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > > > + struct drm_connector_state *conn_state = NULL;
> > > > > + struct drm_connector *conn;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > > + int i;
> > > > > +
> > > > > + for_each_new_connector_in_state(pstate->state, conn, 
> > > > > conn_state, i) {
> > > > > + if (conn_state->crtc == pstate->crtc)
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + if (i == pstate->state->num_connector)
> > > > > + return 0;
> > > > > +
> > > > > + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > > > + return 0;
> > > > > +
> > > > > + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > > > +pstate->crtc);
> > > > > +
> > > > > + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay 
> > > > > ||
> > > > > + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > > > + return -EINVAL;
> > > > 
> > > > border * 2 ?  
> > > 
> > > Oops, indeed. I'll fix that.
> > >   
> > > >   
> > > > > +
> > > > > + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > > > + vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > > > > + vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > > > > +   (crtc_state->mode.hdisplay -
> > > > > +(conn_state->underscan.hborder * 2))) /
> > > > > +  crtc_state->mode.hdisplay;
> > > > > + vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > > > > +   (crtc_state->mode.vdisplay -
> > > > > +(conn_state->underscan.vborder * 2))) /
> > > > > +  crtc_state->mode.vdisplay;
> > > > 
> > > > So you're now scaling all planes? The code seems to reject scaling for
> > > > the cursor plane, how are you dealing with that? Or just no cursor
> > > > allowed when underscanning?  
> > > 
> > > No, I just didn't test with a cursor plane. We should probably avoid
> > > scaling the cursor plane and just adjust its position. Eric any opinion
> > > on that?  
> > 
> > I don't think you can just not scale it. The user asked for the cursor
> > to be at a specific place with a specific size. Can't just ignore
> > that and do something else. Also eg. i915 would definitely scale the
> > cursor since we'd just scale the entire crtc instead of scaling
> > individual planes. Different drivers doing different things wouldn't
> > be good.
> 
> Except in our case the scaling takes place before the composition, so
> we don't have a choice.

The choice is to either do what userspace asked, or return an error.

> 
> > 
> > >   
> > > > 
> > > > I'm also wondering if there's any way we can reconcile these border
> > > > props with the scaling mode prop, should we ever wish to expose
> > > > these props on connectors that already have the scaling mode prop.  
> > > 
> > > Nouveau seems to expose both, and I don't see why we couldn't.  
> > 
> > First of all the interaction of these borders with panels that have
> > a fixed mode would need to be properly specified. Do we apply the
> > 

[Bug 106474] "CPU1 stuck for XXs: Xorg" since update to linux-4.16.x

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106474

--- Comment #3 from Clemens Eisserer  ---
unfortunately not on that machine :/

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Boris Brezillon]

On Fri, 11 May 2018 19:54:02 +0300
Ville Syrjälä  wrote:

> On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > On Fri, 11 May 2018 18:34:50 +0300
> > Ville Syrjälä  wrote:
> >   
> > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:  
> > > > Applying an underscan setup is just a matter of scaling all planes
> > > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > > horizontal and vertical border.
> > > > 
> > > > Create an vc4_plane_underscan_adj() function doing that and call it from
> > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> > > > underscan properties to the HDMI connector.
> > > > 
> > > > Signed-off-by: Boris Brezillon 
> > > > ---
> > > > Changes in v2:
> > > > - Take changes on hborder/vborder meaning into account
> > > > ---
> > > >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
> > > > -
> > > >  1 file changed, 48 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
> > > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > index 71d44c357d35..61ed60841cd6 100644
> > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct 
> > > > drm_plane_state *state, int plane)
> > > > }
> > > >  }
> > > >  
> > > > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> > > > +{
> > > > +   struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > > +   struct drm_connector_state *conn_state = NULL;
> > > > +   struct drm_connector *conn;
> > > > +   struct drm_crtc_state *crtc_state;
> > > > +   int i;
> > > > +
> > > > +   for_each_new_connector_in_state(pstate->state, conn, 
> > > > conn_state, i) {
> > > > +   if (conn_state->crtc == pstate->crtc)
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   if (i == pstate->state->num_connector)
> > > > +   return 0;
> > > > +
> > > > +   if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > > +   return 0;
> > > > +
> > > > +   crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > > +  pstate->crtc);
> > > > +
> > > > +   if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay 
> > > > ||
> > > > +   conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > > +   return -EINVAL;
> > > 
> > > border * 2 ?  
> > 
> > Oops, indeed. I'll fix that.
> >   
> > >   
> > > > +
> > > > +   vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > > +   vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > > > +   vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > > > + (crtc_state->mode.hdisplay -
> > > > +  (conn_state->underscan.hborder * 2))) /
> > > > +crtc_state->mode.hdisplay;
> > > > +   vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > > > + (crtc_state->mode.vdisplay -
> > > > +  (conn_state->underscan.vborder * 2))) /
> > > > +crtc_state->mode.vdisplay;
> > > 
> > > So you're now scaling all planes? The code seems to reject scaling for
> > > the cursor plane, how are you dealing with that? Or just no cursor
> > > allowed when underscanning?  
> > 
> > No, I just didn't test with a cursor plane. We should probably avoid
> > scaling the cursor plane and just adjust its position. Eric any opinion
> > on that?  
> 
> I don't think you can just not scale it. The user asked for the cursor
> to be at a specific place with a specific size. Can't just ignore
> that and do something else. Also eg. i915 would definitely scale the
> cursor since we'd just scale the entire crtc instead of scaling
> individual planes. Different drivers doing different things wouldn't
> be good.

Except in our case the scaling takes place before the composition, so
we don't have a choice.

> 
> >   
> > > 
> > > I'm also wondering if there's any way we can reconcile these border
> > > props with the scaling mode prop, should we ever wish to expose
> > > these props on connectors that already have the scaling mode prop.  
> > 
> > Nouveau seems to expose both, and I don't see why we couldn't.  
> 
> First of all the interaction of these borders with panels that have
> a fixed mode would need to be properly specified. Do we apply the
> borders against the user mode or the panel's native mode?

Hm, I'm a bit lost. Isn't crtc_state->mode supposed to contain the mode
that is about to be applied, no matter if it's a usermode or one of the
mode returned by the display? 

> I guess
> the latter would be a bit easier (would also match how the TV 

Re: [Freedreno] [DPU PATCH v2 04/12] drm/msm/dpu: create new platform driver for dpu device

[Jordan Crouse]

On Fri, May 11, 2018 at 08:19:30PM +0530, Rajesh Yadav wrote:
> Current MSM display controller HW matches a tree like
> hierarchy where MDSS top level wrapper is parent device
> and mdp5/dpu, dsi, dp are child devices.
> 
> Each child device like mdp5, dsi etc. have a separate driver,
> but currently dpu handling is tied to a single driver which
> was managing both mdss and dpu resources.
> 
> Inorder to have the cleaner one to one device and driver
> association, this change adds a new platform_driver for dpu
> child device node which implements the kms functionality.
> 
> The dpu driver implements runtime_pm support for managing clocks
> and bus bandwidth etc.
> 
> Changes in v2:
>   - remove redundant param check from _dpu_kms_hw_destroy (Sean Paul)
>   - remove explicit calls to devm_kfree (Sean Paul)
>   - merge dpu_init into dpu_bind (Sean Paul)
>   - merge dpu_destroy into dpu_unbind (Sean Paul)
>   - use %pK for kernel pointer printing (Jordan Crouse)
>   - remove explicit devm allocation failure message (Jordan Crouse)
>
> Signed-off-by: Rajesh Yadav 

Reviewed-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 238 
> +---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   4 +
>  drivers/gpu/drm/msm/msm_drv.c   |   2 +
>  drivers/gpu/drm/msm/msm_drv.h   |   3 +
>  4 files changed, 196 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index e4ab753..85f3dbc 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1030,16 +1030,12 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms, 
> unsigned long rate,
>   return rate;
>  }
>  
> -static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
> - struct platform_device *pdev)
> +static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
>  {
>   struct drm_device *dev;
>   struct msm_drm_private *priv;
>   int i;
>  
> - if (!dpu_kms || !pdev)
> - return;
> -
>   dev = dpu_kms->dev;
>   if (!dev)
>   return;
> @@ -1091,15 +1087,15 @@ static void _dpu_kms_hw_destroy(struct dpu_kms 
> *dpu_kms,
>   dpu_kms->core_client = NULL;
>  
>   if (dpu_kms->vbif[VBIF_NRT])
> - msm_iounmap(pdev, dpu_kms->vbif[VBIF_NRT]);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_NRT]);
>   dpu_kms->vbif[VBIF_NRT] = NULL;
>  
>   if (dpu_kms->vbif[VBIF_RT])
> - msm_iounmap(pdev, dpu_kms->vbif[VBIF_RT]);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_RT]);
>   dpu_kms->vbif[VBIF_RT] = NULL;
>  
>   if (dpu_kms->mmio)
> - msm_iounmap(pdev, dpu_kms->mmio);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->mmio);
>   dpu_kms->mmio = NULL;
>  
>   dpu_reg_dma_deinit();
> @@ -1172,8 +1168,6 @@ int dpu_kms_mmu_attach(struct dpu_kms *dpu_kms, bool 
> secure_only)
>  static void dpu_kms_destroy(struct msm_kms *kms)
>  {
>   struct dpu_kms *dpu_kms;
> - struct drm_device *dev;
> - struct platform_device *platformdev;
>  
>   if (!kms) {
>   DPU_ERROR("invalid kms\n");
> @@ -1181,20 +1175,7 @@ static void dpu_kms_destroy(struct msm_kms *kms)
>   }
>  
>   dpu_kms = to_dpu_kms(kms);
> - dev = dpu_kms->dev;
> - if (!dev) {
> - DPU_ERROR("invalid device\n");
> - return;
> - }
> -
> - platformdev = to_platform_device(dev->dev);
> - if (!platformdev) {
> - DPU_ERROR("invalid platform device\n");
> - return;
> - }
> -
> - _dpu_kms_hw_destroy(dpu_kms, platformdev);
> - kfree(dpu_kms);
> + _dpu_kms_hw_destroy(dpu_kms);
>  }
>  
>  static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
> @@ -1550,7 +1531,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
>   struct dpu_kms *dpu_kms;
>   struct drm_device *dev;
>   struct msm_drm_private *priv;
> - struct platform_device *platformdev;
>   int i, rc = -EINVAL;
>  
>   if (!kms) {
> @@ -1565,34 +1545,28 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
>   goto end;
>   }
>  
> - platformdev = to_platform_device(dev->dev);
> - if (!platformdev) {
> - DPU_ERROR("invalid platform device\n");
> - goto end;
> - }
> -
>   priv = dev->dev_private;
>   if (!priv) {
>   DPU_ERROR("invalid private data\n");
>   goto end;
>   }
>  
> - dpu_kms->mmio = msm_ioremap(platformdev, "mdp_phys", "mdp_phys");
> + dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp_phys", "mdp_phys");
>   if (IS_ERR(dpu_kms->mmio)) {
>   rc = PTR_ERR(dpu_kms->mmio);
>   DPU_ERROR("mdp register memory map failed: %d\n", rc);
>   dpu_kms->mmio = NULL;
>   

Re: [Freedreno] [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[Jordan Crouse]

On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:
> SoCs containing dpu have a MDSS top level wrapper
> which includes sub-blocks as dpu, dsi, phy, dp etc.
> MDSS top level wrapper manages common resources like
> common clocks, power and irq for its sub-blocks.
> 
> Currently, in dpu driver, all the power resource
> management is part of power_handle which manages
> these resources via a custom implementation. And
> the resource relationships are not modelled properly
> in dt.  Moreover the irq domain handling code is part
> of dpu device (which is a child device) due to lack
> of a dedicated driver for MDSS top level wrapper
> device.
> 
> This change adds dpu_mdss top level driver to handle
> common clock like - core clock, ahb clock
> (for register access), main power supply (i.e. gdsc)
> and irq management.
> The top level mdss device/driver acts as an interrupt
> controller and manage hwirq mapping for its child
> devices.
> 
> It implements runtime_pm support for resource management.
> Child nodes can control these resources via runtime_pm
> get/put calls on their corresponding devices due to parent
> child relationship defined in dt.
> 
> Changes in v2:
>   - merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
>   - merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
>   - fix indentation for irq_find_mapping call (Sean Paul)
>   - remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
>   - remove redundant param checks from
> dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
>   - remove redundant param checks from
> dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
>   - return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
> Crouse)
>   - remove redundant param check from dpu_mdss_destroy (Sean Paul)
>   - remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
>   - remove compatibility check from dpu_mdss_init as
> it is conditionally called from msm_drv (Sean Paul)
>   - reworked msm_dss_parse_clock() to add return checks for
> of_property_read_* calls, fix log message and
> fix alignment issues (Sean Paul/Jordan Crouse)
>   - remove extra line before dpu_mdss_init (Sean Paul)
>   - remove redundant param checks from __intr_offset and
> make it a void function to avoid unnecessary error
> handling from caller (Jordan Crouse)
>   - remove redundant param check from dpu_mdss_irq (Jordan Crouse)
>   - change mdss address space log message to debug and use %pK for
> kernel pointers (Jordan Crouse)
>   - remove unnecessary log message from msm_dss_parse_clock (Jordan 
> Crouse)
>   - don't export msm_dss_parse_clock since it is used
> only by dpu driver (Jordan Crouse)
> 
> Signed-off-by: Rajesh Yadav 

Reviewed-by: Jordan Crouse 

I know you'll get a hundred different opinions from a hundred different people
but you don't need to credit me for every change - just a single line "fixed
bugs" works for me.

> ---
>  drivers/gpu/drm/msm/Makefile  |   1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 254 
> ++
>  drivers/gpu/drm/msm/dpu_io_util.c |  57 +
>  drivers/gpu/drm/msm/msm_drv.c |  26 ++-
>  drivers/gpu/drm/msm/msm_drv.h |   2 +-
>  drivers/gpu/drm/msm/msm_kms.h |   1 +
>  include/linux/dpu_io_util.h   |   2 +
>  16 files changed, 339 insertions(+), 226 deletions(-)
>  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> 
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index d7558ed..d9826c1 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -81,6 +81,7 @@ msm-y := \
>   disp/dpu1/dpu_reg_dma.o \
>   disp/dpu1/dpu_rm.o \
>   disp/dpu1/dpu_vbif.o \
> + disp/dpu1/dpu_mdss.o \
>   dpu_dbg.o \
>   dpu_io_util.o \
>   dpu_dbg_evtlog.o \
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> index fe33013..977adc4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> @@ -515,103 +515,6 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
>   

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Ville Syrjälä]

On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 18:34:50 +0300
> Ville Syrjälä  wrote:
> 
> > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > Applying an underscan setup is just a matter of scaling all planes
> > > appropriately and adjusting the CRTC X/Y offset to account for the
> > > horizontal and vertical border.
> > > 
> > > Create an vc4_plane_underscan_adj() function doing that and call it from
> > > vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> > > underscan properties to the HDMI connector.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > > Changes in v2:
> > > - Take changes on hborder/vborder meaning into account
> > > ---
> > >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
> > > -
> > >  1 file changed, 48 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
> > > b/drivers/gpu/drm/vc4/vc4_plane.c
> > > index 71d44c357d35..61ed60841cd6 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct drm_plane_state 
> > > *state, int plane)
> > >   }
> > >  }
> > >  
> > > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> > > +{
> > > + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > > + struct drm_connector_state *conn_state = NULL;
> > > + struct drm_connector *conn;
> > > + struct drm_crtc_state *crtc_state;
> > > + int i;
> > > +
> > > + for_each_new_connector_in_state(pstate->state, conn, conn_state, i) {
> > > + if (conn_state->crtc == pstate->crtc)
> > > + break;
> > > + }
> > > +
> > > + if (i == pstate->state->num_connector)
> > > + return 0;
> > > +
> > > + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > > + return 0;
> > > +
> > > + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > > +pstate->crtc);
> > > +
> > > + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay ||
> > > + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > > + return -EINVAL;  
> > 
> > border * 2 ?
> 
> Oops, indeed. I'll fix that.
> 
> > 
> > > +
> > > + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > > + vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > > + vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > > +   (crtc_state->mode.hdisplay -
> > > +(conn_state->underscan.hborder * 2))) /
> > > +  crtc_state->mode.hdisplay;
> > > + vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > > +   (crtc_state->mode.vdisplay -
> > > +(conn_state->underscan.vborder * 2))) /
> > > +  crtc_state->mode.vdisplay;  
> > 
> > So you're now scaling all planes? The code seems to reject scaling for
> > the cursor plane, how are you dealing with that? Or just no cursor
> > allowed when underscanning?
> 
> No, I just didn't test with a cursor plane. We should probably avoid
> scaling the cursor plane and just adjust its position. Eric any opinion
> on that?

I don't think you can just not scale it. The user asked for the cursor
to be at a specific place with a specific size. Can't just ignore
that and do something else. Also eg. i915 would definitely scale the
cursor since we'd just scale the entire crtc instead of scaling
individual planes. Different drivers doing different things wouldn't
be good.

> 
> > 
> > I'm also wondering if there's any way we can reconcile these border
> > props with the scaling mode prop, should we ever wish to expose
> > these props on connectors that already have the scaling mode prop.
> 
> Nouveau seems to expose both, and I don't see why we couldn't.

First of all the interaction of these borders with panels that have
a fixed mode would need to be properly specified. Do we apply the
borders against the user mode or the panel's native mode? I guess
the latter would be a bit easier (would also match how the TV margins
behave I suppose). But that does leave open the question of how
would generic userspace know which case it's dealing with? Eg. if it
wants to underscan by some specific percentage it has to calculate
the borders based on the correct mode, otherwise the results aren't
going to match the expectations.

> 
> > Maybe we just have to require the scaling mode to be set to fullscreen 
> > to allow borders to be specified explictly?
> > 
> > > +
> > > + if (!vc4_pstate->crtc_w || !vc4_pstate->crtc_h)
> > > + return -EINVAL;
> > > +
> > > + return 0;
> > > +}
> > > +
> > >  static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state 
> > > *state)
> > >  {
> > >   struct drm_plane *plane = state->plane;
> > > @@ -269,7 +312,7 @@ static int 
> > > 

Re: [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp

[Enric Balletbo Serra]

Hi Lin,

2018-05-09 12:22 GMT+02:00 Lin Huang :
> From: Chris Zhong 
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
>
> Changes in v2:
> - update patch following Enric suggest
>
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 
>  drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 67 
> ++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++-
>  4 files changed, 120 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device 
> *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> -   ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
> -   if (ret)
> +   ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
> +   if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct 
> cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> -   ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> -  DP_RECEIVER_CAP_SIZE);
> -   if (ret) {
> +   ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
> +  sizeof(dp->dpcd));
> +   if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
> *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> -   if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> -DP_LINK_STATUS_SIZE)) {
> +   if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
> +   DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
>  }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> +  struct drm_dp_aux_msg *msg)
> +{
> +   struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, 
> aux);
> +   int ret;
> +   u8 status;
> +
> +   switch (msg->request & ~DP_AUX_I2C_MOT) {
> +   case DP_AUX_NATIVE_WRITE:
> +   case DP_AUX_I2C_WRITE:
> +   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +   ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> +   msg->size);
> +   break;
> +   case DP_AUX_NATIVE_READ:
> +   case DP_AUX_I2C_READ:
> +   ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> +  msg->size);
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   status = cdn_dp_get_aux_status(dp);
> +   if (status == AUX_STATUS_ACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> +   else if (status == AUX_STATUS_NACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> +   else if (status == AUX_STATUS_DEFER)
> +   msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> +   return ret;
> +}
> +
>  static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>  {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct 
> device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> +   dp->aux.name = "DP-AUX";
> +   dp->aux.transfer = cdn_dp_aux_transfer;
> +   dp->aux.dev = dev;
> +
> +   ret = drm_dp_aux_register(>aux);
> +   if (ret)
> +   return ret;
>
> INIT_WORK(>event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct platform_device *audio_pdev;
> struct work_struct event_work;
> struct edid *edid;
> +   struct drm_dp_aux aux;
>
> struct mutex lock;
> bool connected;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index 

Re: [PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY

[Enric Balletbo Serra]

Hi Lin,

2018-05-11 16:43 GMT+02:00 Sean Paul :
> On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote:
>> If want to do training outside DP Firmware, need phy voltage swing
>> and pre_emphasis value.
>>
>> Signed-off-by: Lin Huang 
>
> Adding Rob Herring so he has a hope of seeing this.
>

And adding the devicetree ML, otherwise Rob will probably ignore the patch.

>> ---
>> Changes in v2:
>> - rebase
>>
>>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt 
>> b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> index 960da7f..eda26dd 100644
>> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> @@ -17,7 +17,9 @@ Required properties:
>>
>>  Optional properties:
>>   - extcon : extcon specifier for the Power Delivery
>> -
>> + - rockchip,phy_config : That's phy voltage swing and pre_emphasis
>> +  setting, if want to do dp training outside
>> +  dp firmware, need to add these value.
>
> What are the units?
>

Also, I think that will be good add an example or include the property
in the current examples to see how works. It's not clear from the
property description. I suppose it is an array of pairs ?

nit:

-rockchip,phy_config: A list of voltage swing (unit) and pre-emphasis
(unit) pairs. Use this property to enable software link training
instead of hardware link training.

Best regards,
 Enric

> Sean
>
>>  Required nodes : a sub-node is required for each port the phy provides.
>>The sub-node name is used to identify dp or usb3 port,
>>and shall be the following entries:
>> --
>> 2.7.4
>>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation

[Linus Walleij]

On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard  wrote:

> The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
> ILI9881c from Ilitek.
>
> Acked-by: Rob Herring 
> Signed-off-by: Maxime Ripard 
(...)

Bah, now I see this:

> +  - power-gpios: a GPIO phandle for the power pin

That should probably be a fixed regulator backed by a GPIO
instead. Especially if you know which voltage it has. So
one more layer of abstraction, sorry.

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 5/7] drm/vmwgfx: Stop updating plane->fb

[Ville Syrjälä]

On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote:
> On Fri, Apr 06, 2018 at 07:14:51PM +, Deepak Singh Rawat wrote:
> > This makes sense once we got rid of plane->fb
> > 
> > Will this go to drm-next?
> 
> The plan is to push to drm-misc-next once we get all
> the ducks in a row.
> 
> > Could you please CC
> > me so that I can do some testing myself. Thanks.
> 
> Here's a branch if you want a head start:
> git://github.com/vsyrjala/linux.git plane_fb_crtc_nuke_2
> 
> I'd definitely appreciate some testing of this stuff. Wouldn't
> want to break you stuff accidentally.

Did we get anywhere with testing this? I'd like to land the remaining 
bits, but I'd feel much safer doing that if it was tested.

> 
> > 
> > Reviewed-by: Deepak Rawat 
> > 
> > 
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > We want to get rid of plane->fb on atomic drivers. Stop setting it.
> > > 
> > > Cc: Thomas Hellstrom 
> > > Cc: Sinclair Yeh 
> > > Cc: VMware Graphics 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 --
> > >  2 files changed, 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > index 648f8127f65a..bbd3f19b1a0b 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> > > @@ -525,8 +525,6 @@ vmw_sou_primary_plane_atomic_update(struct
> > > drm_plane *plane,
> > >*/
> > >   if (ret != 0)
> > >   DRM_ERROR("Failed to update screen.\n");
> > > -
> > > - crtc->primary->fb = plane->state->fb;
> > >   } else {
> > >   /*
> > >* When disabling a plane, CRTC and FB should always be
> > > NULL
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > index 67331f01ef32..90445bc590cb 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> > > @@ -1285,8 +1285,6 @@ vmw_stdu_primary_plane_atomic_update(struct
> > > drm_plane *plane,
> > >1, 1, NULL, crtc);
> > >   if (ret)
> > >   DRM_ERROR("Failed to update STDU.\n");
> > > -
> > > - crtc->primary->fb = plane->state->fb;
> > >   } else {
> > >   crtc = old_state->crtc;
> > >   stdu = vmw_crtc_to_stdu(crtc);
> > > --
> > > 2.16.1
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/3] drm/panel: Add Ilitek ILI9881c panel driver

[Linus Walleij]

Hi Maxime,

sorry that noone had much time to look at the driver.
But I can help out, hopefully.

On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard  wrote:

> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
> based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
> after the other Ilitek controller drivers.
>
> Signed-off-by: Maxime Ripard 

Nice, I have some experience with those.

> +config DRM_PANEL_ILITEK_ILI9881C
> +   tristate "Ilitek ILI9881C-based panels"
> +   depends on OF
> +   depends on DRM_MIPI_DSI
> +   depends on BACKLIGHT_CLASS_DEVICE

If it absolutely needs DRM_MIPI_DSI and
BACKLIGHT_CLASS_DEVICE it maybe you should
be more helpful to the user to just select it?

Depending on OF is fine, that is more of a platform
property.

> +struct ili9881c {
> +   struct drm_panelpanel;
> +   struct mipi_dsi_device  *dsi;
> +
> +   struct backlight_device *backlight;
> +   struct gpio_desc*power;

Should this not be modeled using a fixed regulator instead?

> +   struct gpio_desc*reset;
> +};

> +enum ili9881c_op {
> +   ILI9881C_SWITCH_PAGE,
> +   ILI9881C_COMMAND,
> +};
> +
> +struct ili9881c_instr {
> +   enum ili9881c_opop;
> +
> +   union arg {
> +   struct cmd {
> +   u8  cmd;
> +   u8  data;
> +   } cmd;
> +   u8  page;
> +   } arg;
> +};
> +
> +#define ILI9881C_SWITCH_PAGE_INSTR(_page)  \
> +   {   \
> +   .op = ILI9881C_SWITCH_PAGE, \
> +   .arg = {\
> +   .page = (_page),\
> +   },  \
> +   }
> +
> +#define ILI9881C_COMMAND_INSTR(_cmd, _data)\
> +   {   \
> +   .op = ILI9881C_COMMAND, \
> +   .arg = {\
> +   .cmd = {\
> +   .cmd = (_cmd),  \
> +   .data = (_data),\
> +   },  \
> +   },  \
> +   }

That looks clever.

> +static const struct ili9881c_instr ili9881c_init[] = {
> +   ILI9881C_SWITCH_PAGE_INSTR(3),
> +   ILI9881C_COMMAND_INSTR(0x01, 0x00),
> +   ILI9881C_COMMAND_INSTR(0x02, 0x00),
> +   ILI9881C_COMMAND_INSTR(0x03, 0x73),
> +   ILI9881C_COMMAND_INSTR(0x04, 0x03),
> +   ILI9881C_COMMAND_INSTR(0x05, 0x00),
> +   ILI9881C_COMMAND_INSTR(0x06, 0x06),
> +   ILI9881C_COMMAND_INSTR(0x07, 0x06),
(...)

This is a bit hard to understand to say the least. If this comes from
a datasheet some more elaborate construction of the commands
would be nice, maybe using some #defines?

If this just comes from some code drop or reverse engineering,
OK bad luck, I can live with it :)

It looks a bit like you're uploading a small firmware.

> +static int ili9881c_switch_page(struct ili9881c *ctx, u8 page)
> +{
> +   u8 buf[4] = { 0xff, 0x98, 0x81, page };

That is also a bit unclear wrt what is going on.

> +static int ili9881c_prepare(struct drm_panel *panel)
> +{
> +   struct ili9881c *ctx = panel_to_ili9881c(panel);
> +   unsigned int i;
> +   int ret;
> +
> +   /* Power the panel */
> +   gpiod_set_value(ctx->power, 1);
> +   msleep(5);

So isn't this a fixed regulator using a GPIO?

> +static const struct drm_display_mode default_mode = {
> +   .clock  = 62000,
> +   .vrefresh   = 60,
> +
> +   .hdisplay   = 720,
> +   .hsync_start= 720 + 10,
> +   .hsync_end  = 720 + 10 + 20,
> +   .htotal = 720 + 10 + 20 + 30,
> +
> +   .vdisplay   = 1280,
> +   .vsync_start= 1280 + 10,
> +   .vsync_end  = 1280 + 10 + 10,
> +   .vtotal = 1280 + 10 + 10 + 20,
> +};

Is that the default mode for this Ilitek device or just for the
BananaPi? If it is the latter it should be named
bananapi_default_mode or something so as not to confuse
the next user of this driver.

> +   ctx->power = devm_gpiod_get(>dev, "power", GPIOD_OUT_LOW);
> +   if (IS_ERR(ctx->power)) {
> +   dev_err(>dev, "Couldn't get our power GPIO\n");
> +   return PTR_ERR(ctx->power);
> +   }

So I'm a bit sceptical about this one.

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Boris Brezillon]

On Fri, 11 May 2018 18:34:50 +0300
Ville Syrjälä  wrote:

> On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > Applying an underscan setup is just a matter of scaling all planes
> > appropriately and adjusting the CRTC X/Y offset to account for the
> > horizontal and vertical border.
> > 
> > Create an vc4_plane_underscan_adj() function doing that and call it from
> > vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> > underscan properties to the HDMI connector.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Changes in v2:
> > - Take changes on hborder/vborder meaning into account
> > ---
> >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
> > -
> >  1 file changed, 48 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
> > b/drivers/gpu/drm/vc4/vc4_plane.c
> > index 71d44c357d35..61ed60841cd6 100644
> > --- a/drivers/gpu/drm/vc4/vc4_plane.c
> > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct drm_plane_state 
> > *state, int plane)
> > }
> >  }
> >  
> > +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> > +{
> > +   struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> > +   struct drm_connector_state *conn_state = NULL;
> > +   struct drm_connector *conn;
> > +   struct drm_crtc_state *crtc_state;
> > +   int i;
> > +
> > +   for_each_new_connector_in_state(pstate->state, conn, conn_state, i) {
> > +   if (conn_state->crtc == pstate->crtc)
> > +   break;
> > +   }
> > +
> > +   if (i == pstate->state->num_connector)
> > +   return 0;
> > +
> > +   if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> > +   return 0;
> > +
> > +   crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> > +  pstate->crtc);
> > +
> > +   if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay ||
> > +   conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> > +   return -EINVAL;  
> 
> border * 2 ?

Oops, indeed. I'll fix that.

> 
> > +
> > +   vc4_pstate->crtc_x += conn_state->underscan.hborder;
> > +   vc4_pstate->crtc_y += conn_state->underscan.vborder;
> > +   vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> > + (crtc_state->mode.hdisplay -
> > +  (conn_state->underscan.hborder * 2))) /
> > +crtc_state->mode.hdisplay;
> > +   vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> > + (crtc_state->mode.vdisplay -
> > +  (conn_state->underscan.vborder * 2))) /
> > +crtc_state->mode.vdisplay;  
> 
> So you're now scaling all planes? The code seems to reject scaling for
> the cursor plane, how are you dealing with that? Or just no cursor
> allowed when underscanning?

No, I just didn't test with a cursor plane. We should probably avoid
scaling the cursor plane and just adjust its position. Eric any opinion
on that?

> 
> I'm also wondering if there's any way we can reconcile these border
> props with the scaling mode prop, should we ever wish to expose
> these props on connectors that already have the scaling mode prop.

Nouveau seems to expose both, and I don't see why we couldn't.

> Maybe we just have to require the scaling mode to be set to fullscreen 
> to allow borders to be specified explictly?
> 
> > +
> > +   if (!vc4_pstate->crtc_w || !vc4_pstate->crtc_h)
> > +   return -EINVAL;
> > +
> > +   return 0;
> > +}
> > +
> >  static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state 
> > *state)
> >  {
> > struct drm_plane *plane = state->plane;
> > @@ -269,7 +312,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
> > drm_plane_state *state)
> > int num_planes = fb->format->num_planes;
> > u32 h_subsample = 1;
> > u32 v_subsample = 1;
> > -   int i;
> > +   int i, ret;
> >  
> > for (i = 0; i < num_planes; i++)
> > vc4_state->offsets[i] = bo->paddr + fb->offsets[i];
> > @@ -292,6 +335,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
> > drm_plane_state *state)
> > vc4_state->crtc_w = state->crtc_w;
> > vc4_state->crtc_h = state->crtc_h;
> >  
> > +   ret = vc4_plane_underscan_adj(state);
> > +   if (ret)
> > +   return ret;
> > +
> > vc4_state->x_scaling[0] = vc4_get_scaling_mode(vc4_state->src_w[0],
> >vc4_state->crtc_w);
> > vc4_state->y_scaling[0] = vc4_get_scaling_mode(vc4_state->src_h[0],
> > -- 
> > 2.14.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel  
> 

___
dri-devel mailing list

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105684

--- Comment #26 from jian-h...@endlessm.com ---
Yes.  System can boot with modprobe.blacklist=amdgpu &
systemd.unit=multi-user.target.

This is the way that I tested and got the dmesg.
I booted with that configuration and got into command line environment.
Than, modprobe efi-pstore which lets the dmesg can be saved into efi storage
when system hangs up.
Then, modprobe amdgpu manually.  If system hangs up at that time, I can get the
dmesg with error information in efi storage at next boot.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v2 12/12] drm/msm/dpu: add error handling in dpu_core_perf_crtc_update

[Sean Paul]

On Fri, May 11, 2018 at 08:19:38PM +0530, Rajesh Yadav wrote:
> dpu_core_perf_crtc_update() is responsible for aggregating
> the data bus bandwidth and dpu core clock rate requirements
> and request the same for all active crtcs.
> Currently, there is no error handling support in this function
> so there is no way caller can know if the perf request fails.
> This change adds error handling code in dpu_core_perf_crtc_update().
> The caller side error handling is not added in this patch.
> 
> Signed-off-by: Rajesh Yadav 

Cool! Thanks for doing this :-)

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 
> ++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  3 ++-
>  2 files changed, 27 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index d3a1ed9..85c0229 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -248,7 +248,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
>   return 0;
>  }
>  
> -static void _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
> +static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
>   struct drm_crtc *crtc, u32 bus_id)
>  {
>   u64 bw_sum_of_intfs = 0, bus_ab_quota, bus_ib_quota;
> @@ -257,6 +257,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
> *kms,
>   = dpu_crtc_get_client_type(crtc);
>   struct drm_crtc *tmp_crtc;
>   struct dpu_crtc_state *dpu_cstate;
> + int ret = 0;
>  
>   drm_for_each_crtc(tmp_crtc, crtc->dev) {
>   if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
> @@ -286,25 +287,28 @@ static void _dpu_core_perf_crtc_update_bus(struct 
> dpu_kms *kms,
>  
>   switch (curr_client_type) {
>   case NRT_CLIENT:
> - dpu_power_data_bus_set_quota(>phandle, kms->core_client,
> + ret = dpu_power_data_bus_set_quota(
> + >phandle, kms->core_client,
>   DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
>   bus_id, bus_ab_quota, bus_ib_quota);
>   DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
> - bus_id, bus_ab_quota, bus_ib_quota);
> +   bus_id, bus_ab_quota, bus_ib_quota);
>   break;
>  
>   case RT_CLIENT:
> - dpu_power_data_bus_set_quota(>phandle, kms->core_client,
> + ret = dpu_power_data_bus_set_quota(
> + >phandle, kms->core_client,
>   DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
>   bus_id, bus_ab_quota, bus_ib_quota);
>   DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
> - bus_id, bus_ab_quota, bus_ib_quota);
> +   bus_id, bus_ab_quota, bus_ib_quota);
>   break;
>  
>   default:
>   DPU_ERROR("invalid client type:%d\n", curr_client_type);
>   break;
>   }
> + return ret;
>  }
>  
>  /**
> @@ -399,7 +403,7 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct 
> dpu_kms *kms)
>   return clk_rate;
>  }
>  
> -void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
> +int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>   int params_changed, bool stop_req)
>  {
>   struct dpu_core_perf_params *new, *old;
> @@ -410,16 +414,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>   int i;
>   struct msm_drm_private *priv;
>   struct dpu_kms *kms;
> + int ret;
>  
>   if (!crtc) {
>   DPU_ERROR("invalid crtc\n");
> - return;
> + return -EINVAL;
>   }
>  
>   kms = _dpu_crtc_get_kms(crtc);
>   if (!kms || !kms->catalog) {
>   DPU_ERROR("invalid kms\n");
> - return;
> + return -EINVAL;
>   }
>   priv = kms->dev->dev_private;
>  
> @@ -482,8 +487,14 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>   update_bus, update_clk);
>  
>   for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
> - if (update_bus & BIT(i))
> - _dpu_core_perf_crtc_update_bus(kms, crtc, i);
> + if (update_bus & BIT(i)) {
> + ret = _dpu_core_perf_crtc_update_bus(kms, crtc, i);
> + if (ret) {
> + DPU_ERROR("crtc-%d: failed to update bw vote 
> for bus-%d\n",
> +   crtc->base.id, i);
> + return ret;
> + }
> + }
>   }
>  
>   /*
> @@ -495,15 +506,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>  
>   

Re: [DPU PATCH v2 11/12] drm/msm/dpu: move dpu_power_handle to dpu folder

[Sean Paul]

On Fri, May 11, 2018 at 08:19:37PM +0530, Rajesh Yadav wrote:
> Now, since dpu_power_handle manages only bus scaling
> and power enable/disable notifications which are restricted
> to dpu driver, move dpu_power_handle to dpu folder.
> 
> Changes in v2:
>   - resolved conflict in dpu_unbind
>   - dropped (Reviewed-by: Sean Paul) due to above change
> 

Reviewed-by: Sean Paul 

> Signed-off-by: Rajesh Yadav 
> ---
>  drivers/gpu/drm/msm/Makefile |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c |   1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c|   5 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   7 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |   2 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  |   1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  39 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h  |   1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 693 
> +++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 288 ++
>  drivers/gpu/drm/msm/dpu_power_handle.c   | 693 
> ---
>  drivers/gpu/drm/msm/dpu_power_handle.h   | 288 --
>  drivers/gpu/drm/msm/msm_drv.c|   9 -
>  drivers/gpu/drm/msm/msm_drv.h|   4 -
>  14 files changed, 1013 insertions(+), 1020 deletions(-)
>  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
>  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
>  delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.c
>  delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.h
> 
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index d9826c1..f578d5a 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -82,10 +82,10 @@ msm-y := \
>   disp/dpu1/dpu_rm.o \
>   disp/dpu1/dpu_vbif.o \
>   disp/dpu1/dpu_mdss.o \
> + disp/dpu1/dpu_power_handle.o \
>   dpu_dbg.o \
>   dpu_io_util.o \
>   dpu_dbg_evtlog.o \
> - dpu_power_handle.o \
>   msm_prop.o \
>   msm_atomic.o \
>   msm_debugfs.o \
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> index 5c5cc56..33ab2ac 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> @@ -18,7 +18,6 @@
>  #include 
>  
>  #include "dpu_core_irq.h"
> -#include "dpu_power_handle.h"
>  
>  /**
>   * dpu_core_irq_callback_handler - dispatch core interrupts
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index 2cf3fca..d3a1ed9 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -257,7 +257,6 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
> *kms,
>   = dpu_crtc_get_client_type(crtc);
>   struct drm_crtc *tmp_crtc;
>   struct dpu_crtc_state *dpu_cstate;
> - struct msm_drm_private *priv = kms->dev->dev_private;
>  
>   drm_for_each_crtc(tmp_crtc, crtc->dev) {
>   if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
> @@ -287,7 +286,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
> *kms,
>  
>   switch (curr_client_type) {
>   case NRT_CLIENT:
> - dpu_power_data_bus_set_quota(>phandle, kms->core_client,
> + dpu_power_data_bus_set_quota(>phandle, kms->core_client,
>   DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
>   bus_id, bus_ab_quota, bus_ib_quota);
>   DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
> @@ -295,7 +294,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
> *kms,
>   break;
>  
>   case RT_CLIENT:
> - dpu_power_data_bus_set_quota(>phandle, kms->core_client,
> + dpu_power_data_bus_set_quota(>phandle, kms->core_client,
>   DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
>   bus_id, bus_ab_quota, bus_ib_quota);
>   DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index e2d2e32..99c5e75 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -598,6 +598,7 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
>   _dpu_crtc_destroy_dest_scaler(dpu_crtc);
>  
>   _dpu_crtc_deinit_events(dpu_crtc);
> + dpu_crtc->phandle = NULL;
>  
>   drm_crtc_cleanup(crtc);
>   mutex_destroy(_crtc->crtc_lock);
> @@ -2572,7 +2573,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
>   }
>  
>   if (dpu_crtc->power_event)
> - 

Re: [DPU PATCH v2 10/12] drm/msm/dpu: use runtime_pm calls in dpu_dbg

[Sean Paul]

On Fri, May 11, 2018 at 08:19:36PM +0530, Rajesh Yadav wrote:
> Currently, msm_drv was creating dpu_power_handle client
> which was used by dpu_dbg module to enable power resources
> before register debug dumping.
> 
> Now since, the mdss core power resource handling is
> implemented via runtime_pm and same has been removed
> from dpu_power_handle. Remove dpu_power_handle dependency
> from msm_drv and use pm_runtime_get/put_sync calls from
> dpu_dbg module on dpu_mdss top level device for core,
> ahb clock and power resource management (for register access).
> 
> Changes in v2:
>   - resolved conflict in dpu_core_perf_init
>   - dropped (Reviewed-by: Sean Paul) due to above change

Reviewed-by: Sean Paul 

> 
> Signed-off-by: Rajesh Yadav 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  7 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  4 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  3 +--
>  drivers/gpu/drm/msm/dpu_dbg.c | 18 +++---
>  drivers/gpu/drm/msm/dpu_dbg.h | 13 ++---
>  drivers/gpu/drm/msm/msm_drv.c | 27 
> +--
>  drivers/gpu/drm/msm/msm_drv.h |  1 -
>  7 files changed, 11 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index 5b79077..2cf3fca 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -673,18 +673,11 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
>   struct drm_device *dev,
>   struct dpu_mdss_cfg *catalog,
>   struct dpu_power_handle *phandle,
> - struct dpu_power_client *pclient,
>   struct dss_clk *core_clk)
>  {
> - if (!pclient) {
> - DPU_ERROR("invalid parameters\n");
> - return -EINVAL;
> - }
> -
>   perf->dev = dev;
>   perf->catalog = catalog;
>   perf->phandle = phandle;
> - perf->pclient = pclient;
>   perf->core_clk = core_clk;
>  
>   perf->max_core_clk_rate = core_clk->max_rate;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> index 9c1a719..cde48df 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> @@ -53,7 +53,6 @@ struct dpu_core_perf_tune {
>   * @debugfs_root: top level debug folder
>   * @catalog: Pointer to catalog configuration
>   * @phandle: Pointer to power handler
> - * @pclient: Pointer to power client
>   * @core_clk: Pointer to core clock structure
>   * @core_clk_rate: current core clock rate
>   * @max_core_clk_rate: maximum allowable core clock rate
> @@ -68,7 +67,6 @@ struct dpu_core_perf {
>   struct dentry *debugfs_root;
>   struct dpu_mdss_cfg *catalog;
>   struct dpu_power_handle *phandle;
> - struct dpu_power_client *pclient;
>   struct dss_clk *core_clk;
>   u64 core_clk_rate;
>   u64 max_core_clk_rate;
> @@ -115,14 +113,12 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>   * @dev: Pointer to drm device
>   * @catalog: Pointer to catalog
>   * @phandle: Pointer to power handle
> - * @pclient: Pointer to power client
>   * @core_clk: pointer to core clock
>   */
>  int dpu_core_perf_init(struct dpu_core_perf *perf,
>   struct drm_device *dev,
>   struct dpu_mdss_cfg *catalog,
>   struct dpu_power_handle *phandle,
> - struct dpu_power_client *pclient,
>   struct dss_clk *core_clk);
>  
>  /**
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 349bda5..9c3b220 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1721,8 +1721,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
>  #endif
>  
>   rc = dpu_core_perf_init(_kms->perf, dev, dpu_kms->catalog,
> - >phandle, priv->pclient,
> - _dpu_kms_get_clk(dpu_kms, "core_clk"));
> + >phandle, _dpu_kms_get_clk(dpu_kms, "core_clk"));
>   if (rc) {
>   DPU_ERROR("failed to init perf %d\n", rc);
>   goto perf_err;
> diff --git a/drivers/gpu/drm/msm/dpu_dbg.c b/drivers/gpu/drm/msm/dpu_dbg.c
> index 4a39b82..27538bc 100644
> --- a/drivers/gpu/drm/msm/dpu_dbg.c
> +++ b/drivers/gpu/drm/msm/dpu_dbg.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "dpu_dbg.h"
>  #include "disp/dpu1/dpu_hw_catalog.h"
> @@ -167,7 +168,6 @@ struct dpu_dbg_vbif_debug_bus {
>   * @evtlog: event log instance
>   * @reg_base_list: list of register dumping regions
>   * @dev: device pointer
> - * @power_ctrl: callback structure for enabling power for reading hw 
> registers
>   * @req_dump_blks: 

Re: [PATCH v4 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation

[Linus Walleij]

On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard  wrote:
> The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
> ILI9881c from Ilitek.
>
> Acked-by: Rob Herring 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v2 08/12] drm/msm/dpu: remove power management code from dpu_power_handle

[Sean Paul]

On Fri, May 11, 2018 at 08:19:34PM +0530, Rajesh Yadav wrote:
> Mdss main power supply (mdss_gdsc) is implemented as a
> generic power domain and mdss top level wrapper device
> manage it via runtime_pm. Remove custom power management
> code from dpu_power_handle.
> 
> Changes in v2:
>   - resolved merge conflict in dpu_power_resource_init
>   - dropped (Reviewed-by: Sean Paul) due to above change
> 
> Signed-off-by: Rajesh Yadav 
> ---
>  drivers/gpu/drm/msm/dpu_power_handle.c | 194 
> +
>  drivers/gpu/drm/msm/dpu_power_handle.h |   2 -
>  2 files changed, 3 insertions(+), 193 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dpu_power_handle.c 
> b/drivers/gpu/drm/msm/dpu_power_handle.c
> index 12602ae..77be106 100644
> --- a/drivers/gpu/drm/msm/dpu_power_handle.c
> +++ b/drivers/gpu/drm/msm/dpu_power_handle.c

/snip

> @@ -614,33 +470,18 @@ int dpu_power_resource_init(struct platform_device 
> *pdev,
>   struct dpu_power_handle *phandle)
>  {
>   int rc = 0, i;
> - struct dss_module_power *mp;
>  
>   if (!phandle || !pdev) {

Can this ever happen? It seems like another case of unnecessary checking.

Aside from this,

Reviewed-by: Sean Paul 


>   pr_err("invalid input param\n");
> - rc = -EINVAL;
> - goto end;
> - }
> - mp = >mp;
> - phandle->dev = >dev;
> -
> - rc = dpu_power_parse_dt_supply(pdev, mp);
> - if (rc) {
> - pr_err("device vreg supply parsing failed\n");
> - return rc;
> + return -EINVAL;
>   }
>  
> - rc = msm_dss_config_vreg(>dev,
> - mp->vreg_config, mp->num_vreg, 1);
> - if (rc) {
> - pr_err("vreg config failed rc=%d\n", rc);
> - goto vreg_err;
> - }
> + phandle->dev = >dev;
>  
>   rc = dpu_power_reg_bus_parse(pdev, phandle);
>   if (rc) {
>   pr_err("register bus parse failed rc=%d\n", rc);
> - goto bus_err;
> + return rc;
>   }
>  
>   for (i = DPU_POWER_HANDLE_DBUS_ID_MNOC;
> @@ -666,19 +507,12 @@ int dpu_power_resource_init(struct platform_device 
> *pdev,
>   for (i--; i >= 0; i--)
>   dpu_power_data_bus_unregister(>data_bus_handle[i]);
>   dpu_power_reg_bus_unregister(phandle->reg_bus_hdl);
> -bus_err:
> - msm_dss_config_vreg(>dev, mp->vreg_config, mp->num_vreg, 0);
> -vreg_err:
> - if (mp->vreg_config)
> - devm_kfree(>dev, mp->vreg_config);
> - mp->num_vreg = 0;
>   return rc;
>  }
>  
>  void dpu_power_resource_deinit(struct platform_device *pdev,
>   struct dpu_power_handle *phandle)
>  {
> - struct dss_module_power *mp;
>   struct dpu_power_client *curr_client, *next_client;
>   struct dpu_power_event *curr_event, *next_event;
>   int i;
> @@ -687,7 +521,6 @@ void dpu_power_resource_deinit(struct platform_device 
> *pdev,
>   pr_err("invalid input param\n");
>   return;
>   }
> - mp = >mp;
>  
>   mutex_lock(>phandle_lock);
>   list_for_each_entry_safe(curr_client, next_client,
> @@ -713,13 +546,6 @@ void dpu_power_resource_deinit(struct platform_device 
> *pdev,
>   dpu_power_data_bus_unregister(>data_bus_handle[i]);
>  
>   dpu_power_reg_bus_unregister(phandle->reg_bus_hdl);
> -
> - msm_dss_config_vreg(>dev, mp->vreg_config, mp->num_vreg, 0);
> -
> - if (mp->vreg_config)
> - devm_kfree(>dev, mp->vreg_config);
> -
> - mp->num_vreg = 0;
>  }
>  
>  int dpu_power_resource_enable(struct dpu_power_handle *phandle,
> @@ -729,15 +555,12 @@ int dpu_power_resource_enable(struct dpu_power_handle 
> *phandle,
>   bool changed = false;
>   u32 max_usecase_ndx = VOTE_INDEX_DISABLE, prev_usecase_ndx;
>   struct dpu_power_client *client;
> - struct dss_module_power *mp;
>  
>   if (!phandle || !pclient) {
>   pr_err("invalid input argument\n");
>   return -EINVAL;
>   }
>  
> - mp = >mp;
> -
>   mutex_lock(>phandle_lock);
>   if (enable)
>   pclient->refcount++;
> @@ -782,13 +605,6 @@ int dpu_power_resource_enable(struct dpu_power_handle 
> *phandle,
>   }
>   }
>  
> - rc = msm_dss_enable_vreg(mp->vreg_config, mp->num_vreg,
> - enable);
> - if (rc) {
> - pr_err("failed to enable vregs rc=%d\n", rc);
> - goto vreg_err;
> - }
> -
>   rc = dpu_power_reg_bus_update(phandle->reg_bus_hdl,
>   max_usecase_ndx);
>   if (rc) {
> @@ -806,8 +622,6 @@ int dpu_power_resource_enable(struct dpu_power_handle 
> *phandle,
>   dpu_power_reg_bus_update(phandle->reg_bus_hdl,
>   

Re: [DPU PATCH v2 07/12] drm/msm/dpu: remove clock management code from dpu_power_handle

[Sean Paul]

On Fri, May 11, 2018 at 08:19:33PM +0530, Rajesh Yadav wrote:
> MDSS and dpu drivers manage their respective clocks via
> runtime_pm. Remove custom clock management code from
> dpu_power_handle.
> 
> Also dpu core clock management code is restricted to
> dpu_core_perf module.
> 
> Changes in v2:
>   - remove local variable to hold and return error code
> in _dpu_core_perf_set_core_clk_rate() instead return
> retcode directly from msm_dss_clk_set_rate() call (Sean Paul)
>   - dpu_core_perf_init() is called from dpu_kms_hw_init() and
> most of the params passed are already validated so remove
> redundant checks from dpu_core_perf_init() (Sean Paul)
>   - return >clk_config[i] directly to avoid local variable
> in _dpu_kms_get_clk() (Sean Paul)
>   - invert conditional check to eliminate local rate variable
> from dpu_kms_get_clk_rate() (Sean Paul)
>   - remove end label from dpu_power_resource_init() and return
> directly on dpu_power_parse_dt_supply() failure as no cleanup
> is needed (Sean Paul)
>   - remove checks for vtotal and vrefresh from
> dpu_encoder_phys_cmd_tearcheck_config() as they should be
> valid in mode_set call (Sean Paul)
> 
> Signed-off-by: Rajesh Yadav 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  41 ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h  |   8 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   9 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  28 ++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   9 +
>  drivers/gpu/drm/msm/dpu_power_handle.c | 196 
> +
>  drivers/gpu/drm/msm/dpu_power_handle.h |  40 -
>  7 files changed, 63 insertions(+), 268 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index 981f77f..5b79077 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -365,6 +365,17 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
>   }
>  }
>  
> +static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> +{
> + struct dss_clk *core_clk = kms->perf.core_clk;
> +
> + if (core_clk->max_rate && (rate > core_clk->max_rate))
> + rate = core_clk->max_rate;
> +
> + core_clk->rate = rate;
> + return msm_dss_clk_set_rate(core_clk, 1);
> +}
> +
>  static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
>  {
>   u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> @@ -376,7 +387,8 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct 
> dpu_kms *kms)
>   dpu_cstate = to_dpu_crtc_state(crtc->state);
>   clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
>   clk_rate);
> - clk_rate = clk_round_rate(kms->perf.core_clk, clk_rate);
> + clk_rate = clk_round_rate(kms->perf.core_clk->clk,
> + clk_rate);
>   }
>   }
>  
> @@ -484,15 +496,11 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
>  
>   DPU_EVT32(kms->dev, stop_req, clk_rate);
>  
> - /* Temp change to avoid crash in clk_set_rate API. */
> -#ifdef QCOM_DPU_SET_CLK
> - if (dpu_power_clk_set_rate(>phandle,
> -kms->perf.clk_name, clk_rate)) {
> + if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
>   DPU_ERROR("failed to set %s clock rate %llu\n",
> - kms->perf.clk_name, clk_rate);
> + kms->perf.core_clk->clk_name, clk_rate);
>   return;
>   }
> -#endif
>  
>   kms->perf.core_clk_rate = clk_rate;
>   DPU_DEBUG("update clk rate = %lld HZ\n", clk_rate);
> @@ -656,7 +664,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
>   dpu_core_perf_debugfs_destroy(perf);
>   perf->max_core_clk_rate = 0;
>   perf->core_clk = NULL;
> - perf->clk_name = NULL;
>   perf->phandle = NULL;
>   perf->catalog = NULL;
>   perf->dev = NULL;
> @@ -667,9 +674,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
>   struct dpu_mdss_cfg *catalog,
>   struct dpu_power_handle *phandle,
>   struct dpu_power_client *pclient,
> - char *clk_name)
> + struct dss_clk *core_clk)
>  {
> - if (!perf || !dev || !catalog || !phandle || !pclient || !clk_name) {
> + if (!pclient) {
>   DPU_ERROR("invalid parameters\n");
>   return -EINVAL;
>   }
> @@ -678,23 +685,13 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
>   

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Ville Syrjälä]

On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> Applying an underscan setup is just a matter of scaling all planes
> appropriately and adjusting the CRTC X/Y offset to account for the
> horizontal and vertical border.
> 
> Create an vc4_plane_underscan_adj() function doing that and call it from
> vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
> underscan properties to the HDMI connector.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Take changes on hborder/vborder meaning into account
> ---
>  drivers/gpu/drm/vc4/vc4_plane.c | 49 
> -
>  1 file changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 71d44c357d35..61ed60841cd6 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct drm_plane_state 
> *state, int plane)
>   }
>  }
>  
> +static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
> +{
> + struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
> + struct drm_connector_state *conn_state = NULL;
> + struct drm_connector *conn;
> + struct drm_crtc_state *crtc_state;
> + int i;
> +
> + for_each_new_connector_in_state(pstate->state, conn, conn_state, i) {
> + if (conn_state->crtc == pstate->crtc)
> + break;
> + }
> +
> + if (i == pstate->state->num_connector)
> + return 0;
> +
> + if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
> + return 0;
> +
> + crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
> +pstate->crtc);
> +
> + if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay ||
> + conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
> + return -EINVAL;

border * 2 ?

> +
> + vc4_pstate->crtc_x += conn_state->underscan.hborder;
> + vc4_pstate->crtc_y += conn_state->underscan.vborder;
> + vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
> +   (crtc_state->mode.hdisplay -
> +(conn_state->underscan.hborder * 2))) /
> +  crtc_state->mode.hdisplay;
> + vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
> +   (crtc_state->mode.vdisplay -
> +(conn_state->underscan.vborder * 2))) /
> +  crtc_state->mode.vdisplay;

So you're now scaling all planes? The code seems to reject scaling for
the cursor plane, how are you dealing with that? Or just no cursor
allowed when underscanning?

I'm also wondering if there's any way we can reconcile these border
props with the scaling mode prop, should we ever wish to expose
these props on connectors that already have the scaling mode prop.
Maybe we just have to require the scaling mode to be set to fullscreen 
to allow borders to be specified explictly?

> +
> + if (!vc4_pstate->crtc_w || !vc4_pstate->crtc_h)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
>  static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state 
> *state)
>  {
>   struct drm_plane *plane = state->plane;
> @@ -269,7 +312,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
> drm_plane_state *state)
>   int num_planes = fb->format->num_planes;
>   u32 h_subsample = 1;
>   u32 v_subsample = 1;
> - int i;
> + int i, ret;
>  
>   for (i = 0; i < num_planes; i++)
>   vc4_state->offsets[i] = bo->paddr + fb->offsets[i];
> @@ -292,6 +335,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
> drm_plane_state *state)
>   vc4_state->crtc_w = state->crtc_w;
>   vc4_state->crtc_h = state->crtc_h;
>  
> + ret = vc4_plane_underscan_adj(state);
> + if (ret)
> + return ret;
> +
>   vc4_state->x_scaling[0] = vc4_get_scaling_mode(vc4_state->src_w[0],
>  vc4_state->crtc_w);
>   vc4_state->y_scaling[0] = vc4_get_scaling_mode(vc4_state->src_h[0],
> -- 
> 2.14.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v2 04/12] drm/msm/dpu: create new platform driver for dpu device

[Sean Paul]

On Fri, May 11, 2018 at 08:19:30PM +0530, Rajesh Yadav wrote:
> Current MSM display controller HW matches a tree like
> hierarchy where MDSS top level wrapper is parent device
> and mdp5/dpu, dsi, dp are child devices.
> 
> Each child device like mdp5, dsi etc. have a separate driver,
> but currently dpu handling is tied to a single driver which
> was managing both mdss and dpu resources.
> 
> Inorder to have the cleaner one to one device and driver
> association, this change adds a new platform_driver for dpu
> child device node which implements the kms functionality.
> 
> The dpu driver implements runtime_pm support for managing clocks
> and bus bandwidth etc.
> 
> Changes in v2:
>   - remove redundant param check from _dpu_kms_hw_destroy (Sean Paul)
>   - remove explicit calls to devm_kfree (Sean Paul)
>   - merge dpu_init into dpu_bind (Sean Paul)
>   - merge dpu_destroy into dpu_unbind (Sean Paul)
>   - use %pK for kernel pointer printing (Jordan Crouse)
>   - remove explicit devm allocation failure message (Jordan Crouse)
> 
> Signed-off-by: Rajesh Yadav 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 238 
> +---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   4 +
>  drivers/gpu/drm/msm/msm_drv.c   |   2 +
>  drivers/gpu/drm/msm/msm_drv.h   |   3 +
>  4 files changed, 196 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index e4ab753..85f3dbc 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1030,16 +1030,12 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms, 
> unsigned long rate,
>   return rate;
>  }
>  
> -static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
> - struct platform_device *pdev)
> +static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
>  {
>   struct drm_device *dev;
>   struct msm_drm_private *priv;
>   int i;
>  
> - if (!dpu_kms || !pdev)
> - return;
> -
>   dev = dpu_kms->dev;
>   if (!dev)
>   return;
> @@ -1091,15 +1087,15 @@ static void _dpu_kms_hw_destroy(struct dpu_kms 
> *dpu_kms,
>   dpu_kms->core_client = NULL;
>  
>   if (dpu_kms->vbif[VBIF_NRT])
> - msm_iounmap(pdev, dpu_kms->vbif[VBIF_NRT]);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_NRT]);
>   dpu_kms->vbif[VBIF_NRT] = NULL;
>  
>   if (dpu_kms->vbif[VBIF_RT])
> - msm_iounmap(pdev, dpu_kms->vbif[VBIF_RT]);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_RT]);
>   dpu_kms->vbif[VBIF_RT] = NULL;
>  
>   if (dpu_kms->mmio)
> - msm_iounmap(pdev, dpu_kms->mmio);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->mmio);
>   dpu_kms->mmio = NULL;
>  
>   dpu_reg_dma_deinit();
> @@ -1172,8 +1168,6 @@ int dpu_kms_mmu_attach(struct dpu_kms *dpu_kms, bool 
> secure_only)
>  static void dpu_kms_destroy(struct msm_kms *kms)
>  {
>   struct dpu_kms *dpu_kms;
> - struct drm_device *dev;
> - struct platform_device *platformdev;
>  
>   if (!kms) {
>   DPU_ERROR("invalid kms\n");
> @@ -1181,20 +1175,7 @@ static void dpu_kms_destroy(struct msm_kms *kms)
>   }
>  
>   dpu_kms = to_dpu_kms(kms);
> - dev = dpu_kms->dev;
> - if (!dev) {
> - DPU_ERROR("invalid device\n");
> - return;
> - }
> -
> - platformdev = to_platform_device(dev->dev);
> - if (!platformdev) {
> - DPU_ERROR("invalid platform device\n");
> - return;
> - }
> -
> - _dpu_kms_hw_destroy(dpu_kms, platformdev);
> - kfree(dpu_kms);
> + _dpu_kms_hw_destroy(dpu_kms);
>  }
>  
>  static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
> @@ -1550,7 +1531,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
>   struct dpu_kms *dpu_kms;
>   struct drm_device *dev;
>   struct msm_drm_private *priv;
> - struct platform_device *platformdev;
>   int i, rc = -EINVAL;
>  
>   if (!kms) {
> @@ -1565,34 +1545,28 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
>   goto end;
>   }
>  
> - platformdev = to_platform_device(dev->dev);
> - if (!platformdev) {
> - DPU_ERROR("invalid platform device\n");
> - goto end;
> - }
> -
>   priv = dev->dev_private;
>   if (!priv) {
>   DPU_ERROR("invalid private data\n");
>   goto end;
>   }
>  
> - dpu_kms->mmio = msm_ioremap(platformdev, "mdp_phys", "mdp_phys");
> + dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp_phys", "mdp_phys");
>   if (IS_ERR(dpu_kms->mmio)) {
>   rc = PTR_ERR(dpu_kms->mmio);
>   DPU_ERROR("mdp register memory map failed: %d\n", rc);
>   dpu_kms->mmio = NULL;
>  

Re: [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[Sean Paul]

On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:
> SoCs containing dpu have a MDSS top level wrapper
> which includes sub-blocks as dpu, dsi, phy, dp etc.
> MDSS top level wrapper manages common resources like
> common clocks, power and irq for its sub-blocks.
> 
> Currently, in dpu driver, all the power resource
> management is part of power_handle which manages
> these resources via a custom implementation. And
> the resource relationships are not modelled properly
> in dt.  Moreover the irq domain handling code is part
> of dpu device (which is a child device) due to lack
> of a dedicated driver for MDSS top level wrapper
> device.
> 
> This change adds dpu_mdss top level driver to handle
> common clock like - core clock, ahb clock
> (for register access), main power supply (i.e. gdsc)
> and irq management.
> The top level mdss device/driver acts as an interrupt
> controller and manage hwirq mapping for its child
> devices.
> 
> It implements runtime_pm support for resource management.
> Child nodes can control these resources via runtime_pm
> get/put calls on their corresponding devices due to parent
> child relationship defined in dt.
> 
> Changes in v2:
>   - merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
>   - merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
>   - fix indentation for irq_find_mapping call (Sean Paul)
>   - remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
>   - remove redundant param checks from
> dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
>   - remove redundant param checks from
> dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
>   - return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
> Crouse)
>   - remove redundant param check from dpu_mdss_destroy (Sean Paul)
>   - remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
>   - remove compatibility check from dpu_mdss_init as
> it is conditionally called from msm_drv (Sean Paul)
>   - reworked msm_dss_parse_clock() to add return checks for
> of_property_read_* calls, fix log message and
> fix alignment issues (Sean Paul/Jordan Crouse)
>   - remove extra line before dpu_mdss_init (Sean Paul)
>   - remove redundant param checks from __intr_offset and
> make it a void function to avoid unnecessary error
> handling from caller (Jordan Crouse)
>   - remove redundant param check from dpu_mdss_irq (Jordan Crouse)
>   - change mdss address space log message to debug and use %pK for
> kernel pointers (Jordan Crouse)
>   - remove unnecessary log message from msm_dss_parse_clock (Jordan 
> Crouse)
>   - don't export msm_dss_parse_clock since it is used
> only by dpu driver (Jordan Crouse)
> 
> Signed-off-by: Rajesh Yadav 
> ---
>  drivers/gpu/drm/msm/Makefile  |   1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 254 
> ++
>  drivers/gpu/drm/msm/dpu_io_util.c |  57 +
>  drivers/gpu/drm/msm/msm_drv.c |  26 ++-
>  drivers/gpu/drm/msm/msm_drv.h |   2 +-
>  drivers/gpu/drm/msm/msm_kms.h |   1 +
>  include/linux/dpu_io_util.h   |   2 +
>  16 files changed, 339 insertions(+), 226 deletions(-)
>  create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> 

/snip

> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> new file mode 100644
> index 000..ce680ea
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c

/snip

> +
> +int dpu_mdss_init(struct drm_device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev->dev);
> + struct msm_drm_private *priv = dev->dev_private;
> + struct dpu_mdss *dpu_mdss;
> + struct dss_module_power *mp;
> + int ret = 0;
> +
> + dpu_mdss = devm_kzalloc(dev->dev, sizeof(*dpu_mdss), GFP_KERNEL);
> + if (!dpu_mdss)
> + return -ENOMEM;
> +
> + dpu_mdss->mmio = msm_ioremap(pdev, "mdss_phys", "mdss_phys");
> + if (IS_ERR(dpu_mdss->mmio)) {
> + ret = PTR_ERR(dpu_mdss->mmio);

remove this ...

> + DPU_ERROR("mdss register memory map failed: %d\n", ret);
> + dpu_mdss->mmio = NULL;
> + return ret;

... and replace 

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #17 from Thomas Martitz  ---
Done, https://bugzilla.kernel.org/show_bug.cgi?id=199693

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105684

--- Comment #25 from Alex Deucher  ---
Does the system boot ok with amdgpu blacklisted?  E.g., append
modprobe.blacklist=amdgpu to the kernel command line in grub and boot to a
non-GUI runlevel.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #16 from Alex Deucher  ---
(In reply to Thomas Martitz from comment #15)
> 
> So, what to do with this information / potential fix?

Please file a bug as per comment 10 and include that information.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #15 from Thomas Martitz  ---
I investigated the commit found by git bisect a bit more, and found that the
following patch (which reverts part of said commit) repairs resuming.

I can't tell the consequences, however reading the commit message suggests this
part is non-critical:

> While at it, make the core check pm_runtime_suspended() when
> setting power.direct_complete so that it doesn't need to be
> checked by ->prepare callbacks.

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 02a497e7c785..028c14386e5d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1959,9 +1959,7 @@ static int device_prepare(struct device *dev,
pm_message_t state)
 * applies to suspend transitions, however.
 */
spin_lock_irq(>power.lock);
-   dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
-   pm_runtime_suspended(dev) && ret > 0 &&
-   !dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
+   dev->power.direct_complete = ret > 0 && state.event ==
PM_EVENT_SUSPEND;
spin_unlock_irq(>power.lock);
return 0;
 }

So, what to do with this information / potential fix?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm/rockchip: support dp training outside dp firmware

[Sean Paul]

On Wed, May 09, 2018 at 06:22:44PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So if the phy is using custom config values, do software
> link training instead of relying on firmware, if software training
> fail, keep firmware training as a fallback if sw training fails.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 

FTR, I've previously reviewed this patch at
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/985573

> ---
> Changes in v2:
> - update patch following Enric suggest
> 
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 391 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  34 ++-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 479 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> 

/snip

> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..c6050ab 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
>   bool connected;
>   bool active;
>   bool suspended;
> + bool sw_training_success;

Can you change this to use_fw_training instead? So it will be false if sw
training succeeds, and true if sw training fails and needs to fallback to fw.

>  
>   const struct firmware *fw;  /* cdn dp firmware */
>   unsigned int fw_version;/* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
>   u8 ports;
>   u8 lanes;
>   int active_port;
> + u8 train_set[4];
>  
>   u8 dpcd[DP_RECEIVER_CAP_SIZE];
>   bool sink_has_audio;

/snip

> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index afdfda0..bd0aed5 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -17,7 +17,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  
>  #include "cdn-dp-core.h"
>  #include "cdn-dp-reg.h"
> @@ -189,7 +191,7 @@ static int cdn_dp_mailbox_send(struct cdn_dp_device *dp, 
> u8 module_id,
>   return 0;
>  }
>  
> -static int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
> +int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
>  {
>   u8 msg[6];
>  
> @@ -606,7 +608,35 @@ static int cdn_dp_get_training_status(struct 
> cdn_dp_device *dp)
>  int cdn_dp_train_link(struct cdn_dp_device *dp)
>  {
>   int ret;
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
>  
> + /*
> +  * DP firmware uses fixed phy config values to do training, but some
> +  * boards need to adjust these values to fit for their unique hardware
> +  * design. So if the phy is using custom config values, do software
> +  * link training instead of relying on firmware, if software training
> +  * fail, keep firmware training as a fallback if sw training fails.
> +  */
> + if (tcphy->need_software_training) {

As discussed in the downstream review, I'd rather default to sw training and
fallback to fw training if we must.

> + ret = cdn_dp_software_train_link(dp);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to do software training %d\n", ret);
> + goto do_fw_training;
> + }
> + ret = cdn_dp_reg_write(dp, SOURCE_HDTX_CAR, 0xf);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to write SOURCE_HDTX_CAR register %d\n", ret);
> + goto do_fw_training;
> + }
> + dp->sw_training_success = true;
> + return 0;
> + }
> +
> +do_fw_training:
> + dp->sw_training_success = false;

Can you please add a DRM_DEBUG_KMS log message here?

>   ret = cdn_dp_training_start(dp);
>   if (ret) {
>   DRM_DEV_ERROR(dp->dev, "Failed to start training %d\n", ret);
> @@ -621,7 +651,7 @@ int cdn_dp_train_link(struct cdn_dp_device *dp)
>  
>   DRM_DEV_DEBUG_KMS(dp->dev, "rate:0x%x, lanes:%d\n", dp->link.rate,
> dp->link.num_lanes);
> - return ret;
> + return 0;
>  }
>  
>  int cdn_dp_set_video_status(struct cdn_dp_device *dp, int active)
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index 6580b11..3420771 100644
> --- 

[PATCH v2 4/4] drm/nouveau: Switch to the generic underscan props

[Boris Brezillon]

Now that underscan props can be parsed by the core and assigned to
conn_state->underscan.xxx, we can rely on this implementation and get
rid of the nouveau-specific underscan props.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 39 +
 drivers/gpu/drm/nouveau/nouveau_connector.h |  9 ---
 drivers/gpu/drm/nouveau/nouveau_display.c   | 14 ---
 drivers/gpu/drm/nouveau/nouveau_display.h   |  3 ---
 drivers/gpu/drm/nouveau/nv50_display.c  | 17 +
 5 files changed, 18 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 6ed9cb053dfa..0ce055d3b89e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -105,12 +105,6 @@ nouveau_conn_atomic_get_property(struct drm_connector 
*connector,
 
if (property == dev->mode_config.scaling_mode_property)
*val = asyc->scaler.mode;
-   else if (property == disp->underscan_property)
-   *val = asyc->scaler.underscan.mode;
-   else if (property == disp->underscan_hborder_property)
-   *val = asyc->scaler.underscan.hborder;
-   else if (property == disp->underscan_vborder_property)
-   *val = asyc->scaler.underscan.vborder;
else if (property == disp->dithering_mode)
*val = asyc->dither.mode;
else if (property == disp->dithering_depth)
@@ -170,24 +164,6 @@ nouveau_conn_atomic_set_property(struct drm_connector 
*connector,
asyc->set.scaler = true;
}
} else
-   if (property == disp->underscan_property) {
-   if (asyc->scaler.underscan.mode != val) {
-   asyc->scaler.underscan.mode = val;
-   asyc->set.scaler = true;
-   }
-   } else
-   if (property == disp->underscan_hborder_property) {
-   if (asyc->scaler.underscan.hborder != val) {
-   asyc->scaler.underscan.hborder = val;
-   asyc->set.scaler = true;
-   }
-   } else
-   if (property == disp->underscan_vborder_property) {
-   if (asyc->scaler.underscan.vborder != val) {
-   asyc->scaler.underscan.vborder = val;
-   asyc->set.scaler = true;
-   }
-   } else
if (property == disp->dithering_mode) {
if (asyc->dither.mode != val) {
asyc->dither.mode = val;
@@ -256,7 +232,6 @@ nouveau_conn_reset(struct drm_connector *connector)
asyc->dither.mode = DITHERING_MODE_AUTO;
asyc->dither.depth = DITHERING_DEPTH_AUTO;
asyc->scaler.mode = DRM_MODE_SCALE_NONE;
-   asyc->scaler.underscan.mode = UNDERSCAN_OFF;
asyc->procamp.color_vibrance = 150;
asyc->procamp.vibrant_hue = 90;
 
@@ -285,18 +260,16 @@ nouveau_conn_attach_properties(struct drm_connector 
*connector)
   dvi_i_subconnector_property, 0);
 
/* Add overscan compensation options to digital outputs. */
-   if (disp->underscan_property &&
+   if (disp->disp.oclass >= NV50_DISP &&
(connector->connector_type == DRM_MODE_CONNECTOR_DVID ||
 connector->connector_type == DRM_MODE_CONNECTOR_DVII ||
 connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
 connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)) {
-   drm_object_attach_property(>base,
-  disp->underscan_property,
-  UNDERSCAN_OFF);
-   drm_object_attach_property(>base,
-  disp->underscan_hborder_property, 0);
-   drm_object_attach_property(>base,
-  disp->underscan_vborder_property, 0);
+   WARN_ON(drm_connector_attach_underscan_properties(connector,
+   BIT(DRM_UNDERSCAN_OFF) |
+   BIT(DRM_UNDERSCAN_ON) |
+   BIT(DRM_UNDERSCAN_AUTO),
+   128, 128));
}
 
/* Add hue and saturation options. */
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index a4d1a059bd3d..1d3ec65288e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -111,15 +111,6 @@ struct nouveau_conn_atom {
 
struct {
int mode;   /* DRM_MODE_SCALE_* */
-   struct {
-   enum {
-   UNDERSCAN_OFF,
-   UNDERSCAN_ON,
-   

[PATCH v2 1/4] drm/connector: Add generic underscan properties

[Boris Brezillon]

We have 3 drivers defining the "underscan", "underscan hborder" and
"underscan vborder" properties (radeon, amd and nouveau) and we are
about to add the same kind of thing in VC4.

Define generic underscan props and add new fields to the drm_connector
state so that the property parsing logic can be shared by all DRM
drivers.

A driver can now attach underscan properties to its connector through
the drm_connector_attach_underscan_properties() helper, and can
check/apply the underscan setup based on the
drm_connector_state->underscan fields.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Add a new section in the connector props doc to describe underscan
  props
- Fix description of auto mode (auto means apply underscan for HDMI
  monitors only)
- Fix description of vborder/hborder:
right_border = left_border = hborder
top_border = bottom_border = vborder
  not
right_border = left_border = hborder / 2
top_border = bottom_border = vborder / 2
- Rename drm_underscan into drm_underscan_state
---
 drivers/gpu/drm/drm_atomic.c|  12 
 drivers/gpu/drm/drm_connector.c | 127 
 include/drm/drm_connector.h |  80 +
 3 files changed, 219 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index dc850b4b6e21..b7312bd172c9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1278,6 +1278,12 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->underscan_mode_property) {
+   state->underscan.mode = val;
+   } else if (property == connector->underscan_hborder_property) {
+   state->underscan.hborder = val;
+   } else if (property == connector->underscan_vborder_property) {
+   state->underscan.vborder = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1359,6 +1365,12 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
*val = state->content_protection;
+   } else if (property == connector->underscan_mode_property) {
+   *val = state->underscan.mode;
+   } else if (property == connector->underscan_hborder_property) {
+   *val = state->underscan.hborder;
+   } else if (property == connector->underscan_vborder_property) {
+   *val = state->underscan.vborder;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9b9ba5d5ec0c..826af6267a4f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -914,6 +914,38 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, 
drm_cp_enum_list)
  * can also expose this property to external outputs, in which case they
  * must support "None", which should be the default (since external screens
  * have a built-in scaler).
+ *
+ * Connectors for non-analog outputs may also have standardized underscan
+ * properties (drivers can set this up by calling
+ * drm_connector_attach_content_protection_property() on initialization):
+ *
+ * underscan:
+ * This properties defines whether underscan is activated or not, and when
+ * it is activated, how the horizontal and vertical borders are calculated:
+ *
+ * off:
+ * Underscan is disabled. The output image shouldn't be scaled to
+ * take screen borders into account.
+ * on:
+ * Underscan is activated and horizontal and vertical borders are
+ * specified through the "underscan hborder" and
+ * "underscan vborder" properties.
+ * auto:
+ * Underscan is activated only for HDMI monitors.
+ *
+ * underscan hborder:
+ * Horizontal border expressed in pixels. The border is symmetric, which
+ * means you'll have a border of 'hborder' pixels on the left and on the
+ * same border on the right.
+ * When this value is 0 and underscan is "on" or "auto", the driver will
+ * pick a default value (the default value is driver dependent).
+ *
+ * underscan vborder:
+ * Vertical border expressed in pixels. The border is symmetric, which
+ * means you'll have a border of 'vborder' pixels on the top and the same
+ * border on the bottom.
+ * When this value is 0 and underscan is "on" or "auto", the driver will
+ * pick a default value (the 

[PATCH v2 3/4] drm/vc4: Attach underscan props to the HDMI connector

[Boris Brezillon]

Now that the plane code takes the underscan setup into account, we can
safely attach the underscan props to the HDMI connector.

We also take care of filling AVI infoframes correctly to expose the
top/botton/left/right bar.

Note that these underscan props match pretty well the
overscan_{left,right,top,bottom} properties defined in config.txt and
parsed by the VC4 firmware.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- none
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1a6db291d48b..17464b5981f9 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -323,6 +323,16 @@ static struct drm_connector 
*vc4_hdmi_connector_init(struct drm_device *dev,
   DRM_MODE_CONNECTOR_HDMIA);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
 
+   /* The hborder and vborder limit is arbitrarily set to 1024 which
+* should be more than enough for real use cases. Note that the actual
+* limitation comes from the display mode:
+*  hborder < hdisplay && vborder < vdisplay
+*/
+   drm_connector_attach_underscan_properties(connector,
+ BIT(DRM_UNDERSCAN_OFF) |
+ BIT(DRM_UNDERSCAN_ON),
+ 1024, 1024);
+
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
 DRM_CONNECTOR_POLL_DISCONNECT);
 
@@ -408,6 +418,9 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder 
*encoder,
 static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
 {
struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
+   struct vc4_dev *vc4 = encoder->dev->dev_private;
+   struct vc4_hdmi *hdmi = vc4->hdmi;
+   struct drm_connector_state *cstate = hdmi->connector->state;
struct drm_crtc *crtc = encoder->crtc;
const struct drm_display_mode *mode = >state->adjusted_mode;
union hdmi_infoframe frame;
@@ -426,6 +439,18 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder)
   vc4_encoder->rgb_range_selectable,
   false);
 
+   if (cstate->underscan.mode == DRM_UNDERSCAN_ON) {
+   if (cstate->underscan.hborder) {
+   frame.avi.right_bar = cstate->underscan.hborder / 2;
+   frame.avi.left_bar = frame.avi.right_bar;
+   }
+
+   if (cstate->underscan.vborder) {
+   frame.avi.top_bar = cstate->underscan.vborder / 2;
+   frame.avi.bottom_bar = frame.avi.top_bar;
+   }
+   }
+
vc4_hdmi_write_infoframe(encoder, );
 }
 
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/4] drm/connector: Provide generic support for underscan

[Boris Brezillon]

Hello,

This is an attempt at providing generic support for underscan connector
props. We already have 3 drivers defining the same underscan, underscan
vborder and underscan hborder properties (amd, radeon and nouveau) and
I am about to add a new one, hence my proposal to put the prop parsing
code in the core and add ->underscan fields to drm_connector_state.

In this v2, I also converted the nouveau driver to the generic
approach. The amdgpu and radeon ones can't be converted since they're
still not converted to the atomic interface.

Regards,

Boris 

Boris Brezillon (4):
  drm/connector: Add generic underscan properties
  drm/vc4: Take underscan setup into account when updating planes
  drm/vc4: Attach underscan props to the HDMI connector
  drm/nouveau: Switch to the generic underscan props

 drivers/gpu/drm/drm_atomic.c|  12 +++
 drivers/gpu/drm/drm_connector.c | 127 
 drivers/gpu/drm/nouveau/nouveau_connector.c |  39 ++---
 drivers/gpu/drm/nouveau/nouveau_connector.h |   9 --
 drivers/gpu/drm/nouveau/nouveau_display.c   |  14 ---
 drivers/gpu/drm/nouveau/nouveau_display.h   |   3 -
 drivers/gpu/drm/nouveau/nv50_display.c  |  17 ++--
 drivers/gpu/drm/vc4/vc4_hdmi.c  |  25 ++
 drivers/gpu/drm/vc4/vc4_plane.c |  49 ++-
 include/drm/drm_connector.h |  80 ++
 10 files changed, 310 insertions(+), 65 deletions(-)

-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Boris Brezillon]

Applying an underscan setup is just a matter of scaling all planes
appropriately and adjusting the CRTC X/Y offset to account for the
horizontal and vertical border.

Create an vc4_plane_underscan_adj() function doing that and call it from
vc4_plane_setup_clipping_and_scaling() so that we are ready to attach
underscan properties to the HDMI connector.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Take changes on hborder/vborder meaning into account
---
 drivers/gpu/drm/vc4/vc4_plane.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 71d44c357d35..61ed60841cd6 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct drm_plane_state 
*state, int plane)
}
 }
 
+static int vc4_plane_underscan_adj(struct drm_plane_state *pstate)
+{
+   struct vc4_plane_state *vc4_pstate = to_vc4_plane_state(pstate);
+   struct drm_connector_state *conn_state = NULL;
+   struct drm_connector *conn;
+   struct drm_crtc_state *crtc_state;
+   int i;
+
+   for_each_new_connector_in_state(pstate->state, conn, conn_state, i) {
+   if (conn_state->crtc == pstate->crtc)
+   break;
+   }
+
+   if (i == pstate->state->num_connector)
+   return 0;
+
+   if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
+   return 0;
+
+   crtc_state = drm_atomic_get_new_crtc_state(pstate->state,
+  pstate->crtc);
+
+   if (conn_state->underscan.hborder >= crtc_state->mode.hdisplay ||
+   conn_state->underscan.vborder >= crtc_state->mode.vdisplay)
+   return -EINVAL;
+
+   vc4_pstate->crtc_x += conn_state->underscan.hborder;
+   vc4_pstate->crtc_y += conn_state->underscan.vborder;
+   vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
+ (crtc_state->mode.hdisplay -
+  (conn_state->underscan.hborder * 2))) /
+crtc_state->mode.hdisplay;
+   vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
+ (crtc_state->mode.vdisplay -
+  (conn_state->underscan.vborder * 2))) /
+crtc_state->mode.vdisplay;
+
+   if (!vc4_pstate->crtc_w || !vc4_pstate->crtc_h)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int vc4_plane_setup_clipping_and_scaling(struct drm_plane_state *state)
 {
struct drm_plane *plane = state->plane;
@@ -269,7 +312,7 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
drm_plane_state *state)
int num_planes = fb->format->num_planes;
u32 h_subsample = 1;
u32 v_subsample = 1;
-   int i;
+   int i, ret;
 
for (i = 0; i < num_planes; i++)
vc4_state->offsets[i] = bo->paddr + fb->offsets[i];
@@ -292,6 +335,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct 
drm_plane_state *state)
vc4_state->crtc_w = state->crtc_w;
vc4_state->crtc_h = state->crtc_h;
 
+   ret = vc4_plane_underscan_adj(state);
+   if (ret)
+   return ret;
+
vc4_state->x_scaling[0] = vc4_get_scaling_mode(vc4_state->src_w[0],
   vc4_state->crtc_w);
vc4_state->y_scaling[0] = vc4_get_scaling_mode(vc4_state->src_h[0],
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106471] Radeon HD 3450 acceleration not working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106471

--- Comment #1 from Alex Deucher  ---
Does it work properly if you remove the nouveau card or switch the slots?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DPU PATCH v2 11/12] drm/msm/dpu: move dpu_power_handle to dpu folder

[Rajesh Yadav]

Now, since dpu_power_handle manages only bus scaling
and power enable/disable notifications which are restricted
to dpu driver, move dpu_power_handle to dpu folder.

Changes in v2:
- resolved conflict in dpu_unbind
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/Makefile |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c|   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  39 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 693 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 288 ++
 drivers/gpu/drm/msm/dpu_power_handle.c   | 693 ---
 drivers/gpu/drm/msm/dpu_power_handle.h   | 288 --
 drivers/gpu/drm/msm/msm_drv.c|   9 -
 drivers/gpu/drm/msm/msm_drv.h|   4 -
 14 files changed, 1013 insertions(+), 1020 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
 delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.c
 delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d9826c1..f578d5a 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -82,10 +82,10 @@ msm-y := \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
disp/dpu1/dpu_mdss.o \
+   disp/dpu1/dpu_power_handle.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
-   dpu_power_handle.o \
msm_prop.o \
msm_atomic.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 5c5cc56..33ab2ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -18,7 +18,6 @@
 #include 
 
 #include "dpu_core_irq.h"
-#include "dpu_power_handle.h"
 
 /**
  * dpu_core_irq_callback_handler - dispatch core interrupts
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 2cf3fca..d3a1ed9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -257,7 +257,6 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
= dpu_crtc_get_client_type(crtc);
struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
-   struct msm_drm_private *priv = kms->dev->dev_private;
 
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
@@ -287,7 +286,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 
switch (curr_client_type) {
case NRT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
@@ -295,7 +294,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
break;
 
case RT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e2d2e32..99c5e75 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -598,6 +598,7 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
_dpu_crtc_destroy_dest_scaler(dpu_crtc);
 
_dpu_crtc_deinit_events(dpu_crtc);
+   dpu_crtc->phandle = NULL;
 
drm_crtc_cleanup(crtc);
mutex_destroy(_crtc->crtc_lock);
@@ -2572,7 +2573,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
}
 
if (dpu_crtc->power_event)
-   dpu_power_handle_unregister_event(>phandle,
+   dpu_power_handle_unregister_event(dpu_crtc->phandle,
dpu_crtc->power_event);
 
 
@@ -2643,7 +2644,7 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,

[DPU PATCH v2 12/12] drm/msm/dpu: add error handling in dpu_core_perf_crtc_update

[Rajesh Yadav]

dpu_core_perf_crtc_update() is responsible for aggregating
the data bus bandwidth and dpu core clock rate requirements
and request the same for all active crtcs.
Currently, there is no error handling support in this function
so there is no way caller can know if the perf request fails.
This change adds error handling code in dpu_core_perf_crtc_update().
The caller side error handling is not added in this patch.

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  3 ++-
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index d3a1ed9..85c0229 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -248,7 +248,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
-static void _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
+static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
struct drm_crtc *crtc, u32 bus_id)
 {
u64 bw_sum_of_intfs = 0, bus_ab_quota, bus_ib_quota;
@@ -257,6 +257,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
= dpu_crtc_get_client_type(crtc);
struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
+   int ret = 0;
 
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
@@ -286,25 +287,28 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 
switch (curr_client_type) {
case NRT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   ret = dpu_power_data_bus_set_quota(
+   >phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
-   bus_id, bus_ab_quota, bus_ib_quota);
+ bus_id, bus_ab_quota, bus_ib_quota);
break;
 
case RT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   ret = dpu_power_data_bus_set_quota(
+   >phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
-   bus_id, bus_ab_quota, bus_ib_quota);
+ bus_id, bus_ab_quota, bus_ib_quota);
break;
 
default:
DPU_ERROR("invalid client type:%d\n", curr_client_type);
break;
}
+   return ret;
 }
 
 /**
@@ -399,7 +403,7 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
return clk_rate;
 }
 
-void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
+int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
int params_changed, bool stop_req)
 {
struct dpu_core_perf_params *new, *old;
@@ -410,16 +414,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
int i;
struct msm_drm_private *priv;
struct dpu_kms *kms;
+   int ret;
 
if (!crtc) {
DPU_ERROR("invalid crtc\n");
-   return;
+   return -EINVAL;
}
 
kms = _dpu_crtc_get_kms(crtc);
if (!kms || !kms->catalog) {
DPU_ERROR("invalid kms\n");
-   return;
+   return -EINVAL;
}
priv = kms->dev->dev_private;
 
@@ -482,8 +487,14 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
update_bus, update_clk);
 
for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
-   if (update_bus & BIT(i))
-   _dpu_core_perf_crtc_update_bus(kms, crtc, i);
+   if (update_bus & BIT(i)) {
+   ret = _dpu_core_perf_crtc_update_bus(kms, crtc, i);
+   if (ret) {
+   DPU_ERROR("crtc-%d: failed to update bw vote 
for bus-%d\n",
+ crtc->base.id, i);
+   return ret;
+   }
+   }
}
 
/*
@@ -495,15 +506,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
DPU_EVT32(kms->dev, stop_req, clk_rate);
 
-   if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
+   ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
+   if (ret) {
DPU_ERROR("failed to set %s 

[DPU PATCH v2 10/12] drm/msm/dpu: use runtime_pm calls in dpu_dbg

[Rajesh Yadav]

Currently, msm_drv was creating dpu_power_handle client
which was used by dpu_dbg module to enable power resources
before register debug dumping.

Now since, the mdss core power resource handling is
implemented via runtime_pm and same has been removed
from dpu_power_handle. Remove dpu_power_handle dependency
from msm_drv and use pm_runtime_get/put_sync calls from
dpu_dbg module on dpu_mdss top level device for core,
ahb clock and power resource management (for register access).

Changes in v2:
- resolved conflict in dpu_core_perf_init
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  7 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  4 
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  3 +--
 drivers/gpu/drm/msm/dpu_dbg.c | 18 +++---
 drivers/gpu/drm/msm/dpu_dbg.h | 13 ++---
 drivers/gpu/drm/msm/msm_drv.c | 27 +--
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 7 files changed, 11 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 5b79077..2cf3fca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -673,18 +673,11 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
-   struct dpu_power_client *pclient,
struct dss_clk *core_clk)
 {
-   if (!pclient) {
-   DPU_ERROR("invalid parameters\n");
-   return -EINVAL;
-   }
-
perf->dev = dev;
perf->catalog = catalog;
perf->phandle = phandle;
-   perf->pclient = pclient;
perf->core_clk = core_clk;
 
perf->max_core_clk_rate = core_clk->max_rate;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 9c1a719..cde48df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -53,7 +53,6 @@ struct dpu_core_perf_tune {
  * @debugfs_root: top level debug folder
  * @catalog: Pointer to catalog configuration
  * @phandle: Pointer to power handler
- * @pclient: Pointer to power client
  * @core_clk: Pointer to core clock structure
  * @core_clk_rate: current core clock rate
  * @max_core_clk_rate: maximum allowable core clock rate
@@ -68,7 +67,6 @@ struct dpu_core_perf {
struct dentry *debugfs_root;
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle *phandle;
-   struct dpu_power_client *pclient;
struct dss_clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -115,14 +113,12 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
  * @dev: Pointer to drm device
  * @catalog: Pointer to catalog
  * @phandle: Pointer to power handle
- * @pclient: Pointer to power client
  * @core_clk: pointer to core clock
  */
 int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
-   struct dpu_power_client *pclient,
struct dss_clk *core_clk);
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 349bda5..9c3b220 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1721,8 +1721,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
 #endif
 
rc = dpu_core_perf_init(_kms->perf, dev, dpu_kms->catalog,
-   >phandle, priv->pclient,
-   _dpu_kms_get_clk(dpu_kms, "core_clk"));
+   >phandle, _dpu_kms_get_clk(dpu_kms, "core_clk"));
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
goto perf_err;
diff --git a/drivers/gpu/drm/msm/dpu_dbg.c b/drivers/gpu/drm/msm/dpu_dbg.c
index 4a39b82..27538bc 100644
--- a/drivers/gpu/drm/msm/dpu_dbg.c
+++ b/drivers/gpu/drm/msm/dpu_dbg.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dpu_dbg.h"
 #include "disp/dpu1/dpu_hw_catalog.h"
@@ -167,7 +168,6 @@ struct dpu_dbg_vbif_debug_bus {
  * @evtlog: event log instance
  * @reg_base_list: list of register dumping regions
  * @dev: device pointer
- * @power_ctrl: callback structure for enabling power for reading hw registers
  * @req_dump_blks: list of blocks requested for dumping
  * @panic_on_err: whether to kernel panic after triggering dump via debugfs
  * @dump_work: work struct for deferring register dump work to separate thread
@@ -182,7 +182,6 @@ struct dpu_dbg_vbif_debug_bus {
struct dpu_dbg_evtlog *evtlog;
  

[Bug 106474] "CPU1 stuck for XXs: Xorg" since update to linux-4.16.x

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106474

--- Comment #2 from Alex Deucher  ---
Can you bisect?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DPU PATCH v2 09/12] drm/msm/dp: remove dpu_power_handle calls from dp driver

[Rajesh Yadav]

DP driver was dependent on dpu_power_handle for MDSS
common clocks and gdsc (main power supply).
The common clocks and power is managed by MDSS top
wrapper device now which is parent of all sub-devices
like DP device.
For same reason, clock and power management code is
removed from dpu_power_handle. Hence, remove the
dpu_power_handle calls from dp driver.

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/dp/dp_power.c | 32 +---
 drivers/gpu/drm/msm/dp/dp_power.h |  4 +---
 2 files changed, 2 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_power.c 
b/drivers/gpu/drm/msm/dp/dp_power.c
index f6e341b..2a85b38 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -26,8 +26,6 @@ struct dp_power_private {
struct clk *pixel_parent;
 
struct dp_power dp_power;
-   struct dpu_power_client *dp_core_client;
-   struct dpu_power_handle *phandle;
 
bool core_clks_on;
bool link_clks_on;
@@ -410,8 +408,7 @@ static int dp_power_config_gpios(struct dp_power_private 
*power, bool flip,
return 0;
 }
 
-static int dp_power_client_init(struct dp_power *dp_power,
-   struct dpu_power_handle *phandle)
+static int dp_power_client_init(struct dp_power *dp_power)
 {
int rc = 0;
struct dp_power_private *power;
@@ -436,19 +433,8 @@ static int dp_power_client_init(struct dp_power *dp_power,
goto error_clk;
}
 
-   power->phandle = phandle;
-   snprintf(dp_client_name, DP_CLIENT_NAME_SIZE, "dp_core_client");
-   power->dp_core_client = dpu_power_client_create(phandle,
-   dp_client_name);
-   if (IS_ERR_OR_NULL(power->dp_core_client)) {
-   pr_err("[%s] client creation failed for DP", dp_client_name);
-   rc = -EINVAL;
-   goto error_client;
-   }
return 0;
 
-error_client:
-   dp_power_clk_init(power, false);
 error_clk:
dp_power_regulator_deinit(power);
 error_power:
@@ -466,7 +452,6 @@ static void dp_power_client_deinit(struct dp_power 
*dp_power)
 
power = container_of(dp_power, struct dp_power_private, dp_power);
 
-   dpu_power_client_destroy(power->phandle, power->dp_core_client);
dp_power_clk_init(power, false);
dp_power_regulator_deinit(power);
 }
@@ -521,13 +506,6 @@ static int dp_power_init(struct dp_power *dp_power, bool 
flip)
goto err_gpio;
}
 
-   rc = dpu_power_resource_enable(power->phandle,
-   power->dp_core_client, true);
-   if (rc) {
-   pr_err("Power resource enable failed\n");
-   goto err_dpu_power;
-   }
-
rc = dp_power_clk_enable(dp_power, DP_CORE_PM, true);
if (rc) {
pr_err("failed to enable DP core clocks\n");
@@ -537,8 +515,6 @@ static int dp_power_init(struct dp_power *dp_power, bool 
flip)
return 0;
 
 err_clk:
-   dpu_power_resource_enable(power->phandle, power->dp_core_client, false);
-err_dpu_power:
dp_power_config_gpios(power, flip, false);
 err_gpio:
dp_power_pinctrl_set(power, false);
@@ -562,12 +538,6 @@ static int dp_power_deinit(struct dp_power *dp_power)
power = container_of(dp_power, struct dp_power_private, dp_power);
 
dp_power_clk_enable(dp_power, DP_CORE_PM, false);
-   rc = dpu_power_resource_enable(power->phandle,
-   power->dp_core_client, false);
-   if (rc) {
-   pr_err("Power resource enable failed, rc=%d\n", rc);
-   goto exit;
-   }
dp_power_config_gpios(power, false, false);
dp_power_pinctrl_set(power, false);
dp_power_regulator_ctrl(power, false);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.h 
b/drivers/gpu/drm/msm/dp/dp_power.h
index 84fe01d..d9dab72 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.h
+++ b/drivers/gpu/drm/msm/dp/dp_power.h
@@ -16,7 +16,6 @@
 #define _DP_POWER_H_
 
 #include "dp_parser.h"
-#include "dpu_power_handle.h"
 
 /**
  * sruct dp_power - DisplayPort's power related data
@@ -32,8 +31,7 @@ struct dp_power {
int (*clk_enable)(struct dp_power *power, enum dp_pm_type pm_type,
bool enable);
int (*set_pixel_clk_parent)(struct dp_power *power);
-   int (*power_client_init)(struct dp_power *power,
-   struct dpu_power_handle *phandle);
+   int (*power_client_init)(struct dp_power *power);
void (*power_client_deinit)(struct dp_power *power);
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DPU PATCH v2 07/12] drm/msm/dpu: remove clock management code from dpu_power_handle

[Rajesh Yadav]

MDSS and dpu drivers manage their respective clocks via
runtime_pm. Remove custom clock management code from
dpu_power_handle.

Also dpu core clock management code is restricted to
dpu_core_perf module.

Changes in v2:
- remove local variable to hold and return error code
  in _dpu_core_perf_set_core_clk_rate() instead return
  retcode directly from msm_dss_clk_set_rate() call (Sean Paul)
- dpu_core_perf_init() is called from dpu_kms_hw_init() and
  most of the params passed are already validated so remove
  redundant checks from dpu_core_perf_init() (Sean Paul)
- return >clk_config[i] directly to avoid local variable
  in _dpu_kms_get_clk() (Sean Paul)
- invert conditional check to eliminate local rate variable
  from dpu_kms_get_clk_rate() (Sean Paul)
- remove end label from dpu_power_resource_init() and return
  directly on dpu_power_parse_dt_supply() failure as no cleanup
  is needed (Sean Paul)
- remove checks for vtotal and vrefresh from
  dpu_encoder_phys_cmd_tearcheck_config() as they should be
  valid in mode_set call (Sean Paul)

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  41 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h  |   8 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  28 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   9 +
 drivers/gpu/drm/msm/dpu_power_handle.c | 196 +
 drivers/gpu/drm/msm/dpu_power_handle.h |  40 -
 7 files changed, 63 insertions(+), 268 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 981f77f..5b79077 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -365,6 +365,17 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
}
 }
 
+static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
+{
+   struct dss_clk *core_clk = kms->perf.core_clk;
+
+   if (core_clk->max_rate && (rate > core_clk->max_rate))
+   rate = core_clk->max_rate;
+
+   core_clk->rate = rate;
+   return msm_dss_clk_set_rate(core_clk, 1);
+}
+
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
 {
u64 clk_rate = kms->perf.perf_tune.min_core_clk;
@@ -376,7 +387,8 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
dpu_cstate = to_dpu_crtc_state(crtc->state);
clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
clk_rate);
-   clk_rate = clk_round_rate(kms->perf.core_clk, clk_rate);
+   clk_rate = clk_round_rate(kms->perf.core_clk->clk,
+   clk_rate);
}
}
 
@@ -484,15 +496,11 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
DPU_EVT32(kms->dev, stop_req, clk_rate);
 
-   /* Temp change to avoid crash in clk_set_rate API. */
-#ifdef QCOM_DPU_SET_CLK
-   if (dpu_power_clk_set_rate(>phandle,
-  kms->perf.clk_name, clk_rate)) {
+   if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
DPU_ERROR("failed to set %s clock rate %llu\n",
-   kms->perf.clk_name, clk_rate);
+   kms->perf.core_clk->clk_name, clk_rate);
return;
}
-#endif
 
kms->perf.core_clk_rate = clk_rate;
DPU_DEBUG("update clk rate = %lld HZ\n", clk_rate);
@@ -656,7 +664,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
dpu_core_perf_debugfs_destroy(perf);
perf->max_core_clk_rate = 0;
perf->core_clk = NULL;
-   perf->clk_name = NULL;
perf->phandle = NULL;
perf->catalog = NULL;
perf->dev = NULL;
@@ -667,9 +674,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
struct dpu_power_client *pclient,
-   char *clk_name)
+   struct dss_clk *core_clk)
 {
-   if (!perf || !dev || !catalog || !phandle || !pclient || !clk_name) {
+   if (!pclient) {
DPU_ERROR("invalid parameters\n");
return -EINVAL;
}
@@ -678,23 +685,13 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
perf->catalog = catalog;
perf->phandle = phandle;
perf->pclient = pclient;
-   perf->clk_name = clk_name;
-
-   perf->core_clk = dpu_power_clk_get_clk(phandle, clk_name);
-   if 

[DPU PATCH v2 08/12] drm/msm/dpu: remove power management code from dpu_power_handle

[Rajesh Yadav]

Mdss main power supply (mdss_gdsc) is implemented as a
generic power domain and mdss top level wrapper device
manage it via runtime_pm. Remove custom power management
code from dpu_power_handle.

Changes in v2:
- resolved merge conflict in dpu_power_resource_init
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/dpu_power_handle.c | 194 +
 drivers/gpu/drm/msm/dpu_power_handle.h |   2 -
 2 files changed, 3 insertions(+), 193 deletions(-)

diff --git a/drivers/gpu/drm/msm/dpu_power_handle.c 
b/drivers/gpu/drm/msm/dpu_power_handle.c
index 12602ae..77be106 100644
--- a/drivers/gpu/drm/msm/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/dpu_power_handle.c
@@ -101,150 +101,6 @@ void dpu_power_client_destroy(struct dpu_power_handle 
*phandle,
}
 }
 
-static int dpu_power_parse_dt_supply(struct platform_device *pdev,
-   struct dss_module_power *mp)
-{
-   int i = 0, rc = 0;
-   u32 tmp = 0;
-   struct device_node *of_node = NULL, *supply_root_node = NULL;
-   struct device_node *supply_node = NULL;
-
-   if (!pdev || !mp) {
-   pr_err("invalid input param pdev:%pK mp:%pK\n", pdev, mp);
-   return -EINVAL;
-   }
-
-   of_node = pdev->dev.of_node;
-
-   mp->num_vreg = 0;
-   supply_root_node = of_get_child_by_name(of_node,
-   "qcom,platform-supply-entries");
-   if (!supply_root_node) {
-   pr_debug("no supply entry present\n");
-   return rc;
-   }
-
-   for_each_child_of_node(supply_root_node, supply_node)
-   mp->num_vreg++;
-
-   if (mp->num_vreg == 0) {
-   pr_debug("no vreg\n");
-   return rc;
-   }
-
-   pr_debug("vreg found. count=%d\n", mp->num_vreg);
-   mp->vreg_config = devm_kzalloc(>dev, sizeof(struct dss_vreg) *
-   mp->num_vreg, GFP_KERNEL);
-   if (!mp->vreg_config) {
-   rc = -ENOMEM;
-   return rc;
-   }
-
-   for_each_child_of_node(supply_root_node, supply_node) {
-
-   const char *st = NULL;
-
-   rc = of_property_read_string(supply_node,
-   "qcom,supply-name", );
-   if (rc) {
-   pr_err("error reading name. rc=%d\n", rc);
-   goto error;
-   }
-
-   strlcpy(mp->vreg_config[i].vreg_name, st,
-   sizeof(mp->vreg_config[i].vreg_name));
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-min-voltage", );
-   if (rc) {
-   pr_err("error reading min volt. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].min_voltage = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-max-voltage", );
-   if (rc) {
-   pr_err("error reading max volt. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].max_voltage = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-enable-load", );
-   if (rc) {
-   pr_err("error reading enable load. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].enable_load = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-disable-load", );
-   if (rc) {
-   pr_err("error reading disable load. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].disable_load = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-pre-on-sleep", );
-   if (rc)
-   pr_debug("error reading supply pre sleep value. 
rc=%d\n",
-   rc);
-
-   mp->vreg_config[i].pre_on_sleep = (!rc ? tmp : 0);
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-pre-off-sleep", );
-   if (rc)
-   pr_debug("error reading supply pre sleep value. 
rc=%d\n",
-   rc);
-
-   mp->vreg_config[i].pre_off_sleep = (!rc ? tmp : 0);
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-post-on-sleep", );
-   if (rc)
-   pr_debug("error reading supply post sleep value. 

[DPU PATCH v2 06/12] drm/msm/dpu: use runtime_pm calls on dpu device

[Rajesh Yadav]

The dpu driver implements runtime_pm support for managing
dpu specific resources like - clocks, bus bandwidth etc.

Use pm_runtime_get/put_sync calls on dpu device.

The common clocks and power management for all child nodes
(mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver
via runtime_pm due to parent child relationship.

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c |  8 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 16 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 45 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c|  6 ++--
 5 files changed, 31 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 977adc4..5c5cc56 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -452,10 +452,10 @@ void dpu_core_irq_preinstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
 
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, true);
+   pm_runtime_get_sync(_kms->pdev->dev);
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, false);
+   pm_runtime_put_sync(_kms->pdev->dev);
 
spin_lock_init(_kms->irq_obj.cb_lock);
 
@@ -496,7 +496,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
 
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, true);
+   pm_runtime_get_sync(_kms->pdev->dev);
for (i = 0; i < dpu_kms->irq_obj.total_irqs; i++)
if (atomic_read(_kms->irq_obj.enable_counts[i]) ||
!list_empty(_kms->irq_obj.irq_cb_tbl[i]))
@@ -504,7 +504,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
 
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, false);
+   pm_runtime_put_sync(_kms->pdev->dev);
 
kfree(dpu_kms->irq_obj.irq_cb_tbl);
kfree(dpu_kms->irq_obj.enable_counts);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 48920b05..e2d2e32 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -86,8 +86,12 @@ static inline int _dpu_crtc_power_enable(struct dpu_crtc 
*dpu_crtc, bool enable)
 
dpu_kms = to_dpu_kms(priv->kms);
 
-   return dpu_power_resource_enable(>phandle, dpu_kms->core_client,
-   enable);
+   if (enable)
+   pm_runtime_get_sync(_kms->pdev->dev);
+   else
+   pm_runtime_put_sync(_kms->pdev->dev);
+
+   return 0;
 }
 
 /**
@@ -2250,7 +2254,6 @@ static int _dpu_crtc_vblank_enable_no_lock(
 
/* drop lock since power crtc cb may try to re-acquire lock */
mutex_unlock(_crtc->crtc_lock);
-   pm_runtime_get_sync(dev->dev);
ret = _dpu_crtc_power_enable(dpu_crtc, true);
mutex_lock(_crtc->crtc_lock);
if (ret)
@@ -2580,7 +2583,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
-   pm_runtime_put_sync(crtc->dev->dev);
 
mutex_unlock(_crtc->crtc_lock);
 }
@@ -2611,8 +2613,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
return;
}
 
-   pm_runtime_get_sync(crtc->dev->dev);
-
drm_for_each_encoder(encoder, crtc->dev) {
if (encoder->crtc != crtc)
continue;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4386360..298a6ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -268,8 +268,12 @@ static inline int _dpu_encoder_power_enable(struct 
dpu_encoder_virt *dpu_enc,
 
dpu_kms = to_dpu_kms(priv->kms);
 
-   return dpu_power_resource_enable(>phandle, dpu_kms->core_client,
-   enable);
+   if (enable)
+   pm_runtime_get_sync(_kms->pdev->dev);
+   else
+   pm_runtime_put_sync(_kms->pdev->dev);
+
+   return 0;
 }
 
 void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys *phys_enc,
@@ -796,10 +800,8 @@ static void _dpu_encoder_resource_control_helper(struct 
drm_encoder *drm_enc,
}
 
if (enable) {
-   

[DPU PATCH v2 05/12] drm/msm/dpu: update dpu sub-block offsets wrt dpu base address

[Rajesh Yadav]

The dpu sub-block offsets were defined wrt mdss base address
instead of dpu base address.
Since, dpu is now defined as a separate device, update hw catalog
offsets for all dpu sub blocks wrt dpu base address.

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 68 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 +++---
 2 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c5b370f..2fd3254 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -80,7 +80,7 @@
 static struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
-   .base = 0x1000, .len = 0x45C,
+   .base = 0x0, .len = 0x45C,
.features = 0,
.highest_bank_bit = 0x2,
.has_dest_scaler = true,
@@ -111,27 +111,27 @@
 static struct dpu_ctl_cfg sdm845_ctl[] = {
{
.name = "ctl_0", .id = CTL_0,
-   .base = 0x2000, .len = 0xE4,
+   .base = 0x1000, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_1", .id = CTL_1,
-   .base = 0x2200, .len = 0xE4,
+   .base = 0x1200, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_2", .id = CTL_2,
-   .base = 0x2400, .len = 0xE4,
+   .base = 0x1400, .len = 0xE4,
.features = 0
},
{
.name = "ctl_3", .id = CTL_3,
-   .base = 0x2600, .len = 0xE4,
+   .base = 0x1600, .len = 0xE4,
.features = 0
},
{
.name = "ctl_4", .id = CTL_4,
-   .base = 0x2800, .len = 0xE4,
+   .base = 0x1800, .len = 0xE4,
.features = 0
},
 };
@@ -211,21 +211,21 @@
}
 
 static struct dpu_sspp_cfg sdm845_sspp[] = {
-   SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x5000,
+   SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
-   SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x7000,
+   SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
-   SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x9000,
+   SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
-   SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xb000,
+   SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
-   SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x25000,
+   SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
-   SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x27000,
+   SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
-   SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x29000,
+   SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
-   SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2b000,
+   SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
 };
 
@@ -252,17 +252,17 @@
.lm_pair_mask = (1 << _lmpair) \
}
 static struct dpu_lm_cfg sdm845_lm[] = {
-   LM_BLK("lm_0", LM_0, 0x45000, DSPP_0,
+   LM_BLK("lm_0", LM_0, 0x44000, DSPP_0,
DS_0, PINGPONG_0, LM_1),
-   LM_BLK("lm_1", LM_1, 0x46000, DSPP_1,
+   LM_BLK("lm_1", LM_1, 0x45000, DSPP_1,
DS_1, PINGPONG_1, LM_0),
-   LM_BLK("lm_2", LM_2, 0x47000, DSPP_2,
+   LM_BLK("lm_2", LM_2, 0x46000, DSPP_2,
DS_MAX, PINGPONG_2, LM_5),
LM_BLK("lm_3", LM_3, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
LM_BLK("lm_4", LM_4, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
-   LM_BLK("lm_5", LM_5, 0x4a000, DSPP_3,
+   LM_BLK("lm_5", LM_5, 0x49000, DSPP_3,
DS_MAX, PINGPONG_3, LM_2),
 };
 
@@ -270,7 +270,7 @@
  * DSPP sub blocks config
  */
 static struct dpu_dspp_top_cfg sdm845_dspp_top = {
-   .name = "dspp_top", .base = 0x1300, .len = 0xc
+   .name = "dspp_top", .base = 0x300, .len = 0xc
 };
 
 static const struct dpu_dspp_sub_blks sdm845_dspp_sblk = {
@@ -304,10 +304,10 @@
}
 
 static struct dpu_dspp_cfg sdm845_dspp[] = {
-   DSPP_BLK("dspp_0", DSPP_0, 0x55000),
-   DSPP_BLK("dspp_1", DSPP_1, 0x57000),
-   DSPP_BLK("dspp_2", DSPP_2, 0x59000),
-   DSPP_BLK("dspp_3", DSPP_3, 0x5b000),
+   DSPP_BLK("dspp_0", DSPP_0, 0x54000),
+   DSPP_BLK("dspp_1", DSPP_1, 0x56000),
+   DSPP_BLK("dspp_2", DSPP_2, 0x58000),
+   DSPP_BLK("dspp_3", DSPP_3, 0x5a000),
 };
 
 

[DPU PATCH v2 04/12] drm/msm/dpu: create new platform driver for dpu device

[Rajesh Yadav]

Current MSM display controller HW matches a tree like
hierarchy where MDSS top level wrapper is parent device
and mdp5/dpu, dsi, dp are child devices.

Each child device like mdp5, dsi etc. have a separate driver,
but currently dpu handling is tied to a single driver which
was managing both mdss and dpu resources.

Inorder to have the cleaner one to one device and driver
association, this change adds a new platform_driver for dpu
child device node which implements the kms functionality.

The dpu driver implements runtime_pm support for managing clocks
and bus bandwidth etc.

Changes in v2:
- remove redundant param check from _dpu_kms_hw_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul)
- merge dpu_init into dpu_bind (Sean Paul)
- merge dpu_destroy into dpu_unbind (Sean Paul)
- use %pK for kernel pointer printing (Jordan Crouse)
- remove explicit devm allocation failure message (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 238 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   4 +
 drivers/gpu/drm/msm/msm_drv.c   |   2 +
 drivers/gpu/drm/msm/msm_drv.h   |   3 +
 4 files changed, 196 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e4ab753..85f3dbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1030,16 +1030,12 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms, 
unsigned long rate,
return rate;
 }
 
-static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
-   struct platform_device *pdev)
+static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
 {
struct drm_device *dev;
struct msm_drm_private *priv;
int i;
 
-   if (!dpu_kms || !pdev)
-   return;
-
dev = dpu_kms->dev;
if (!dev)
return;
@@ -1091,15 +1087,15 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
dpu_kms->core_client = NULL;
 
if (dpu_kms->vbif[VBIF_NRT])
-   msm_iounmap(pdev, dpu_kms->vbif[VBIF_NRT]);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_NRT]);
dpu_kms->vbif[VBIF_NRT] = NULL;
 
if (dpu_kms->vbif[VBIF_RT])
-   msm_iounmap(pdev, dpu_kms->vbif[VBIF_RT]);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_RT]);
dpu_kms->vbif[VBIF_RT] = NULL;
 
if (dpu_kms->mmio)
-   msm_iounmap(pdev, dpu_kms->mmio);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->mmio);
dpu_kms->mmio = NULL;
 
dpu_reg_dma_deinit();
@@ -1172,8 +1168,6 @@ int dpu_kms_mmu_attach(struct dpu_kms *dpu_kms, bool 
secure_only)
 static void dpu_kms_destroy(struct msm_kms *kms)
 {
struct dpu_kms *dpu_kms;
-   struct drm_device *dev;
-   struct platform_device *platformdev;
 
if (!kms) {
DPU_ERROR("invalid kms\n");
@@ -1181,20 +1175,7 @@ static void dpu_kms_destroy(struct msm_kms *kms)
}
 
dpu_kms = to_dpu_kms(kms);
-   dev = dpu_kms->dev;
-   if (!dev) {
-   DPU_ERROR("invalid device\n");
-   return;
-   }
-
-   platformdev = to_platform_device(dev->dev);
-   if (!platformdev) {
-   DPU_ERROR("invalid platform device\n");
-   return;
-   }
-
-   _dpu_kms_hw_destroy(dpu_kms, platformdev);
-   kfree(dpu_kms);
+   _dpu_kms_hw_destroy(dpu_kms);
 }
 
 static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
@@ -1550,7 +1531,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
struct dpu_kms *dpu_kms;
struct drm_device *dev;
struct msm_drm_private *priv;
-   struct platform_device *platformdev;
int i, rc = -EINVAL;
 
if (!kms) {
@@ -1565,34 +1545,28 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
goto end;
}
 
-   platformdev = to_platform_device(dev->dev);
-   if (!platformdev) {
-   DPU_ERROR("invalid platform device\n");
-   goto end;
-   }
-
priv = dev->dev_private;
if (!priv) {
DPU_ERROR("invalid private data\n");
goto end;
}
 
-   dpu_kms->mmio = msm_ioremap(platformdev, "mdp_phys", "mdp_phys");
+   dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp_phys", "mdp_phys");
if (IS_ERR(dpu_kms->mmio)) {
rc = PTR_ERR(dpu_kms->mmio);
DPU_ERROR("mdp register memory map failed: %d\n", rc);
dpu_kms->mmio = NULL;
goto error;
}
-   DRM_INFO("mapped mdp address space @%p\n", dpu_kms->mmio);
-   dpu_kms->mmio_len = msm_iomap_size(platformdev, "mdp_phys");
+   DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio);
+   

[DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[Rajesh Yadav]

SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.

Currently, in dpu driver, all the power resource
management is part of power_handle which manages
these resources via a custom implementation. And
the resource relationships are not modelled properly
in dt.  Moreover the irq domain handling code is part
of dpu device (which is a child device) due to lack
of a dedicated driver for MDSS top level wrapper
device.

This change adds dpu_mdss top level driver to handle
common clock like - core clock, ahb clock
(for register access), main power supply (i.e. gdsc)
and irq management.
The top level mdss device/driver acts as an interrupt
controller and manage hwirq mapping for its child
devices.

It implements runtime_pm support for resource management.
Child nodes can control these resources via runtime_pm
get/put calls on their corresponding devices due to parent
child relationship defined in dt.

Changes in v2:
- merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
- merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
- fix indentation for irq_find_mapping call (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant param checks from
  dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
- remove redundant param checks from
  dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)
- remove redundant param check from dpu_mdss_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove extra line before dpu_mdss_init (Sean Paul)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- remove redundant param check from dpu_mdss_irq (Jordan Crouse)
- change mdss address space log message to debug and use %pK for
  kernel pointers (Jordan Crouse)
- remove unnecessary log message from msm_dss_parse_clock (Jordan 
Crouse)
- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 254 ++
 drivers/gpu/drm/msm/dpu_io_util.c |  57 +
 drivers/gpu/drm/msm/msm_drv.c |  26 ++-
 drivers/gpu/drm/msm/msm_drv.h |   2 +-
 drivers/gpu/drm/msm/msm_kms.h |   1 +
 include/linux/dpu_io_util.h   |   2 +
 16 files changed, 339 insertions(+), 226 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d7558ed..d9826c1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -81,6 +81,7 @@ msm-y := \
disp/dpu1/dpu_reg_dma.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+   disp/dpu1/dpu_mdss.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index fe33013..977adc4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -515,103 +515,6 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
dpu_kms->irq_obj.total_irqs = 0;
 }
 
-static void dpu_core_irq_mask(struct irq_data *irqd)
-{
-   struct dpu_kms *dpu_kms;
-
-   if (!irqd || !irq_data_get_irq_chip_data(irqd)) {
-   DPU_ERROR("invalid parameters irqd %d\n", irqd != NULL);
-   return;
-   }
-   dpu_kms = irq_data_get_irq_chip_data(irqd);
-
-   /* memory barrier */
-   smp_mb__before_atomic();
-   

[DPU PATCH v2 01/12] drm/msm: remove redundant pm_runtime_enable call from msm_drv

[Rajesh Yadav]

MDSS top level device includes the common power resources
and it's corresponding driver (i.e. mdp5_mdss) handles call
to enable/disable runtime_pm for enabling these resources.
Remove redundant pm_runtime_enable call from msm_drv.

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index ebc40a9..9bb436f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -581,7 +581,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
goto fail;
}
priv->kms = kms;
-   pm_runtime_enable(dev);
 
/**
 * Since kms->funcs->hw_init(kms) might call
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[DPU PATCH v2 02/12] drm/msm/mdp5: subclass msm_mdss for mdp5

[Rajesh Yadav]

SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.

Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.

Add mdss helper interface (msm_mdss_funcs) to msm_mdss
base for mdp5/dpu mdss specific implementation calls.

This change subclasses msm_mdss for mdp5, dpu specific
changes will be done separately.

Changes in v2:
- fixed indentation for irq_domain_add_linear call (Sean Paul)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154 --
 drivers/gpu/drm/msm/msm_drv.c |  23 +++--
 drivers/gpu/drm/msm/msm_kms.h |  20 ++--
 3 files changed, 110 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
index f2a0db7..1cc4e57 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
@@ -20,12 +20,10 @@
 #include "msm_drv.h"
 #include "mdp5_kms.h"
 
-/*
- * If needed, this can become more specific: something like struct mdp5_mdss,
- * which contains a 'struct msm_mdss base' member.
- */
-struct msm_mdss {
-   struct drm_device *dev;
+#define to_mdp5_mdss(x) container_of(x, struct mdp5_mdss, base)
+
+struct mdp5_mdss {
+   struct msm_mdss base;
 
void __iomem *mmio, *vbif;
 
@@ -41,22 +39,22 @@ struct msm_mdss {
} irqcontroller;
 };
 
-static inline void mdss_write(struct msm_mdss *mdss, u32 reg, u32 data)
+static inline void mdss_write(struct mdp5_mdss *mdp5_mdss, u32 reg, u32 data)
 {
-   msm_writel(data, mdss->mmio + reg);
+   msm_writel(data, mdp5_mdss->mmio + reg);
 }
 
-static inline u32 mdss_read(struct msm_mdss *mdss, u32 reg)
+static inline u32 mdss_read(struct mdp5_mdss *mdp5_mdss, u32 reg)
 {
-   return msm_readl(mdss->mmio + reg);
+   return msm_readl(mdp5_mdss->mmio + reg);
 }
 
 static irqreturn_t mdss_irq(int irq, void *arg)
 {
-   struct msm_mdss *mdss = arg;
+   struct mdp5_mdss *mdp5_mdss = arg;
u32 intr;
 
-   intr = mdss_read(mdss, REG_MDSS_HW_INTR_STATUS);
+   intr = mdss_read(mdp5_mdss, REG_MDSS_HW_INTR_STATUS);
 
VERB("intr=%08x", intr);
 
@@ -64,7 +62,7 @@ static irqreturn_t mdss_irq(int irq, void *arg)
irq_hw_number_t hwirq = fls(intr) - 1;
 
generic_handle_irq(irq_find_mapping(
-   mdss->irqcontroller.domain, hwirq));
+   mdp5_mdss->irqcontroller.domain, hwirq));
intr &= ~(1 << hwirq);
}
 
@@ -84,19 +82,19 @@ static irqreturn_t mdss_irq(int irq, void *arg)
 
 static void mdss_hw_mask_irq(struct irq_data *irqd)
 {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
 
smp_mb__before_atomic();
-   clear_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   clear_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
 }
 
 static void mdss_hw_unmask_irq(struct irq_data *irqd)
 {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
 
smp_mb__before_atomic();
-   set_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   set_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
 }
 
@@ -109,13 +107,13 @@ static void mdss_hw_unmask_irq(struct irq_data *irqd)
 static int mdss_hw_irqdomain_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hwirq)
 {
-   struct msm_mdss *mdss = d->host_data;
+   struct mdp5_mdss *mdp5_mdss = d->host_data;
 
if (!(VALID_IRQS & (1 << hwirq)))
return -EPERM;
 
irq_set_chip_and_handler(irq, _hw_irq_chip, handle_level_irq);
-   irq_set_chip_data(irq, mdss);
+   irq_set_chip_data(irq, mdp5_mdss);
 
return 0;
 }
@@ -126,90 +124,99 @@ static int mdss_hw_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
 };
 
 
-static int mdss_irq_domain_init(struct msm_mdss *mdss)
+static int mdss_irq_domain_init(struct mdp5_mdss *mdp5_mdss)
 {
-   struct device *dev = mdss->dev->dev;
+   struct device *dev = mdp5_mdss->base.dev->dev;
struct irq_domain *d;
 
d = irq_domain_add_linear(dev->of_node, 32, _hw_irqdomain_ops,
- mdss);
+ mdp5_mdss);
if (!d) {
dev_err(dev, "mdss irq domain add failed\n");
return -ENXIO;
}
 
-   mdss->irqcontroller.enabled_mask = 0;
-   mdss->irqcontroller.domain = d;
+   mdp5_mdss->irqcontroller.enabled_mask = 0;
+   mdp5_mdss->irqcontroller.domain 

[DPU PATCH v2 00/12] Refactor DPU device/driver hierarchy and add runtime_pm support

[Rajesh Yadav]

SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes
sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper
manages common resources like common clocks, main power supply and
interrupts for its sub-blocks.

But current dpu driver implementation is based on a flat device hierarchy
where MDSS/DPU HW blocks were represented by single device and DSI/DP etc.
are represented as independent devices w/o any relationships b/t these
nodes which doesn't model the HW associations precisely.

A minimal MDSS and DPU controller device separation is done in following
patch series [1] but currently both these devices match to a single driver
which is getting probed two times and all the resources are still tied to
DPU device.

Moreover, all the power resource management in DPU driver is part of
power_handle module which manages these resources via a custom
implementation.

Irq domain handling is part of DPU device, due to lack of a dedicated
driver for MDSS top level wrapper device.

This patch series aims at adding separate drivers for MDSS top level
wrapper device and DPU child device. MDP5 device/driver is used as a
reference for this refactoring effort. Both the drivers implement
runtime_pm support for their power resource management. Child nodes can
control common resources managed by parent device due to parent child
relationship defined in dt. The top level MDSS device acts as an
interrupt controller and manages hwirq mappings for its child devices. 

Inorder to add MDP5 and DPU specific MDSS driver implementation, this patch
series also subclasses existing msm_mdss define. A helper interface
(msm_mdss_funcs) is added to invoke the platform specific implementations.

This change also corrects hw catalog offsets for all sub blocks present
within DPU device. The offset are now defined wrt DPU base address
(instead of using MDSS base address).

Clock and Power handling code have been removed from dpu_power_handle since
each device manages it's resources via runtime_pm. Now, since
dpu_power_handle manages only bus scaling and power enable/disable
notifications and it's usage is restricted to DPU driver only, moved
dpu_power_handle code to DPU folder.

The dt bindings update patch will be sent subsequently.

This patch series depends on [1].

1 - https://lists.freedesktop.org/archives/freedreno/2018-April/002354.html

Changes in v2:
- fix indentation issues in dpu_mdss (Sean Paul)
- merge tiny static functions (like _dpu_mdss_hw_rev_init()
  and _dpu_mdss_get_intr_sources()) in caller functions (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant input param checks from dpu_mdss
  and dpu_kms (Sean Paul/Jordan Crouse)
- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- use %pK for kernel pointers (Jordan Crouse)
- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)
- merge dpu_init into dpu_bind and dpu_destroy into dpu_unbind (Sean 
Paul)
- remove explicit devm allocation failure message (Jordan Crouse)
- remove local variable to hold and return error code
  in _dpu_core_perf_set_core_clk_rate() instead return
  retcode directly from msm_dss_clk_set_rate() call (Sean Paul)
- return >clk_config[i] directly to avoid local variable
  in _dpu_kms_get_clk() (Sean Paul)
- invert conditional check to eliminate local rate variable
  from dpu_kms_get_clk_rate() (Sean Paul)
- remove end label from dpu_power_resource_init() and return
  directly on dpu_power_parse_dt_supply() failure as no cleanup
  is needed (Sean Paul)
- remove checks for vtotal and vrefresh from
  dpu_encoder_phys_cmd_tearcheck_config() as they should be
  valid in mode_set() call (Sean Paul)
- add error handling in dpu_core_perf_crtc_update() (Sean Paul)

Rajesh Yadav (12):
  drm/msm: remove pm_runtime_enable call from msm_drv
  drm/msm/mdp5: subclass msm_mdss for mdp5
  drm/msm/dpu: add MDSS top level driver for dpu
  drm/msm/dpu: create new platform driver for dpu device
  drm/msm/dpu: update dpu sub-block offsets wrt dpu base address
  drm/msm/dpu: use runtime_pm calls on dpu device
  drm/msm/dpu: remove clock management code from dpu_power_handle
  drm/msm/dpu: remove power 

Re: [PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY

[Sean Paul]

On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote:
> If want to do training outside DP Firmware, need phy voltage swing
> and pre_emphasis value.
> 
> Signed-off-by: Lin Huang 

Adding Rob Herring so he has a hope of seeing this.

> ---
> Changes in v2:
> - rebase
> 
>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt 
> b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> index 960da7f..eda26dd 100644
> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
> @@ -17,7 +17,9 @@ Required properties:
>  
>  Optional properties:
>   - extcon : extcon specifier for the Power Delivery
> -
> + - rockchip,phy_config : That's phy voltage swing and pre_emphasis
> +  setting, if want to do dp training outside
> +  dp firmware, need to add these value.

What are the units?

Sean

>  Required nodes : a sub-node is required for each port the phy provides.
>The sub-node name is used to identify dp or usb3 port,
>and shall be the following entries:
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] phy: rockchip-typec: support variable phy config value

[Sean Paul]

On Wed, May 09, 2018 at 06:22:42PM +0800, Lin Huang wrote:
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
> 
FTR, I've previously reviewed this at
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/985573

This patch should come _after_ the dt binding addition.

> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> 
>  drivers/phy/rockchip/phy-rockchip-typec.c | 284 
> +++---
>  include/soc/rockchip/rockchip_phy_typec.h |  64 +++
>  2 files changed, 250 insertions(+), 98 deletions(-)
>  create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
> 

/snip

> diff --git a/include/soc/rockchip/rockchip_phy_typec.h 
> b/include/soc/rockchip/rockchip_phy_typec.h
> new file mode 100644
> index 000..4a328221
> --- /dev/null
> +++ b/include/soc/rockchip/rockchip_phy_typec.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Lin Huang 
> + */
> +
> +#ifndef __SOC_ROCKCHIP_PHY_TYPEC_H
> +#define __SOC_ROCKCHIP_PHY_TYPEC_H
> +
> +struct usb3phy_reg {
> + u32 offset;
> + u32 enable_bit;
> + u32 write_enable;
> +};
> +
> +/**
> + * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> + * @reg: the base address for usb3-phy config.
> + * @typec_conn_dir: the register of type-c connector direction.
> + * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> + * @external_psm: the register of type-c phy external psm clock.
> + * @pipe_status: the register of type-c phy pipe status.
> + * @usb3_host_disable: the register of type-c usb3 host disable.
> + * @usb3_host_port: the register of type-c usb3 host port.
> + * @uphy_dp_sel: the register of type-c phy DP select control.
> + */
> +struct rockchip_usb3phy_port_cfg {
> + unsigned int reg;
> + struct usb3phy_reg typec_conn_dir;
> + struct usb3phy_reg usb3tousb2_en;
> + struct usb3phy_reg external_psm;
> + struct usb3phy_reg pipe_status;
> + struct usb3phy_reg usb3_host_disable;
> + struct usb3phy_reg usb3_host_port;
> + struct usb3phy_reg uphy_dp_sel;
> +};
> +
> +struct phy_config {
> + int swing;
> + int pe;
> +};
> +
> +struct rockchip_typec_phy {
> + struct device *dev;
> + void __iomem *base;
> + struct extcon_dev *extcon;
> + struct regmap *grf_regs;
> + struct clk *clk_core;
> + struct clk *clk_ref;
> + struct reset_control *uphy_rst;
> + struct reset_control *pipe_rst;
> + struct reset_control *tcphy_rst;
> + const struct rockchip_usb3phy_port_cfg *port_cfgs;
> + /* mutex to protect access to individual PHYs */
> + struct mutex lock;
> + struct phy_config config[3][4];
> + u8 need_software_training;

I thought we decided to always do sw training and then fallback to fw training.
If so, we don't need this.

Sean

> + bool flip;
> + u8 mode;
> + int (*typec_phy_config)(struct phy *phy, int link_rate,
> + int lanes, u8 swing, u8 pre_emp);
> +};
> +
> +#endif
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

[Maxime Ripard]

On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> @@ -0,0 +1,297 @@
> +/*
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)

This really should be the first line, and with a C++ style comment, as
in:

// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
 * Copyright (C) ...

See Documentation/process/license-rules.rst

> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <  0   1   1   1   1   2   2   2
> +2   3   3   3   3   4   4   4
> +5   5   5   6   6   6   7   7
> +8   8   8   9   9   9  10  10
> +   10  11  11  12  12  12  13  13
> +   14  14  14  15  15  16  16  17
> +   17  17  18  18  19  19  20  20
> +   21  21  21  22  22  23  23  24
> +   24  25  25  26  26  27  27  28
> +   28  29  30  30  31  31  32  32
> +   33  33  34  35  35  36  36  37
> +   38  38  39  39  40  41  41  42
> +   43  43  44  44  45  46  47  47
> +   48  49  49  50  51  51  52  53
> +   54  54  55  56  57  57  58  59
> +   60  61  61  62  63  64  65  65
> +   66  67  68  69  70  71  71  72
> +   73  74  75  76  77  78  79  80
> +   81  82  83  84  85  86  87  88
> +   89  90  91  92  93  94  95  96
> +   97  98  99 101 102 103 104 105
> +  106 108 109 110 111 112 114 115
> +  116 117 119 120 121 123 124 125
> +  127 128 129 131 132 133 135 136
> +  138 139 141 142 144 145 147 148
> +  150 151 153 154 156 157 159 161
> +  162 164 166 167 169 171 173 174
> +  176 178 180 181 183 185 187 189
> +  191 192 194 196 198 200 202 204
> +  206 208 210 212 214 216 219 221
> +  223 225 227 229 232 234 236 238
> +  241 242 244 246 248 250 253 255>;

You kind of overdid it here :)

What I meant to say before was that if you have 10 elements (and you
really should have something in that magnitude) each step should
increase the perceived brightness by 10%.

In this particular case, I really think having something close to <0 4
8 16 32 64 128 255> would be enough.

And in general, that kind of odd looking table without any more
context is just screaming for a comment :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp

[Sean Paul]

On Wed, May 09, 2018 at 06:22:41PM +0800, Lin Huang wrote:
> From: Chris Zhong 
> 
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 

FTR, I've already done one pass at [1]. All of those nits look fixed, so 

Reviewed-by: Sean Paul 

[1]- 
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/985572

> ---
> 
> Changes in v2: 
> - update patch following Enric suggest
> 
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 
>  drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 67 
> ++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++-
>  4 files changed, 120 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device 
> *dp, u8 *sink_count)
>   u8 value;
>  
>   *sink_count = 0;
> - ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
> - if (ret)
> + ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
> + if (ret < 0)
>   return ret;
>  
>   *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct 
> cdn_dp_device *dp)
>   if (!cdn_dp_check_sink_connection(dp))
>   return -ENODEV;
>  
> - ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> -DP_RECEIVER_CAP_SIZE);
> - if (ret) {
> + ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
> +sizeof(dp->dpcd));
> + if (ret < 0) {
>   DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
>   return ret;
>   }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
> *dp)
>   if (!port || !dp->link.rate || !dp->link.num_lanes)
>   return false;
>  
> - if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> -  DP_LINK_STATUS_SIZE)) {
> + if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
>   DRM_ERROR("Failed to get link status\n");
>   return false;
>   }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
>   return NOTIFY_DONE;
>  }
>  
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> +struct drm_dp_aux_msg *msg)
> +{
> + struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
> + int ret;
> + u8 status;
> +
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> + ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> + msg->size);
> + break;
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> +msg->size);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + status = cdn_dp_get_aux_status(dp);
> + if (status == AUX_STATUS_ACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> + else if (status == AUX_STATUS_NACK)
> + msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> + else if (status == AUX_STATUS_DEFER)
> + msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> + return ret;
> +}
> +
>  static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>  {
>   struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct 
> device *master, void *data)
>   dp->active = false;
>   dp->active_port = -1;
>   dp->fw_loaded = false;
> + dp->aux.name = "DP-AUX";
> + dp->aux.transfer = cdn_dp_aux_transfer;
> + dp->aux.dev = dev;
> +
> + ret = drm_dp_aux_register(>aux);
> + if (ret)
> + return ret;
>  
>   INIT_WORK(>event_work, cdn_dp_pd_event_work);
>  
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
>   struct platform_device *audio_pdev;
>   struct work_struct event_work;
>   struct edid *edid;
> + struct drm_dp_aux aux;
>  
>   struct mutex lock;
>   bool connected;
> diff --git 

[PATCH] drm: rcar-du: disable dtc graph-endpoint warnings on DT overlays

[Rob Herring]

The rcar DT overlays are missing symetrical remote-endpoint properties
in their graph nodes because the remote-endpoint is fixed up at
run-time. Disable the dtc 'graph-endpoint' warnings when compiling these
overlays. If this becomes a common problem for overlays, then perhaps
this check needs to be disabled for all overlays.

Reported-by: Stephen Rothwell 
Cc: Laurent Pinchart 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Signed-off-by: Rob Herring 
---
This needs to go thru my tree because it is dependent on the dtc update 
that adds the warning (perhaps we're going to need to add option 
checking for dtc).

Rob 

 drivers/gpu/drm/rcar-du/Makefile | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 3e58ed93d5b1..2a3b8d7972b5 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -17,3 +17,10 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)   += rcar_du_vsp.o
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
 obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
+
+# 'remote-endpoint' is fixed up at run-time
+DTC_FLAGS_rcar_du_of_lvds_r8a7790 += -Wno-graph_endpoint
+DTC_FLAGS_rcar_du_of_lvds_r8a7791 += -Wno-graph_endpoint
+DTC_FLAGS_rcar_du_of_lvds_r8a7793 += -Wno-graph_endpoint
+DTC_FLAGS_rcar_du_of_lvds_r8a7795 += -Wno-graph_endpoint
+DTC_FLAGS_rcar_du_of_lvds_r8a7796 += -Wno-graph_endpoint
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #14 from john-s...@gmx.net ---
Same Problem here (HP zbook 15u 5g).

https://bugzilla.kernel.org/show_bug.cgi?id=199609

Chen Yu recommended to write a request on amd-...@lists.freedesktop.org with no
success so far.

https://lists.freedesktop.org/archives/amd-gfx/2018-May/022064.html

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/connector: Add generic underscan properties

[Boris Brezillon]

On Mon, 7 May 2018 17:25:30 +0200
Daniel Vetter  wrote:

> On Mon, May 07, 2018 at 05:15:33PM +0200, Daniel Vetter wrote:
> > On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillon wrote:  
> > > We have 3 drivers defining the "underscan", "underscan hborder" and
> > > "underscan vborder" properties (radeon, amd and nouveau) and we are
> > > about to add the same kind of thing in VC4.
> > > 
> > > Define generic underscan props and add new fields to the drm_connector
> > > state so that the property parsing logic can be shared by all DRM
> > > drivers.
> > > 
> > > A driver can now attach underscan properties to its connector through
> > > the drm_connector_attach_underscan_properties() helper, and can
> > > check/apply the underscan setup based on the
> > > drm_connector_state->underscan fields.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c|  12 
> > >  drivers/gpu/drm/drm_connector.c | 120 
> > > 
> > >  include/drm/drm_connector.h |  78 ++
> > >  3 files changed, 210 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index dc850b4b6e21..b7312bd172c9 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1278,6 +1278,12 @@ static int 
> > > drm_atomic_connector_set_property(struct drm_connector *connector,
> > >   return -EINVAL;
> > >   }
> > >   state->content_protection = val;
> > > + } else if (property == connector->underscan_mode_property) {
> > > + state->underscan.mode = val;
> > > + } else if (property == connector->underscan_hborder_property) {
> > > + state->underscan.hborder = val;
> > > + } else if (property == connector->underscan_vborder_property) {
> > > + state->underscan.vborder = val;
> > >   } else if (connector->funcs->atomic_set_property) {
> > >   return connector->funcs->atomic_set_property(connector,
> > >   state, property, val);
> > > @@ -1359,6 +1365,12 @@ drm_atomic_connector_get_property(struct 
> > > drm_connector *connector,
> > >   *val = state->scaling_mode;
> > >   } else if (property == connector->content_protection_property) {
> > >   *val = state->content_protection;
> > > + } else if (property == connector->underscan_mode_property) {
> > > + *val = state->underscan.mode;
> > > + } else if (property == connector->underscan_hborder_property) {
> > > + *val = state->underscan.hborder;
> > > + } else if (property == connector->underscan_vborder_property) {
> > > + *val = state->underscan.vborder;
> > >   } else if (connector->funcs->atomic_get_property) {
> > >   return connector->funcs->atomic_get_property(connector,
> > >   state, property, val);
> > > diff --git a/drivers/gpu/drm/drm_connector.c 
> > > b/drivers/gpu/drm/drm_connector.c
> > > index dfc8ca1e9413..9937390b8a25 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -914,6 +914,31 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, 
> > > drm_cp_enum_list)
> > >   *   can also expose this property to external outputs, in which 
> > > case they
> > >   *   must support "None", which should be the default (since 
> > > external screens
> > >   *   have a built-in scaler).  
> > 
> > I think a new section here would be good, to make it more obvious this is
> > a group of properties. Plus a reference to
> > drm_connector_attach_underscan_properties().
> >   
> > > + *
> > > + * underscan:
> > > + *   This properties defines whether underscan is activated or not, 
> > > and when
> > > + *   it is activated, how the horizontal and vertical borders are 
> > > calculated:
> > > + *
> > > + *   off:
> > > + *   Underscan is disabled. The output image shouldn't be 
> > > scaled to
> > > + *   take screen borders into account.
> > > + *   on:
> > > + *   Underscan is activated and horizontal and vertical 
> > > borders are
> > > + *   specified through the "underscan hborder" and
> > > + *   "underscan vborder" properties.
> > > + *   auto:
> > > + *   Underscan is activated and horizontal and vertical 
> > > borders are
> > > + *   automatically chosen by the driver.
> > > + *
> > > + * underscan hborder:
> > > + *   Horizontal border expressed in pixels. The border is symmetric, 
> > > which
> > > + *   means you'll have half of this value placed on the left and the 
> > > other
> > > + *   half on the right.
> > > + *
> > > + * underscan vborder:
> > > + *   Vertical border expressed in pixels. The border is symmetric, 
> > > which
> > > + *   means you'll have half of this value placed on the top and the 
> 

Re: [PATCH 1/3] drm/connector: Add generic underscan properties

[Boris Brezillon]

On Tue, 8 May 2018 10:18:10 +1000
Ben Skeggs  wrote:

> On 8 May 2018 at 04:26, Harry Wentland  wrote:
> >
> >
> > On 2018-05-07 12:19 PM, Boris Brezillon wrote:  
> >> On Mon, 7 May 2018 18:01:44 +0300
> >> Ville Syrjälä  wrote:
> >>  
> >>> On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillon wrote:  
>  We have 3 drivers defining the "underscan", "underscan hborder" and
>  "underscan vborder" properties (radeon, amd and nouveau) and we are
>  about to add the same kind of thing in VC4.
> 
>  Define generic underscan props and add new fields to the drm_connector
>  state so that the property parsing logic can be shared by all DRM
>  drivers.
> 
>  A driver can now attach underscan properties to its connector through
>  the drm_connector_attach_underscan_properties() helper, and can
>  check/apply the underscan setup based on the
>  drm_connector_state->underscan fields.
> 
>  Signed-off-by: Boris Brezillon 
>  ---
>   drivers/gpu/drm/drm_atomic.c|  12 
>   drivers/gpu/drm/drm_connector.c | 120 
>  
>   include/drm/drm_connector.h |  78 ++
>   3 files changed, 210 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>  index dc850b4b6e21..b7312bd172c9 100644
>  --- a/drivers/gpu/drm/drm_atomic.c
>  +++ b/drivers/gpu/drm/drm_atomic.c
>  @@ -1278,6 +1278,12 @@ static int 
>  drm_atomic_connector_set_property(struct drm_connector *connector,
>  return -EINVAL;
>  }
>  state->content_protection = val;
>  +   } else if (property == connector->underscan_mode_property) {
>  +   state->underscan.mode = val;
>  +   } else if (property == connector->underscan_hborder_property) {
>  +   state->underscan.hborder = val;
>  +   } else if (property == connector->underscan_vborder_property) {
>  +   state->underscan.vborder = val;
>  } else if (connector->funcs->atomic_set_property) {
>  return connector->funcs->atomic_set_property(connector,
>  state, property, val);
>  @@ -1359,6 +1365,12 @@ drm_atomic_connector_get_property(struct 
>  drm_connector *connector,
>  *val = state->scaling_mode;
>  } else if (property == connector->content_protection_property) {
>  *val = state->content_protection;
>  +   } else if (property == connector->underscan_mode_property) {
>  +   *val = state->underscan.mode;
>  +   } else if (property == connector->underscan_hborder_property) {
>  +   *val = state->underscan.hborder;
>  +   } else if (property == connector->underscan_vborder_property) {
>  +   *val = state->underscan.vborder;
>  } else if (connector->funcs->atomic_get_property) {
>  return connector->funcs->atomic_get_property(connector,
>  state, property, val);
>  diff --git a/drivers/gpu/drm/drm_connector.c 
>  b/drivers/gpu/drm/drm_connector.c
>  index dfc8ca1e9413..9937390b8a25 100644
>  --- a/drivers/gpu/drm/drm_connector.c
>  +++ b/drivers/gpu/drm/drm_connector.c
>  @@ -914,6 +914,31 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, 
>  drm_cp_enum_list)
>    * can also expose this property to external outputs, in which case they
>    * must support "None", which should be the default (since external 
>  screens
>    * have a built-in scaler).
>  + *
>  + * underscan:
>  + * This properties defines whether underscan is activated or not, and 
>  when
>  + * it is activated, how the horizontal and vertical borders are 
>  calculated:
>  + *
>  + * off:
>  + * Underscan is disabled. The output image shouldn't be scaled 
>  to
>  + * take screen borders into account.  
> >>>  
>  + * on:
>  + * Underscan is activated and horizontal and vertical borders 
>  are
>  + * specified through the "underscan hborder" and
>  + * "underscan vborder" properties.  
> >>>
> >>> How is the output scaled?  
> >>
> >> In HW. The formula is
> >>
> >>   hfactor = (hdisplay - hborder) / hdisplay
> >>   vfactor = (vdisplay - vborder) / vdisplay
> >>  
> >>> What does the user mode hdisplay/vdisplay mean
> >>> in this case?  
> >>
> >> The same as before this patch: the output resolution. You just add
> >> black margins.
> >>  
> >>> What if I want underscan without scaling?  
> >>
> >> Then don't involve the DRM driver and do that from userspace: just
> >> fill the visible portion of the framebuffer and leave the rest black.
> >> There nothing the DRM driver 

Re: [PATCH] drm: Match sysfs name in link removal to link creation

[Sean Paul]

On Fri, May 11, 2018 at 07:15:42AM +0300, Haneen Mohammed wrote:
> This patch matches the sysfs name used in the unlinking with the
> linking function. Otherwise, remove_compat_control_link() fails to remove
> sysfs created by create_compat_control_link() in drm_dev_register().
> 
> Signed-off-by: Haneen Mohammed 

Hey Haneen,
Nice catch! I've applied this to drm-misc-fixes with applicable Fixes and Cc
tags.

Sean

> ---
>  drivers/gpu/drm/drm_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a1b9338736e3..c2c21d839727 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -716,7 +716,7 @@ static void remove_compat_control_link(struct drm_device 
> *dev)
>   if (!minor)
>   return;
>  
> - name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);
> + name = kasprintf(GFP_KERNEL, "controlD%d", minor->index + 64);
>   if (!name)
>   return;
>  
> -- 
> 2.17.0
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #13 from Thomas Martitz  ---
I'll report the bug on the other site as well. 

In my view: Loading the amdgpu module breaks resuming from suspend. Maybe the
module isn't correctly adapted to the changes made in generic subsystems
earlier.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #12 from Michel Dänzer  ---
That's debatable, given you bisected to a non-amdgpu commit, which affects WiFi
as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #11 from Thomas Martitz  ---
I can suspend+resume just fine with amdgpu blacklisted, so I'm under the
impression that this is the right place.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90

[Maxime Ripard]

On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > as found on the Ainol AW1 tablet.
> > > 
> > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > the two extra lanes per component are grounded.
> > > 
> > > In the future, it might become necessary to introduce a dedicated
> > > device-tree property to specify the bus format to use instead of the
> > > default one for the panel. This will allow supporting different bus
> > > formats for the same panel modes.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  drivers/gpu/drm/panel/panel-simple.c | 26 ++
> > >  1 file changed, 26 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > > b/drivers/gpu/drm/panel/panel-simple.c
> > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 = 
> > > {
> > >   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > >  };
> > >  
> > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > + .clock = 4,
> > > + .hdisplay = 800,
> > > + .hsync_start = 800 + 112,
> > > + .hsync_end = 800 + 112 + 1,
> > > + .htotal = 800 + 112 + 1 + 87,
> > > + .vdisplay = 480,
> > > + .vsync_start = 480 + 141,
> > > + .vsync_end = 480 + 141 + 1,
> > > + .vtotal = 480 + 141 + 1 + 38,
> > > + .vrefresh = 60,
> > > +};
> > > +
> > > +static const struct panel_desc innolux_at070tn90 = {
> > > + .modes = _at070tn90_mode,
> > > + .num_modes = 1,
> > > + .size = {
> > > + .width = 154,
> > > + .height = 86,
> > > + },
> > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > +};
> > > +
> > 
> > I'm not really convinced this is the right approach. You said it
> > yourself, the panel is using a 24-bits interface, and you just happen
> > to have a tablet that routed it using a 18-bits interface instead.
> > 
> > That doesn't belong in the driver, especially associated to the
> > compatible, but where the routing is described: in the device
> > tree. And given that the panel interface is a 24 bits panel, if we
> > were to have a default, we should have this one, and not the one
> > fitting your use case.
> 
> I fully agree, this is why I suggested introducing a dedicated dt
> property for selecting the bus format (in the commit message). I still
> proposed this patch as a temporary solution, but I'm definitely willing
> to craft a proper solution as well.
> 
> Here is an initial proposition:
> 1. Making bus_format an array in struct panel_desc and listing all the
> relevant bus formats that the panel can support there;

I'm not sure this is needed, the input format is always the same in
your case, the panel will always take a 24 bits RGB value. What you
want to change is the encoder output format (and I guess you want that
to be meaningful to enable or not the dithering).

> 2. Introducing an optional "bus-format" dt property that indicates which
> bus format to use, and using the first index of the bus formats array if
> the property is not present;

I guess the width would be enough, and that way we can take the
bus-width format that is already defined (but used in the v4l2
framework, not in DRM yet).

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106473] Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106473

--- Comment #2 from Matt Whitlock  ---
(In reply to Michel Dänzer from comment #1)
> Does
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=6f81e07ecb8c0793dc482307d5d96fd3df95b7d2 help?

I've applied this patch and rebuilt Mesa. I'll reply again soon as to whether I
see the crash recur.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/4] backlight: fix device-tree node lookups

[Lee Jones]

On Fri, 11 May 2018, Johan Hovold wrote:

> Hi Lee,
> 
> On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote:
> > A number of drivers have been using the wrong OF helper when doing 
> > child-node
> > lookups during probe. This meant that they were doing tree-wide searches 
> > rather
> > than matching on child nodes and that the parent node could end up being
> > prematurely freed.
> 
> > Johan Hovold (4):
> >   backlight: as3711_bl: fix device-tree node lookup
> >   backlight: max8925_bl: fix device-tree node lookup
> >   backlight: tps65217_bl: fix device-tree node lookup
> >   backlight: as3711_bl: fix device-tree node leaks
> 
> It appears these four have been sitting in your for-backlight-fixes 
> branch for half a year now without being forwarded to Linus.
> 
> Don't get many backlight fixes these days, huh? ;)

Ha!  To be honest I think those patches are the only 4 -fixes I've
*ever* had for Backlight. :)

I have pulled them into the main branch, so they won't be forgotten
again.  Sorry for the delay.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: exynos: Change return type to vm_fault_t

[Inki Dae]

2018년 05월 10일 23:27에 Souptick Joarder 이(가) 쓴 글:
> On Sat, Apr 14, 2018 at 9:34 PM, Souptick Joarder  
> wrote:
>> Use new return type vm_fault_t for fault handler
>> in struct vm_operations_struct.
>>
>> Signed-off-by: Souptick Joarder 
>> Reviewed-by: Matthew Wilcox 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 21 -
>>  drivers/gpu/drm/exynos/exynos_drm_gem.h |  3 ++-
>>  2 files changed, 6 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 11cc01b..6e1494f 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -431,37 +431,24 @@ int exynos_drm_gem_dumb_create(struct drm_file 
>> *file_priv,
>> return 0;
>>  }
>>
>> -int exynos_drm_gem_fault(struct vm_fault *vmf)
>> +vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf)
>>  {
>> struct vm_area_struct *vma = vmf->vma;
>> struct drm_gem_object *obj = vma->vm_private_data;
>> struct exynos_drm_gem *exynos_gem = to_exynos_gem(obj);
>> unsigned long pfn;
>> pgoff_t page_offset;
>> -   int ret;
>>
>> page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>>
>> if (page_offset >= (exynos_gem->size >> PAGE_SHIFT)) {
>> DRM_ERROR("invalid page offset\n");
>> -   ret = -EINVAL;
>> -   goto out;
>> +   return VM_FAULT_SIGBUS;
>> }
>>
>> pfn = page_to_pfn(exynos_gem->pages[page_offset]);
>> -   ret = vm_insert_mixed(vma, vmf->address, __pfn_to_pfn_t(pfn, 
>> PFN_DEV));
>> -
>> -out:
>> -   switch (ret) {
>> -   case 0:
>> -   case -ERESTARTSYS:
>> -   case -EINTR:
>> -   return VM_FAULT_NOPAGE;
>> -   case -ENOMEM:
>> -   return VM_FAULT_OOM;
>> -   default:
>> -   return VM_FAULT_SIGBUS;
>> -   }
>> +   return vmf_insert_mixed(vma, vmf->address,
>> +   __pfn_to_pfn_t(pfn, PFN_DEV));
>>  }
>>
>>  static int exynos_drm_gem_mmap_obj(struct drm_gem_object *obj,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> index 5a4c7de..9057d7f 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> @@ -13,6 +13,7 @@
>>  #define _EXYNOS_DRM_GEM_H_
>>
>>  #include 
>> +#include 
>>
>>  #define to_exynos_gem(x)   container_of(x, struct exynos_drm_gem, base)
>>
>> @@ -111,7 +112,7 @@ int exynos_drm_gem_dumb_create(struct drm_file 
>> *file_priv,
>>struct drm_mode_create_dumb *args);
>>
>>  /* page fault handler and mmap fault address(virtual) to physical memory. */
>> -int exynos_drm_gem_fault(struct vm_fault *vmf);
>> +vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf);
>>
>>  /* set vm_flags and we can change the vm attribute to other one at here. */
>>  int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>> --
>> 1.9.1
>>
> 
> Any comment on this patch ?
> 

Cleanup one so merged it already to -next.

Thanks,
Inki Dae

> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106447] System freeze after resuming from suspend (amdgpu)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106447

--- Comment #10 from Michel Dänzer  ---
Looks like you should report this at
https://bugzilla.kernel.org/enter_bug.cgi?product=Power%20Management=Hibernation/Suspend
.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 84740] black screen after Grub loads a kernel entry (Intel Atom D2xxx/N2xxx Integrated Graphics Controller)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=84740

Jani Saarinen  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #11 from Jani Saarinen  ---
OK, thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106473] Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106473

--- Comment #1 from Michel Dänzer  ---
Does
https://cgit.freedesktop.org/mesa/mesa/commit/?id=6f81e07ecb8c0793dc482307d5d96fd3df95b7d2
help?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-next

[Maarten Lankhorst]

Hey,

Another pull request for drm-misc-next. Previous one was not applied yet,
but only sending delta since last request:
https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html

drm-misc-next-2018-05-11-1:
drm-misc-next for v4.18:

UAPI Changes:
- Aspect ratio support for 64:27 and 256:135, usable by atomic clients
and legacy clients that set DRM_CLIENT_CAP_ASPECT_RATIO.

Core Changes:
- Aspect ratio validation has become more strict.
- A few DP fixes.
- Unneeded stubs from sync_debug interface removed.

Driver Changes:
- Small fixes to xen-front.

The following changes since commit 741c3aeb82c78e173aa7155aaffb971e5c73ab3c:

drm/bridge/synopsys: dsi: use adjusted_mode in mode_set (2018-04-26 08:24:26 
+0200)

are available in the Git repository at:

git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-05-11-1

for you to fetch changes up to ef6ccc68a46ddfe0b4afae365bf2188356238b5d:

drm: Add and handle new aspect ratios in DRM layer (2018-05-11 09:07:45 +0200)


drm-misc-next for v4.18:

UAPI Changes:
- Aspect ratio support for 64:27 and 256:135, usable by atomic clients
and legacy clients that set DRM_CLIENT_CAP_ASPECT_RATIO.

Core Changes:
- Aspect ratio validation has become more strict.
- A few DP fixes.
- Unneeded stubs from sync_debug interface removed.

Driver Changes:
- Small fixes to xen-front.


Andy Shevchenko (1):
drm: panel-orientation-quirks: Convert to use match_string() helper

Ankit Nautiyal (3):
drm: Add DRM client cap for aspect-ratio
drm: Handle aspect ratio info in legacy modeset path
drm: Expose modes with aspect ratio, only if requested

Colin Ian King (1):
gpu: drm: sti: fix spelling mistake: "initialze" -> "initialize"

Dan Carpenter (3):
drm/xen-front: checking for NULL instead of IS_ERR
drm/xen-front: fix xen_drm_front_shbuf_alloc() error handling
drm/xen-front: Fix loop timeout

Daniel Vetter (13):
dma-fence: Some kerneldoc polish for dma-fence.h
drm: Drop DRM_CONTROL_ALLOW from ioctls
drm/i915: Drop DRM_CONTROL_ALLOW
drm/vmwgfx: Drop DRM_CONTROL_ALLOW
dma-fence: remove fill_driver_data callback
dma-fence: Make ->enable_signaling optional
dma-fence: Allow wait_any_timeout for all fences
dma-fence: Make ->wait callback optional
drm: Remove unecessary dma_fence_ops
drm/qxl: Remove unecessary dma_fence_ops
Revert 
190c462d5be19ba622a82f5fd0625087c870a1e6..bf3012ada1be770de5c35c1bb16f73b3a01d"
drm/msm: Don't setup control node debugfs files
drm: remove all control node code

Eric Anholt (6):
drm: Make the prime vmap/vunmap hooks optional.
drm/vc4: Skip ULPS latching when we're in that ULPS state already.
drm/panel: Enable DSI transactions on the RPi panel.
drm/vc4: Add a pad field to align drm_vc4_submit_cl to 64 bits.
dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.
drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

Ezequiel Garcia (1):
dma-buf: Remove unneeded stubs around sync_debug interfaces

Gerd Hoffmann (4):
qxl: remove qxl_io_log()
qxl: move qxl_send_monitors_config()
qxl: hook monitors_config updates into crtc, not encoder.
qxl: drop dummy functions

Jia-Ju Bai (1):
gpu: drm: bridge: adv7511: Replace mdelay with usleep_range in adv7511_probe

Kristian H. Kristensen (1):
drm/rockchip: Disable blending for win0

Linus Walleij (3):
drm/pl111: Support the Versatile Express
drm/pl111: Enable device-specific assigned memory
drm/pl111: Fix module probe bug

Maarten Lankhorst (5):
drm/rect: Round above 1 << 16 upwards to correct scale calculation functions.
drm/rect: Handle rounding errors in drm_rect_clip_scaled, v3.
drm/i915: Do not adjust scale when out of bounds, v2.
drm/selftests: Rename the Kconfig option to CONFIG_DRM_DEBUG_SELFTEST
drm/selftests: Add drm helper selftest

Manasi Navare (1):
drm/dp: Rename the edp_sdp_header as dp_sdp_header

Matt Atwood (2):
drm/dp: Add DP_DPCD_REV_XX to drm_dp_helper
drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

Peter Rosin (1):
drm/bridge: adv7511: fix spelling of driver name in Kconfig

Philippe CORNU (3):
drm/stm: ltdc: fix deferred endpoint management
drm/stm: ltdc: add mode_valid()
drm/stm: ltdc: fix warnings in ltdc_plane_create()

Satendra Singh Thakur (1):
drm/atomic: Handling the case when setting old crtc for plane

Sharma, Shashank (2):
drm: Add aspect ratio parsing in DRM layer
drm: Add and handle new aspect ratios in DRM layer

Stefan Schake (3):
drm/vc4: Syncobj import support
drm/vc4: Export fence through syncobj
drm/vc4: Enable syncobj support

Tom Callaway (1):
drm/tinydrm/mi0283qt: Always set rotation value

Vaishali Thakkar (1):
drm/vc4: make function vc4_allocate_bin_bo static

Ville Syrjälä (7):
drm: Don't pass the index to drm_property_add_enum()
drm/rect: Fix drm_rect_rotation_inv() docs
drm/modes: Introduce drm_mode_match()
drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
drm/edid: Fix 

Re: [Intel-gfx] [PATCH v14 10/10] drm: Add and handle new aspect ratios in DRM layer

[Maarten Lankhorst]

Op 09-05-18 om 22:24 schreef Daniel Vetter:
> On Tue, May 08, 2018 at 04:39:45PM +0530, Nautiyal, Ankit K wrote:
>> From: "Sharma, Shashank" 
>>
>> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
>> - 64:27
>> - 256:135
>>
>> This patch:
>> -  Adds new DRM flags for to represent these new aspect ratios.
>> -  Adds new cases to handle these aspect ratios while converting
>> from user->kernel mode or vise versa.
>>
>> This patch was once reviewed and merged, and later reverted due
>> to lack of DRM client protection, while adding aspect ratio bits
>> in user modes. This is a re-spin of the series, with DRM client
>> cap protection.
>>
>> The previous series can be found here:
>> https://pw-emeril.freedesktop.org/series/10850/
>>
>> Signed-off-by: Shashank Sharma 
>> Reviewed-by: Sean Paul  (V2)
>> Reviewed-by: Jose Abreu  (V2)
>>
>> Cc: Ville Syrjala 
>> Cc: Sean Paul 
>> Cc: Jose Abreu 
>> Cc: Ankit Nautiyal 
> Since I bikeshedded the drm core bits and they all look good now imo, on
> patches 6-10:
>
> Acked-by: Daniel Vetter 
Thanks, pushed with ack. :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/4] backlight: fix device-tree node lookups

[Johan Hovold]

Hi Lee,

On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote:
> A number of drivers have been using the wrong OF helper when doing child-node
> lookups during probe. This meant that they were doing tree-wide searches 
> rather
> than matching on child nodes and that the parent node could end up being
> prematurely freed.

> Johan Hovold (4):
>   backlight: as3711_bl: fix device-tree node lookup
>   backlight: max8925_bl: fix device-tree node lookup
>   backlight: tps65217_bl: fix device-tree node lookup
>   backlight: as3711_bl: fix device-tree node leaks

It appears these four have been sitting in your for-backlight-fixes 
branch for half a year now without being forwarded to Linus.

Don't get many backlight fixes these days, huh? ;)

Thanks,
Johan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

[Chris Wilson]

Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> Change how dma_fence_add_callback() behaves, when the fence
> has error-signaled by the time it is being add. After this commit,
> dma_fence_add_callback() returns the fence error, if it
> has error-signaled before dma_fence_add_callback() is called.

Why? What problem are you trying to solve? fence->error does not imply
that the fence has yet been signaled, and the caller wants a callback
when it is signaled.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

[Chris Wilson]

Quoting Ezequiel Garcia (2018-05-10 13:51:56)
> On Wed, 2018-05-09 at 19:42 -0300, Gustavo Padovan wrote:
> > Hi Ezequiel,
> > 
> > On Wed, 2018-05-09 at 17:14 -0300, Ezequiel Garcia wrote:
> > > Change how dma_fence_add_callback() behaves, when the fence
> > > has error-signaled by the time it is being add. After this commit,
> > > dma_fence_add_callback() returns the fence error, if it
> > > has error-signaled before dma_fence_add_callback() is called.
> > > 
> > > Signed-off-by: Ezequiel Garcia 
> > > ---
> > >  drivers/dma-buf/dma-fence.c | 10 ++
> > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-
> > > fence.c
> > > index 4edb9fd3cf47..298b440c5b68 100644
> > > --- a/drivers/dma-buf/dma-fence.c
> > > +++ b/drivers/dma-buf/dma-fence.c
> > > @@ -226,7 +226,8 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
> > >   *
> > >   * Note that the callback can be called from an atomic context.  If
> > >   * fence is already signaled, this function will return -ENOENT (and
> > > - * *not* call the callback)
> > > + * *not* call the callback). If the fence is error-signaled, this
> > > + * function returns the fence error.
> > >   *
> > >   * Add a software callback to the fence. Same restrictions apply to
> > >   * refcount as it does to dma_fence_wait, however the caller doesn't
> > > need to
> > > @@ -235,8 +236,8 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
> > >   * after it signals with dma_fence_signal. The callback itself can
> > > be called
> > >   * from irq context.
> > >   *
> > > - * Returns 0 in case of success, -ENOENT if the fence is already
> > > signaled
> > > - * and -EINVAL in case of error.
> > > + * Returns 0 in case of success, -ENOENT (or the error value) if the
> > > fence is
> > > + * already signaled and -EINVAL in case of error.
> > >   */
> > >  int dma_fence_add_callback(struct dma_fence *fence, struct
> > > dma_fence_cb *cb,
> > >dma_fence_func_t func)
> > > @@ -250,7 +251,8 @@ int dma_fence_add_callback(struct dma_fence
> > > *fence, struct dma_fence_cb *cb,
> > >  
> > > if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
> > > INIT_LIST_HEAD(>node);
> > > -   return -ENOENT;
> > > +   ret = (fence->error < 0) ? fence->error : -ENOENT;
> > > +   return ret;
> > > }
> > 
> > It looks good to me, but I'd first go check all place we call it in the
> > kernel because I have some memory of callers relying on the -ENOENT
> > return code for some decision. I might be wrong though.
> > 
> > 
> 
> I checked all users before submitting this patch.
> 
> git grep " = dma_fence_add_callback"
> drivers/gpu/drm/i915/i915_sw_fence.c:   ret = dma_fence_add_callback(dma, 
> >base, func);
> 
> And from what I could see, all of them handle the error
> properly.

Err, no. That error then is propagated back to userspace, and that is
not part of our ABI...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Match sysfs name in link removal to link creation

[Haneen Mohammed]

This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_link() fails to remove
sysfs created by create_compat_control_link() in drm_dev_register().

Signed-off-by: Haneen Mohammed 
---
 drivers/gpu/drm/drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a1b9338736e3..c2c21d839727 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -716,7 +716,7 @@ static void remove_compat_control_link(struct drm_device 
*dev)
if (!minor)
return;
 
-   name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);
+   name = kasprintf(GFP_KERNEL, "controlD%d", minor->index + 64);
if (!name)
return;
 
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: drm: drm_vm: Adding new typedef vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
 drivers/gpu/drm/drm_vm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 2660543..c330104 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -100,7 +100,7 @@ static pgprot_t drm_dma_prot(uint32_t map_type, struct 
vm_area_struct *vma)
  * map, get the page, increment the use count and return it.
  */
 #if IS_ENABLED(CONFIG_AGP)
-static int drm_vm_fault(struct vm_fault *vmf)
+static vm_fault_t drm_vm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -173,7 +173,7 @@ static int drm_vm_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS; /* Disallow mremap */
 }
 #else
-static int drm_vm_fault(struct vm_fault *vmf)
+static vm_fault_t drm_vm_fault(struct vm_fault *vmf)
 {
return VM_FAULT_SIGBUS;
 }
@@ -189,7 +189,7 @@ static int drm_vm_fault(struct vm_fault *vmf)
  * Get the mapping, find the real physical page to map, get the page, and
  * return it.
  */
-static int drm_vm_shm_fault(struct vm_fault *vmf)
+static vm_fault_t drm_vm_shm_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
@@ -291,7 +291,7 @@ static void drm_vm_shm_close(struct vm_area_struct *vma)
  *
  * Determine the page number from the page offset and get it from 
drm_device_dma::pagelist.
  */
-static int drm_vm_dma_fault(struct vm_fault *vmf)
+static vm_fault_t drm_vm_dma_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_file *priv = vma->vm_file->private_data;
@@ -326,7 +326,7 @@ static int drm_vm_dma_fault(struct vm_fault *vmf)
  *
  * Determine the map offset from the page offset and get it from 
drm_sg_mem::pagelist.
  */
-static int drm_vm_sg_fault(struct vm_fault *vmf)
+static vm_fault_t drm_vm_sg_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_local_map *map = vma->vm_private_data;
--
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] gpu: drm: udl: Adding new typedef vm_fault_t

[Souptick Joarder]

On Wed, Apr 25, 2018 at 10:29 AM, Souptick Joarder  wrote:
> Use new return type vm_fault_t for fault and huge_fault
> handler. For now, this is just documenting that the
> function returns a VM_FAULT value rather than an errno.
> Once all instances are converted, vm_fault_t will become
> a distinct type.
>
> Commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Previously vm_insert_page() returns err which driver
> mapped into VM_FAULT_* type. The new function vmf_
> insert_page() will replace this inefficiency by
> returning VM_FAULT_* type.
>
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Matthew Wilcox 
> ---
> v2: Updated the change log
>
>  drivers/gpu/drm/udl/udl_drv.h |  3 ++-
>  drivers/gpu/drm/udl/udl_gem.c | 15 ++-
>  2 files changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index 2a75ab8..11151c4 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -16,6 +16,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #define DRIVER_NAME"udl"
>  #define DRIVER_DESC"DisplayLink"
> @@ -134,7 +135,7 @@ struct drm_gem_object *udl_gem_prime_import(struct 
> drm_device *dev,
>  int udl_gem_vmap(struct udl_gem_object *obj);
>  void udl_gem_vunmap(struct udl_gem_object *obj);
>  int udl_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
> -int udl_gem_fault(struct vm_fault *vmf);
> +vm_fault_t udl_gem_fault(struct vm_fault *vmf);
>
>  int udl_handle_damage(struct udl_framebuffer *fb, int x, int y,
>   int width, int height);
> diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> index dee6bd9..cf5fe35 100644
> --- a/drivers/gpu/drm/udl/udl_gem.c
> +++ b/drivers/gpu/drm/udl/udl_gem.c
> @@ -100,13 +100,12 @@ int udl_drm_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
> return ret;
>  }
>
> -int udl_gem_fault(struct vm_fault *vmf)
> +vm_fault_t udl_gem_fault(struct vm_fault *vmf)
>  {
> struct vm_area_struct *vma = vmf->vma;
> struct udl_gem_object *obj = to_udl_bo(vma->vm_private_data);
> struct page *page;
> unsigned int page_offset;
> -   int ret = 0;
>
> page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>
> @@ -114,17 +113,7 @@ int udl_gem_fault(struct vm_fault *vmf)
> return VM_FAULT_SIGBUS;
>
> page = obj->pages[page_offset];
> -   ret = vm_insert_page(vma, vmf->address, page);
> -   switch (ret) {
> -   case -EAGAIN:
> -   case 0:
> -   case -ERESTARTSYS:
> -   return VM_FAULT_NOPAGE;
> -   case -ENOMEM:
> -   return VM_FAULT_OOM;
> -   default:
> -   return VM_FAULT_SIGBUS;
> -   }
> +   return vmf_insert_page(vma, vmf->address, page);
>  }
>
>  int udl_gem_get_pages(struct udl_gem_object *obj)
> --
> 1.9.1
>

Any comment on this patch ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] lib/ratelimit: Lockless ratelimiting

[Dmitry Safonov]

Currently ratelimit_state is protected with spin_lock. If the .lock is
taken at the moment of ___ratelimit() call, the message is suppressed to
make ratelimiting robust.

That results in the following issue issue:
  CPU0  CPU1
--   --
printk_ratelimit()   printk_ratelimit()
| |
  try_spin_lock()  try_spin_lock()
| |
time_is_before_jiffies()  return 0; // suppress

So, concurrent call of ___ratelimit() results in silently suppressing
one of the messages, regardless if the limit is reached or not.
And rc->missed is not increased in such case so the issue is covered
from user.

Convert ratelimiting to use atomic counters and drop spin_lock.

Note: in the rare corner-case when (rs->burst == 0) and concurrent
access suppressed message might be printed from both (several) CPUs,
that are accessing ratelimit.

Note: That might be unexpected, but with the first interval of messages
storm one can print up to burst*2 messages. So, it doesn't guarantee
that in *any* interval amount of messages is lesser than burst.
But, that differs lightly from previous behavior where one can start
burst=5 interval and print 4 messages on the last milliseconds of
interval + new 5 messages from new interval (totally 9 messages in
lesser than interval value).

Cc: Arnd Bergmann 
Cc: David Airlie 
Cc: Greg Kroah-Hartman 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: "Theodore Ts'o" 
Cc: Thomas Gleixner 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dmitry Safonov 
---
 drivers/char/random.c| 16 ---
 drivers/gpu/drm/i915/i915_perf.c |  4 +--
 include/linux/ratelimit.h| 24 +---
 lib/ratelimit.c  | 59 +++-
 4 files changed, 50 insertions(+), 53 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index c1c40c7ed0e8..3694cbcb04a0 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -937,25 +937,21 @@ static void crng_reseed(struct crng_state *crng, struct 
entropy_store *r)
crng->init_time = jiffies;
spin_unlock_irqrestore(>lock, flags);
if (crng == _crng && crng_init < 2) {
+   int unseeded_miss, urandom_miss;
+
invalidate_batched_entropy();
numa_crng_init();
crng_init = 2;
process_random_ready_list();
wake_up_interruptible(_init_wait);
pr_notice("random: crng init done\n");
-   if (unseeded_warning.missed) {
+   if ((unseeded_miss = atomic_xchg(_warning.missed, 0)))
pr_notice("random: %d get_random_xx warning(s) missed "
- "due to ratelimiting\n",
- unseeded_warning.missed);
-   unseeded_warning.missed = 0;
-   }
+ "due to ratelimiting\n", unseeded_miss);
unseeded_warning.flags = 0;
-   if (urandom_warning.missed) {
+   if ((urandom_miss = atomic_xchg(_warning.missed, 0)))
pr_notice("random: %d urandom warning(s) missed "
- "due to ratelimiting\n",
- urandom_warning.missed);
-   urandom_warning.missed = 0;
-   }
+ "due to ratelimiting\n", urandom_miss);
urandom_warning.flags = 0;
}
 }
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index abaca6edeb71..a8e00913bdb9 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1316,9 +1316,9 @@ static void i915_oa_stream_destroy(struct 
i915_perf_stream *stream)
 
put_oa_config(dev_priv, stream->oa_config);
 
-   if (dev_priv->perf.oa.spurious_report_rs.missed) {
+   if (atomic_read(_priv->perf.oa.spurious_report_rs.missed)) {
DRM_NOTE("%d spurious OA report notices suppressed due to 
ratelimiting\n",
-dev_priv->perf.oa.spurious_report_rs.missed);
+
atomic_read(_priv->perf.oa.spurious_report_rs.missed));
}
 }
 
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
index e9a14a7641e0..ddc572389f08 100644
--- a/include/linux/ratelimit.h
+++ b/include/linux/ratelimit.h
@@ -4,7 +4,6 @@
 
 #include 
 #include 
-#include 
 
 #define DEFAULT_RATELIMIT_INTERVAL (5 * HZ)
 #define DEFAULT_RATELIMIT_BURST10
@@ -13,21 +12,21 @@
 #define RATELIMIT_MSG_ON_RELEASE   BIT(0)

Re: [PATCH 4/4] drm/tegra: Refactor IOMMU attach/detach

[Dmitry Osipenko]

On 04.05.2018 16:37, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Attaching to and detaching from an IOMMU uses the same code sequence in
> every driver, so factor it out into separate helpers.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/dc.c   | 42 ++--
>  drivers/gpu/drm/tegra/drm.c  | 42 
>  drivers/gpu/drm/tegra/drm.h  |  4 
>  drivers/gpu/drm/tegra/gr2d.c | 32 +++
>  drivers/gpu/drm/tegra/gr3d.c | 31 ++
>  5 files changed, 68 insertions(+), 83 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index c843f11043db..3e7ec3937346 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -1837,21 +1837,11 @@ static int tegra_dc_init(struct host1x_client *client)
>   if (!dc->syncpt)
>   dev_warn(dc->dev, "failed to allocate syncpoint\n");
>  
> - if (tegra->domain) {
> - dc->group = iommu_group_get(client->dev);
> -
> - if (dc->group && dc->group != tegra->group) {
> - err = iommu_attach_group(tegra->domain, dc->group);
> - if (err < 0) {
> - dev_err(dc->dev,
> - "failed to attach to domain: %d\n",
> - err);
> - iommu_group_put(dc->group);
> - return err;
> - }
> -
> - tegra->group = dc->group;
> - }
> + dc->group = host1x_client_iommu_attach(client, true);
> + if (IS_ERR(dc->group)) {
> + err = PTR_ERR(dc->group);
> + dev_err(client->dev, "failed to attach to domain: %d\n", err);
> + return err;
>   }
>  
>   if (dc->soc->wgrps)
> @@ -1916,15 +1906,7 @@ static int tegra_dc_init(struct host1x_client *client)
>   if (!IS_ERR(primary))
>   drm_plane_cleanup(primary);
>  
> - if (dc->group) {
> - if (dc->group == tegra->group) {
> - iommu_detach_group(tegra->domain, dc->group);
> - tegra->group = NULL;
> - }
> -
> - iommu_group_put(dc->group);
> - }
> -
> + host1x_client_iommu_detach(client, dc->group);
>   host1x_syncpt_free(dc->syncpt);
>  
>   return err;
> @@ -1932,9 +1914,7 @@ static int tegra_dc_init(struct host1x_client *client)
>  
>  static int tegra_dc_exit(struct host1x_client *client)
>  {
> - struct drm_device *drm = dev_get_drvdata(client->parent);
>   struct tegra_dc *dc = host1x_client_to_dc(client);
> - struct tegra_drm *tegra = drm->dev_private;
>   int err;
>  
>   devm_free_irq(dc->dev, dc->irq, dc);
> @@ -1945,15 +1925,7 @@ static int tegra_dc_exit(struct host1x_client *client)
>   return err;
>   }
>  
> - if (dc->group) {
> - if (dc->group == tegra->group) {
> - iommu_detach_group(tegra->domain, dc->group);
> - tegra->group = NULL;
> - }
> -
> - iommu_group_put(dc->group);
> - }
> -
> + host1x_client_iommu_detach(client, dc->group);
>   host1x_syncpt_free(dc->syncpt);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 7afe2f635f74..bc1008305e1e 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -1114,6 +1114,48 @@ int tegra_drm_unregister_client(struct tegra_drm 
> *tegra,
>   return 0;
>  }
>  
> +struct iommu_group *host1x_client_iommu_attach(struct host1x_client *client,
> +bool shared)
> +{
> + struct drm_device *drm = dev_get_drvdata(client->parent);
> + struct tegra_drm *tegra = drm->dev_private;
> + struct iommu_group *group = NULL;
> + int err;
> +
> + if (tegra->domain) {
> + group = iommu_group_get(client->dev);
> +
> + if (group && (!shared || (shared && (group != tegra->group {
> + err = iommu_attach_group(tegra->domain, group);
> + if (err < 0) {
> + iommu_group_put(group);
> + return ERR_PTR(err);
> + }
> +
> + if (shared && !tegra->group)
> + tegra->group = group;

Nit: Probably it doesn't make much sense to have devices unattached to BO's AS,
what about to error out here or at least display a error/warning message?

@@ -1796,7 +1796,12 @@ struct iommu_group *host1x_client_iommu_attach(struct
host1x_client *client,
if (tegra->domain) {
group = iommu_group_get(client->dev);

-   if (group && (!shared || (shared && (group != tegra->group {
+   if (!group) {
+   

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

[Ezequiel Garcia]

On Wed, 2018-05-09 at 19:42 -0300, Gustavo Padovan wrote:
> Hi Ezequiel,
> 
> On Wed, 2018-05-09 at 17:14 -0300, Ezequiel Garcia wrote:
> > Change how dma_fence_add_callback() behaves, when the fence
> > has error-signaled by the time it is being add. After this commit,
> > dma_fence_add_callback() returns the fence error, if it
> > has error-signaled before dma_fence_add_callback() is called.
> > 
> > Signed-off-by: Ezequiel Garcia 
> > ---
> >  drivers/dma-buf/dma-fence.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-
> > fence.c
> > index 4edb9fd3cf47..298b440c5b68 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -226,7 +226,8 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
> >   *
> >   * Note that the callback can be called from an atomic context.  If
> >   * fence is already signaled, this function will return -ENOENT (and
> > - * *not* call the callback)
> > + * *not* call the callback). If the fence is error-signaled, this
> > + * function returns the fence error.
> >   *
> >   * Add a software callback to the fence. Same restrictions apply to
> >   * refcount as it does to dma_fence_wait, however the caller doesn't
> > need to
> > @@ -235,8 +236,8 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
> >   * after it signals with dma_fence_signal. The callback itself can
> > be called
> >   * from irq context.
> >   *
> > - * Returns 0 in case of success, -ENOENT if the fence is already
> > signaled
> > - * and -EINVAL in case of error.
> > + * Returns 0 in case of success, -ENOENT (or the error value) if the
> > fence is
> > + * already signaled and -EINVAL in case of error.
> >   */
> >  int dma_fence_add_callback(struct dma_fence *fence, struct
> > dma_fence_cb *cb,
> >dma_fence_func_t func)
> > @@ -250,7 +251,8 @@ int dma_fence_add_callback(struct dma_fence
> > *fence, struct dma_fence_cb *cb,
> >  
> > if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
> > INIT_LIST_HEAD(>node);
> > -   return -ENOENT;
> > +   ret = (fence->error < 0) ? fence->error : -ENOENT;
> > +   return ret;
> > }
> 
> It looks good to me, but I'd first go check all place we call it in the
> kernel because I have some memory of callers relying on the -ENOENT
> return code for some decision. I might be wrong though.
> 
> 

I checked all users before submitting this patch.

git grep " = dma_fence_add_callback"
drivers/gpu/drm/i915/i915_sw_fence.c:   ret = dma_fence_add_callback(dma, 
>base, func);
drivers/gpu/drm/scheduler/gpu_scheduler.c:  r = 
dma_fence_add_callback(fence, _fence->cb,
drivers/gpu/drm/scheduler/gpu_scheduler.c:  r = 
dma_fence_add_callback(fence, _fence->cb,

And from what I could see, all of them handle the error
properly.

Thanks,
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] gpu: drm: armada: Adding new typedef vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler in
struct vm_operations_struct. For now, this is just
documenting that the function returns a VM_FAULT
value rather than an errno. Once all instances are
converted, vm_fault_t will become a distinct type.

commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Previously vm_insert_pfn() returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_pfn() will replace this inefficiency by
returning VM_FAULT_* type.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
---
v2: Updated the change log

 drivers/gpu/drm/armada/armada_gem.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index a97f509..81a55b7 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -13,25 +13,14 @@
 #include 
 #include "armada_ioctlP.h"

-static int armada_gem_vm_fault(struct vm_fault *vmf)
+static vm_fault_t armada_gem_vm_fault(struct vm_fault *vmf)
 {
struct drm_gem_object *gobj = vmf->vma->vm_private_data;
struct armada_gem_object *obj = drm_to_armada_gem(gobj);
unsigned long pfn = obj->phys_addr >> PAGE_SHIFT;
-   int ret;

pfn += (vmf->address - vmf->vma->vm_start) >> PAGE_SHIFT;
-   ret = vm_insert_pfn(vmf->vma, vmf->address, pfn);
-
-   switch (ret) {
-   case 0:
-   case -EBUSY:
-   return VM_FAULT_NOPAGE;
-   case -ENOMEM:
-   return VM_FAULT_OOM;
-   default:
-   return VM_FAULT_SIGBUS;
-   }
+   return vmf_insert_pfn(vmf->vma, vmf->address, pfn);
 }

 const struct vm_operations_struct armada_gem_vm_ops = {
--
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

[Souptick Joarder]

Hi Gerd /Daniel,

On Tue, Apr 24, 2018 at 6:05 PM, Gerd Hoffmann  wrote:
> On Tue, Apr 24, 2018 at 02:11:51PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote:
>> > On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote:
>> > > Use new return type vm_fault_t for fault handler. For
>> > > now, this is just documenting that the function returns
>> > > a VM_FAULT value rather than an errno. Once all instances
>> > > are converted, vm_fault_t will become a distinct type.
>> > >
>> > > Reference id -> 1c8f422059ae ("mm: change return type to
>> > > vm_fault_t")
>> >
>> > Hmm, that commit isn't yet in drm-misc-next.
>> > Will drm-misc-next merge with 4.17-rcX soon?
>>
>> For backmerge requests you need to cc/ping the drm-misc maintainers.
>> Adding them. I think the hold-up also was that Dave was on vacations
>> still.
>
> Ah, ok.
>
> So my expectation that a backmerge happens anyway after -rc1/2 is in
> line with reality, it is just to be delayed this time.  I'll stay
> tuned ;)

Is this patch already merged in drm-misc-next tree ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: exynos: Change return type to vm_fault_t

[Souptick Joarder]

On Sat, Apr 14, 2018 at 9:34 PM, Souptick Joarder  wrote:
> Use new return type vm_fault_t for fault handler
> in struct vm_operations_struct.
>
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Matthew Wilcox 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 21 -
>  drivers/gpu/drm/exynos/exynos_drm_gem.h |  3 ++-
>  2 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 11cc01b..6e1494f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -431,37 +431,24 @@ int exynos_drm_gem_dumb_create(struct drm_file 
> *file_priv,
> return 0;
>  }
>
> -int exynos_drm_gem_fault(struct vm_fault *vmf)
> +vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf)
>  {
> struct vm_area_struct *vma = vmf->vma;
> struct drm_gem_object *obj = vma->vm_private_data;
> struct exynos_drm_gem *exynos_gem = to_exynos_gem(obj);
> unsigned long pfn;
> pgoff_t page_offset;
> -   int ret;
>
> page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>
> if (page_offset >= (exynos_gem->size >> PAGE_SHIFT)) {
> DRM_ERROR("invalid page offset\n");
> -   ret = -EINVAL;
> -   goto out;
> +   return VM_FAULT_SIGBUS;
> }
>
> pfn = page_to_pfn(exynos_gem->pages[page_offset]);
> -   ret = vm_insert_mixed(vma, vmf->address, __pfn_to_pfn_t(pfn, 
> PFN_DEV));
> -
> -out:
> -   switch (ret) {
> -   case 0:
> -   case -ERESTARTSYS:
> -   case -EINTR:
> -   return VM_FAULT_NOPAGE;
> -   case -ENOMEM:
> -   return VM_FAULT_OOM;
> -   default:
> -   return VM_FAULT_SIGBUS;
> -   }
> +   return vmf_insert_mixed(vma, vmf->address,
> +   __pfn_to_pfn_t(pfn, PFN_DEV));
>  }
>
>  static int exynos_drm_gem_mmap_obj(struct drm_gem_object *obj,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> index 5a4c7de..9057d7f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> @@ -13,6 +13,7 @@
>  #define _EXYNOS_DRM_GEM_H_
>
>  #include 
> +#include 
>
>  #define to_exynos_gem(x)   container_of(x, struct exynos_drm_gem, base)
>
> @@ -111,7 +112,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
>struct drm_mode_create_dumb *args);
>
>  /* page fault handler and mmap fault address(virtual) to physical memory. */
> -int exynos_drm_gem_fault(struct vm_fault *vmf);
> +vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf);
>
>  /* set vm_flags and we can change the vm attribute to other one at here. */
>  int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
> --
> 1.9.1
>

Any comment on this patch ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t

[Souptick Joarder]

Hi Sean,

On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder  wrote:
> Use new return type vm_fault_t for fault handler.
>
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Matthew Wilcox 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 2524ff1..c64a859 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct drm_gem_object 
> *obj)
> kfree(vgem_obj);
>  }
>
> -static int vgem_gem_fault(struct vm_fault *vmf)
> +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
>  {
> struct vm_area_struct *vma = vmf->vma;
> struct drm_vgem_gem_object *obj = vma->vm_private_data;
> /* We don't use vmf->pgoff since that has the fake offset */
> unsigned long vaddr = vmf->address;
> -   int ret;
> +   vm_fault_t ret = VM_FAULT_SIGBUS;
> loff_t num_pages;
> pgoff_t page_offset;
> page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> if (page_offset > num_pages)
> return VM_FAULT_SIGBUS;
>
> -   ret = -ENOENT;
> mutex_lock(>pages_lock);
> if (obj->pages) {
> get_page(obj->pages[page_offset]);
> --
> 1.9.1
>

Any further comment on this patch ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] ratelimit: Do not lose messages under limit

[Dmitry Safonov]

There are two issues with ratelimiting as far a I can see:
1. Messages may be lost even if their amount fit burst limit;
2. "suppressed" message may not be printed if there is no call to
   ___ratelimit() after interval ends.

I address (1) issue in the second patch.
While the (2) issue will require adding timers to print "suppressed"
message and care if ratelimit is on stack and no more exists. Which
looks too much at this point.

Dmitry Safonov (2):
  random: Omit double-printing ratelimit messages
  lib/ratelimit: Lockless ratelimiting

 drivers/char/random.c| 22 +++
 drivers/gpu/drm/i915/i915_perf.c |  4 +--
 include/linux/ratelimit.h| 34 ++-
 lib/ratelimit.c  | 59 +++-
 4 files changed, 61 insertions(+), 58 deletions(-)

-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization

[Christian König]

Looks like a good idea to me as well. Reviewed-by: Christian König 
 for the series.


Regards,
Christian.

Am 11.05.2018 um 07:27 schrieb Zhou, David(ChunMing):

The series  is OK to me, Reviewed-by: Chunming  Zhou 
It is better to wait Christian to have a look  before pushing patch.

Regards,
David Zhou
-Original Message-
From: Junwei Zhang [mailto:jerry.zh...@amd.com]
Sent: Friday, May 11, 2018 12:58 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Koenig, Christian ; Zhou, David(ChunMing) 
; Zhang, Jerry 
Subject: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization

Signed-off-by: Junwei Zhang 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..6a9e46a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -419,6 +419,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
  
  	bo->tbo.bdev = >mman.bdev;

amdgpu_ttm_placement_from_domain(bo, bp->domain);
+   if (bp->type == ttm_bo_type_kernel)
+   bo->tbo.priority = 1;
  
  	r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, bp->type,

 >placement, page_align, , acc_size, @@ 
-434,9 +436,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
  
-	if (bp->type == ttm_bo_type_kernel)

-   bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
--
1.9.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel