[BUG] hdlcd gets confused about base address

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

Hi,

While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region.  (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.

This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.

Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.

So, I patched the HDLCD to do this, and testing it with Xorg after
several repetitions seems to work.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
What I think is going on is that the FIFO or address generator for
reading data from the AXI bus is not properly reset when changing the
resolution, and the enable-disable-enable cycle causes the HDLCD
hardware to sort itself out.  It's (eg) significantly out - for example,
to properly align the display, I have to program an address of
0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
before the real start of the frame buffer.

With this patch, a patch to TDA998x to avoid the i2c-designware issue,
and xf86-video-armada, I have LXDE running on the Juno.

Something I also noticed is this:

        scanout_start = gem->paddr + plane->state->fb->offsets[0] +
                plane->state->crtc_y * plane->state->fb->pitches[0] +
                plane->state->crtc_x * bpp / 8;

Surely this should be using src_[xy] (which are the position in the
source - iow, memory, and not crtc_[xy] which is the position on the
CRTC displayed window.  To put it another way, the src_* define the
region of the source material that is mapped onto a rectangular area
on the display defined by crtc_*.

Another note is that since the CRTC can't place the plane in arbitary
positions and sizes within the active area, should the atomic_check
ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
size of the active area?

 drivers/gpu/drm/arm/hdlcd_crtc.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae22ddb..3e97acf6e2a7 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
 	clk_prepare_enable(hdlcd->clk);
 	hdlcd_crtc_mode_set_nofb(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
+	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
+	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
 }
 
 static void hdlcd_crtc_disable(struct drm_crtc *crtc)


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

Hi,

While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region.  (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.

This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.

Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.

So, I patched the HDLCD to do this, and testing it with Xorg after
several repetitions seems to work.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
What I think is going on is that the FIFO or address generator for
reading data from the AXI bus is not properly reset when changing the
resolution, and the enable-disable-enable cycle causes the HDLCD
hardware to sort itself out.  It's (eg) significantly out - for example,
to properly align the display, I have to program an address of
0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
before the real start of the frame buffer.

With this patch, a patch to TDA998x to avoid the i2c-designware issue,
and xf86-video-armada, I have LXDE running on the Juno.

Something I also noticed is this:

        scanout_start = gem->paddr + plane->state->fb->offsets[0] +
                plane->state->crtc_y * plane->state->fb->pitches[0] +
                plane->state->crtc_x * bpp / 8;

Surely this should be using src_[xy] (which are the position in the
source - iow, memory, and not crtc_[xy] which is the position on the
CRTC displayed window.  To put it another way, the src_* define the
region of the source material that is mapped onto a rectangular area
on the display defined by crtc_*.

Another note is that since the CRTC can't place the plane in arbitary
positions and sizes within the active area, should the atomic_check
ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
size of the active area?

 drivers/gpu/drm/arm/hdlcd_crtc.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae22ddb..3e97acf6e2a7 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
 	clk_prepare_enable(hdlcd->clk);
 	hdlcd_crtc_mode_set_nofb(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
+	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
+	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
 }
 
 static void hdlcd_crtc_disable(struct drm_crtc *crtc)


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Daniel Vetter]

On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> Hi,
> 
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region.  (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
> 
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.
> 
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.
> 
> So, I patched the HDLCD to do this, and testing it with Xorg after
> several repetitions seems to work.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> What I think is going on is that the FIFO or address generator for
> reading data from the AXI bus is not properly reset when changing the
> resolution, and the enable-disable-enable cycle causes the HDLCD
> hardware to sort itself out.  It's (eg) significantly out - for example,
> to properly align the display, I have to program an address of
> 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> before the real start of the frame buffer.
> 
> With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> and xf86-video-armada, I have LXDE running on the Juno.
> 
> Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
> Surely this should be using src_[xy] (which are the position in the
> source - iow, memory, and not crtc_[xy] which is the position on the
> CRTC displayed window.  To put it another way, the src_* define the
> region of the source material that is mapped onto a rectangular area
> on the display defined by crtc_*.
> 
> Another note is that since the CRTC can't place the plane in arbitary
> positions and sizes within the active area, should the atomic_check
> ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> size of the active area?

Yup, it should. See drm_plane_helper_check_state() and its caller for a
helper to make this easier. Long-term computing this stuff by default and
having a bunch of igts to regression-test it would be good I think, but
that needs CRC support. And lots of work, since we have lots of drivers.
-Daniel

> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae22ddb..3e97acf6e2a7 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
>  	clk_prepare_enable(hdlcd->clk);
>  	hdlcd_crtc_mode_set_nofb(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
>  }
>  
>  static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> 
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [BUG] hdlcd gets confused about base address

[Daniel Vetter]

On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> Hi,
> 
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region.  (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
> 
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.
> 
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.
> 
> So, I patched the HDLCD to do this, and testing it with Xorg after
> several repetitions seems to work.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> What I think is going on is that the FIFO or address generator for
> reading data from the AXI bus is not properly reset when changing the
> resolution, and the enable-disable-enable cycle causes the HDLCD
> hardware to sort itself out.  It's (eg) significantly out - for example,
> to properly align the display, I have to program an address of
> 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> before the real start of the frame buffer.
> 
> With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> and xf86-video-armada, I have LXDE running on the Juno.
> 
> Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
> Surely this should be using src_[xy] (which are the position in the
> source - iow, memory, and not crtc_[xy] which is the position on the
> CRTC displayed window.  To put it another way, the src_* define the
> region of the source material that is mapped onto a rectangular area
> on the display defined by crtc_*.
> 
> Another note is that since the CRTC can't place the plane in arbitary
> positions and sizes within the active area, should the atomic_check
> ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> size of the active area?

Yup, it should. See drm_plane_helper_check_state() and its caller for a
helper to make this easier. Long-term computing this stuff by default and
having a bunch of igts to regression-test it would be good I think, but
that needs CRC support. And lots of work, since we have lots of drivers.
-Daniel

> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae22ddb..3e97acf6e2a7 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
>  	clk_prepare_enable(hdlcd->clk);
>  	hdlcd_crtc_mode_set_nofb(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
>  }
>  
>  static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> 
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> Hi,

Hi Russell,

> 
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region.  (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
> 
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.

Thanks for reporting this. To double check your issue, you are booting
with HDLCD using the native monitor resolution as detected via EDID
and then using xrandr to change the display mode. When you do that you
are seeing the image being shifted to the right. Is that a correct
description? (I'm trying to reproduce it here and want to make sure 
I've got the details right).

> 
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.

Do you resize the display mode as well afer re-enabling HDLCD?

> 
> So, I patched the HDLCD to do this, and testing it with Xorg after
> several repetitions seems to work.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> What I think is going on is that the FIFO or address generator for
> reading data from the AXI bus is not properly reset when changing the
> resolution, and the enable-disable-enable cycle causes the HDLCD
> hardware to sort itself out.

That is likely what is happening. According to the datasheet, changing
the resolution should be done while the HDLCD command mode is disabled,
which is what writing 0 into HDLCD_REG_COMMAND does.


> It's (eg) significantly out - for example,
> to properly align the display, I have to program an address of
> 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> before the real start of the frame buffer.

What is the resolution you are using?

> 
> With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> and xf86-video-armada, I have LXDE running on the Juno.

Can you tell me more about the TDA998x and i2c-designware issue?
Also, I don't think you need to use xf86-video-armada, the mode-setting
driver built into Xorg should be working fine (that is what I've used
in my testing).

> 
> Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
> Surely this should be using src_[xy] (which are the position in the
> source - iow, memory, and not crtc_[xy] which is the position on the
> CRTC displayed window.  To put it another way, the src_* define the
> region of the source material that is mapped onto a rectangular area
> on the display defined by crtc_*.

Yes, that is a bug and most likely the source of the issue that you are
seeing if my understanding of your testing is correct.

> 
> Another note is that since the CRTC can't place the plane in arbitary
> positions and sizes within the active area, should the atomic_check
> ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> size of the active area?

That should be the case, indeed. I'm going prepare a patch to do that.

> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae22ddb..3e97acf6e2a7 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
>  	clk_prepare_enable(hdlcd->clk);
>  	hdlcd_crtc_mode_set_nofb(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);

I am not convinced that this is the right fix. If anything, I would put a
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
line to make sure the command mode is disabled before setting the mode, but
again, I need to understand your use case to make sure that this indeed fixes it.

Best regards,
Liviu

>  }
>  
>  static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> 
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> Hi,

Hi Russell,

> 
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region.  (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
> 
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.

Thanks for reporting this. To double check your issue, you are booting
with HDLCD using the native monitor resolution as detected via EDID
and then using xrandr to change the display mode. When you do that you
are seeing the image being shifted to the right. Is that a correct
description? (I'm trying to reproduce it here and want to make sure 
I've got the details right).

> 
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.

Do you resize the display mode as well afer re-enabling HDLCD?

> 
> So, I patched the HDLCD to do this, and testing it with Xorg after
> several repetitions seems to work.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> What I think is going on is that the FIFO or address generator for
> reading data from the AXI bus is not properly reset when changing the
> resolution, and the enable-disable-enable cycle causes the HDLCD
> hardware to sort itself out.

That is likely what is happening. According to the datasheet, changing
the resolution should be done while the HDLCD command mode is disabled,
which is what writing 0 into HDLCD_REG_COMMAND does.


> It's (eg) significantly out - for example,
> to properly align the display, I have to program an address of
> 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> before the real start of the frame buffer.

What is the resolution you are using?

> 
> With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> and xf86-video-armada, I have LXDE running on the Juno.

Can you tell me more about the TDA998x and i2c-designware issue?
Also, I don't think you need to use xf86-video-armada, the mode-setting
driver built into Xorg should be working fine (that is what I've used
in my testing).

> 
> Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
> Surely this should be using src_[xy] (which are the position in the
> source - iow, memory, and not crtc_[xy] which is the position on the
> CRTC displayed window.  To put it another way, the src_* define the
> region of the source material that is mapped onto a rectangular area
> on the display defined by crtc_*.

Yes, that is a bug and most likely the source of the issue that you are
seeing if my understanding of your testing is correct.

> 
> Another note is that since the CRTC can't place the plane in arbitary
> positions and sizes within the active area, should the atomic_check
> ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> size of the active area?

That should be the case, indeed. I'm going prepare a patch to do that.

> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae22ddb..3e97acf6e2a7 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
>  	clk_prepare_enable(hdlcd->clk);
>  	hdlcd_crtc_mode_set_nofb(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);

I am not convinced that this is the right fix. If anything, I would put a
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
line to make sure the command mode is disabled before setting the mode, but
again, I need to understand your use case to make sure that this indeed fixes it.

Best regards,
Liviu

>  }
>  
>  static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> 
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 11:06:04AM +0000, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > Hi,
> 
> Hi Russell,
> 
> > 
> > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > starts up or shuts down, the display is shifted significantly to the
> > right and wrapped in the active region.  (No sync bars are visible.)
> > The timings are correct, it behaves as if the start address has been
> > shifted many pixels _into_ the framebuffer.
> > 
> > This occurs whenever the display mode size is changed - using xrandr
> > in Xorg shows that changing the resolution triggers the problem
> > almost every time, but changing the refresh rate does not.
> 
> Thanks for reporting this. To double check your issue, you are booting
> with HDLCD using the native monitor resolution as detected via EDID
> and then using xrandr to change the display mode. When you do that you
> are seeing the image being shifted to the right. Is that a correct
> description? (I'm trying to reproduce it here and want to make sure 
> I've got the details right).

I first noticed it when booting with the buggy I2C EDID reading, so
DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
down, I noticed that the framebuffer console was shifted.  It's actually
shifted to the left because framebuffer pixel 0,0 is not displayed.

> > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > and repeated disable/enable cycles do not make the issue re-appear.
> 
> Do you resize the display mode as well afer re-enabling HDLCD?

I quite literally just did:

./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1

(with a devmem2 fixed for ARM64) which immediately fixed the issue.

> > What I think is going on is that the FIFO or address generator for
> > reading data from the AXI bus is not properly reset when changing the
> > resolution, and the enable-disable-enable cycle causes the HDLCD
> > hardware to sort itself out.
> 
> That is likely what is happening. According to the datasheet, changing
> the resolution should be done while the HDLCD command mode is disabled,
> which is what writing 0 into HDLCD_REG_COMMAND does.

That does not appear to be sufficient.

> > It's (eg) significantly out - for example,
> > to properly align the display, I have to program an address of
> > 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> > before the real start of the frame buffer.
> 
> What is the resolution you are using?

In the case I detailed here, 1920x1080.

> > With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> > and xf86-video-armada, I have LXDE running on the Juno.
> 
> Can you tell me more about the TDA998x and i2c-designware issue?
> Also, I don't think you need to use xf86-video-armada, the mode-setting
> driver built into Xorg should be working fine (that is what I've used
> in my testing).

See the i2c-designware thread on lakml.  It's a spontaneous high
interrupt latency causing the Tx FIFO not to be loaded before it
empties, and the i2c-designware crap decides at that point to
immediately generate an I2C stop.  The I2C controller in Juno can
only work reliably in a system which has guaranteed low interrupt
latencies.

> > Something I also noticed is this:
> > 
> >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> >                 plane->state->crtc_x * bpp / 8;
> > 
> > Surely this should be using src_[xy] (which are the position in the
> > source - iow, memory, and not crtc_[xy] which is the position on the
> > CRTC displayed window.  To put it another way, the src_* define the
> > region of the source material that is mapped onto a rectangular area
> > on the display defined by crtc_*.
> 
> Yes, that is a bug and most likely the source of the issue that you are
> seeing if my understanding of your testing is correct.

It isn't the source of this issue at all.  gem->paddr is 0xf5000000, and
the value programmed originally into the register is the same.  So, from
those two pieces of information, we can reasonably assume that crtc_y
and crtc_x were both zero here.

> > Another note is that since the CRTC can't place the plane in arbitary
> > positions and sizes within the active area, should the atomic_check
> > ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> > size of the active area?
> 
> That should be the case, indeed. I'm going prepare a patch to do that.

I've already a patch along the lines of Daniel Vetter's response to this
point which I'm just testing.

> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 48019ae22ddb..3e97acf6e2a7 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> >  	clk_prepare_enable(hdlcd->clk);
> >  	hdlcd_crtc_mode_set_nofb(crtc);
> >  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> 
> I am not convinced that this is the right fix. If anything, I would put a
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
> line to make sure the command mode is disabled before setting the mode, but
> again, I need to understand your use case to make sure that this indeed fixes it.

Maybe hdlcd shouldn't be implementing the ->enable callback but instead
the ->commit callback then?

I'll give it a try.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 11:06:04AM +0000, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > Hi,
> 
> Hi Russell,
> 
> > 
> > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > starts up or shuts down, the display is shifted significantly to the
> > right and wrapped in the active region.  (No sync bars are visible.)
> > The timings are correct, it behaves as if the start address has been
> > shifted many pixels _into_ the framebuffer.
> > 
> > This occurs whenever the display mode size is changed - using xrandr
> > in Xorg shows that changing the resolution triggers the problem
> > almost every time, but changing the refresh rate does not.
> 
> Thanks for reporting this. To double check your issue, you are booting
> with HDLCD using the native monitor resolution as detected via EDID
> and then using xrandr to change the display mode. When you do that you
> are seeing the image being shifted to the right. Is that a correct
> description? (I'm trying to reproduce it here and want to make sure 
> I've got the details right).

I first noticed it when booting with the buggy I2C EDID reading, so
DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
down, I noticed that the framebuffer console was shifted.  It's actually
shifted to the left because framebuffer pixel 0,0 is not displayed.

> > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > and repeated disable/enable cycles do not make the issue re-appear.
> 
> Do you resize the display mode as well afer re-enabling HDLCD?

I quite literally just did:

./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1

(with a devmem2 fixed for ARM64) which immediately fixed the issue.

> > What I think is going on is that the FIFO or address generator for
> > reading data from the AXI bus is not properly reset when changing the
> > resolution, and the enable-disable-enable cycle causes the HDLCD
> > hardware to sort itself out.
> 
> That is likely what is happening. According to the datasheet, changing
> the resolution should be done while the HDLCD command mode is disabled,
> which is what writing 0 into HDLCD_REG_COMMAND does.

That does not appear to be sufficient.

> > It's (eg) significantly out - for example,
> > to properly align the display, I have to program an address of
> > 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> > before the real start of the frame buffer.
> 
> What is the resolution you are using?

In the case I detailed here, 1920x1080.

> > With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> > and xf86-video-armada, I have LXDE running on the Juno.
> 
> Can you tell me more about the TDA998x and i2c-designware issue?
> Also, I don't think you need to use xf86-video-armada, the mode-setting
> driver built into Xorg should be working fine (that is what I've used
> in my testing).

See the i2c-designware thread on lakml.  It's a spontaneous high
interrupt latency causing the Tx FIFO not to be loaded before it
empties, and the i2c-designware crap decides at that point to
immediately generate an I2C stop.  The I2C controller in Juno can
only work reliably in a system which has guaranteed low interrupt
latencies.

> > Something I also noticed is this:
> > 
> >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> >                 plane->state->crtc_x * bpp / 8;
> > 
> > Surely this should be using src_[xy] (which are the position in the
> > source - iow, memory, and not crtc_[xy] which is the position on the
> > CRTC displayed window.  To put it another way, the src_* define the
> > region of the source material that is mapped onto a rectangular area
> > on the display defined by crtc_*.
> 
> Yes, that is a bug and most likely the source of the issue that you are
> seeing if my understanding of your testing is correct.

It isn't the source of this issue at all.  gem->paddr is 0xf5000000, and
the value programmed originally into the register is the same.  So, from
those two pieces of information, we can reasonably assume that crtc_y
and crtc_x were both zero here.

> > Another note is that since the CRTC can't place the plane in arbitary
> > positions and sizes within the active area, should the atomic_check
> > ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> > size of the active area?
> 
> That should be the case, indeed. I'm going prepare a patch to do that.

I've already a patch along the lines of Daniel Vetter's response to this
point which I'm just testing.

> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 48019ae22ddb..3e97acf6e2a7 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> >  	clk_prepare_enable(hdlcd->clk);
> >  	hdlcd_crtc_mode_set_nofb(crtc);
> >  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> 
> I am not convinced that this is the right fix. If anything, I would put a
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
> line to make sure the command mode is disabled before setting the mode, but
> again, I need to understand your use case to make sure that this indeed fixes it.

Maybe hdlcd shouldn't be implementing the ->enable callback but instead
the ->commit callback then?

I'll give it a try.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:06:04AM +0000, Liviu Dudau wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > Hi,
> > 
> > Hi Russell,
> > 
> > > 
> > > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > > starts up or shuts down, the display is shifted significantly to the
> > > right and wrapped in the active region.  (No sync bars are visible.)
> > > The timings are correct, it behaves as if the start address has been
> > > shifted many pixels _into_ the framebuffer.
> > > 
> > > This occurs whenever the display mode size is changed - using xrandr
> > > in Xorg shows that changing the resolution triggers the problem
> > > almost every time, but changing the refresh rate does not.
> > 
> > Thanks for reporting this. To double check your issue, you are booting
> > with HDLCD using the native monitor resolution as detected via EDID
> > and then using xrandr to change the display mode. When you do that you
> > are seeing the image being shifted to the right. Is that a correct
> > description? (I'm trying to reproduce it here and want to make sure 
> > I've got the details right).
> 
> I first noticed it when booting with the buggy I2C EDID reading, so
> DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
> down, I noticed that the framebuffer console was shifted.  It's actually
> shifted to the left because framebuffer pixel 0,0 is not displayed.

I see. So the reason why I did not notice this was the EDID transfers
mostly working for me.

> 
> > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > and repeated disable/enable cycles do not make the issue re-appear.
> > 
> > Do you resize the display mode as well afer re-enabling HDLCD?
> 
> I quite literally just did:
> 
> ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1

Sorry, was not very clear. Under my assumption that you were resizing the
display with xrandr, I was wondering if the issue you were seeing disappeared
when using devmem2 plus the resizing.

> 
> (with a devmem2 fixed for ARM64) which immediately fixed the issue.
> 
> > > What I think is going on is that the FIFO or address generator for
> > > reading data from the AXI bus is not properly reset when changing the
> > > resolution, and the enable-disable-enable cycle causes the HDLCD
> > > hardware to sort itself out.
> > 
> > That is likely what is happening. According to the datasheet, changing
> > the resolution should be done while the HDLCD command mode is disabled,
> > which is what writing 0 into HDLCD_REG_COMMAND does.
> 
> That does not appear to be sufficient.
> 
> > > It's (eg) significantly out - for example,
> > > to properly align the display, I have to program an address of
> > > 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> > > before the real start of the frame buffer.
> > 
> > What is the resolution you are using?
> 
> In the case I detailed here, 1920x1080.
> 
> > > With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> > > and xf86-video-armada, I have LXDE running on the Juno.
> > 
> > Can you tell me more about the TDA998x and i2c-designware issue?
> > Also, I don't think you need to use xf86-video-armada, the mode-setting
> > driver built into Xorg should be working fine (that is what I've used
> > in my testing).
> 
> See the i2c-designware thread on lakml.  It's a spontaneous high
> interrupt latency causing the Tx FIFO not to be loaded before it
> empties, and the i2c-designware crap decides at that point to
> immediately generate an I2C stop.  The I2C controller in Juno can
> only work reliably in a system which has guaranteed low interrupt
> latencies.

Sorry, my email setup had a hickup and it was slow fetching all my emails.
I've seen the thread after replying in this thread.

> 
> > > Something I also noticed is this:
> > > 
> > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > >                 plane->state->crtc_x * bpp / 8;
> > > 
> > > Surely this should be using src_[xy] (which are the position in the
> > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > CRTC displayed window.  To put it another way, the src_* define the
> > > region of the source material that is mapped onto a rectangular area
> > > on the display defined by crtc_*.
> > 
> > Yes, that is a bug and most likely the source of the issue that you are
> > seeing if my understanding of your testing is correct.
> 
> It isn't the source of this issue at all.  gem->paddr is 0xf5000000, and
> the value programmed originally into the register is the same.  So, from
> those two pieces of information, we can reasonably assume that crtc_y
> and crtc_x were both zero here.

Yes, they should be zero all the time, as we don't support plane positioning
with HDLCD.

> 
> > > Another note is that since the CRTC can't place the plane in arbitary
> > > positions and sizes within the active area, should the atomic_check
> > > ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> > > size of the active area?
> > 
> > That should be the case, indeed. I'm going prepare a patch to do that.
> 
> I've already a patch along the lines of Daniel Vetter's response to this
> point which I'm just testing.

OK, let me know how it goes and please Cc me on it.


> 
> > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > index 48019ae22ddb..3e97acf6e2a7 100644
> > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> > >  	clk_prepare_enable(hdlcd->clk);
> > >  	hdlcd_crtc_mode_set_nofb(crtc);
> > >  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > 
> > I am not convinced that this is the right fix. If anything, I would put a
> > hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
> > line to make sure the command mode is disabled before setting the mode, but
> > again, I need to understand your use case to make sure that this indeed fixes it.
> 
> Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> the ->commit callback then?

I believe we need ->enable for the initial setup (cold boot or module reloading).

Best regards,
Liviu

> 
> I'll give it a try.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:06:04AM +0000, Liviu Dudau wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > Hi,
> > 
> > Hi Russell,
> > 
> > > 
> > > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > > starts up or shuts down, the display is shifted significantly to the
> > > right and wrapped in the active region.  (No sync bars are visible.)
> > > The timings are correct, it behaves as if the start address has been
> > > shifted many pixels _into_ the framebuffer.
> > > 
> > > This occurs whenever the display mode size is changed - using xrandr
> > > in Xorg shows that changing the resolution triggers the problem
> > > almost every time, but changing the refresh rate does not.
> > 
> > Thanks for reporting this. To double check your issue, you are booting
> > with HDLCD using the native monitor resolution as detected via EDID
> > and then using xrandr to change the display mode. When you do that you
> > are seeing the image being shifted to the right. Is that a correct
> > description? (I'm trying to reproduce it here and want to make sure 
> > I've got the details right).
> 
> I first noticed it when booting with the buggy I2C EDID reading, so
> DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
> down, I noticed that the framebuffer console was shifted.  It's actually
> shifted to the left because framebuffer pixel 0,0 is not displayed.

I see. So the reason why I did not notice this was the EDID transfers
mostly working for me.

> 
> > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > and repeated disable/enable cycles do not make the issue re-appear.
> > 
> > Do you resize the display mode as well afer re-enabling HDLCD?
> 
> I quite literally just did:
> 
> ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1

Sorry, was not very clear. Under my assumption that you were resizing the
display with xrandr, I was wondering if the issue you were seeing disappeared
when using devmem2 plus the resizing.

> 
> (with a devmem2 fixed for ARM64) which immediately fixed the issue.
> 
> > > What I think is going on is that the FIFO or address generator for
> > > reading data from the AXI bus is not properly reset when changing the
> > > resolution, and the enable-disable-enable cycle causes the HDLCD
> > > hardware to sort itself out.
> > 
> > That is likely what is happening. According to the datasheet, changing
> > the resolution should be done while the HDLCD command mode is disabled,
> > which is what writing 0 into HDLCD_REG_COMMAND does.
> 
> That does not appear to be sufficient.
> 
> > > It's (eg) significantly out - for example,
> > > to properly align the display, I have to program an address of
> > > 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> > > before the real start of the frame buffer.
> > 
> > What is the resolution you are using?
> 
> In the case I detailed here, 1920x1080.
> 
> > > With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> > > and xf86-video-armada, I have LXDE running on the Juno.
> > 
> > Can you tell me more about the TDA998x and i2c-designware issue?
> > Also, I don't think you need to use xf86-video-armada, the mode-setting
> > driver built into Xorg should be working fine (that is what I've used
> > in my testing).
> 
> See the i2c-designware thread on lakml.  It's a spontaneous high
> interrupt latency causing the Tx FIFO not to be loaded before it
> empties, and the i2c-designware crap decides at that point to
> immediately generate an I2C stop.  The I2C controller in Juno can
> only work reliably in a system which has guaranteed low interrupt
> latencies.

Sorry, my email setup had a hickup and it was slow fetching all my emails.
I've seen the thread after replying in this thread.

> 
> > > Something I also noticed is this:
> > > 
> > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > >                 plane->state->crtc_x * bpp / 8;
> > > 
> > > Surely this should be using src_[xy] (which are the position in the
> > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > CRTC displayed window.  To put it another way, the src_* define the
> > > region of the source material that is mapped onto a rectangular area
> > > on the display defined by crtc_*.
> > 
> > Yes, that is a bug and most likely the source of the issue that you are
> > seeing if my understanding of your testing is correct.
> 
> It isn't the source of this issue at all.  gem->paddr is 0xf5000000, and
> the value programmed originally into the register is the same.  So, from
> those two pieces of information, we can reasonably assume that crtc_y
> and crtc_x were both zero here.

Yes, they should be zero all the time, as we don't support plane positioning
with HDLCD.

> 
> > > Another note is that since the CRTC can't place the plane in arbitary
> > > positions and sizes within the active area, should the atomic_check
> > > ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> > > size of the active area?
> > 
> > That should be the case, indeed. I'm going prepare a patch to do that.
> 
> I've already a patch along the lines of Daniel Vetter's response to this
> point which I'm just testing.

OK, let me know how it goes and please Cc me on it.


> 
> > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > index 48019ae22ddb..3e97acf6e2a7 100644
> > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> > >  	clk_prepare_enable(hdlcd->clk);
> > >  	hdlcd_crtc_mode_set_nofb(crtc);
> > >  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > > +	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > 
> > I am not convinced that this is the right fix. If anything, I would put a
> > hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
> > line to make sure the command mode is disabled before setting the mode, but
> > again, I need to understand your use case to make sure that this indeed fixes it.
> 
> Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> the ->commit callback then?

I believe we need ->enable for the initial setup (cold boot or module reloading).

Best regards,
Liviu

> 
> I'll give it a try.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 11:32:12AM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> > I first noticed it when booting with the buggy I2C EDID reading, so
> > DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
> > down, I noticed that the framebuffer console was shifted.  It's actually
> > shifted to the left because framebuffer pixel 0,0 is not displayed.
> 
> I see. So the reason why I did not notice this was the EDID transfers
> mostly working for me.

It also happens when EDID transfers work too!

> > > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > > and repeated disable/enable cycles do not make the issue re-appear.
> > > 
> > > Do you resize the display mode as well afer re-enabling HDLCD?
> > 
> > I quite literally just did:
> > 
> > ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
> 
> Sorry, was not very clear. Under my assumption that you were resizing the
> display with xrandr, I was wondering if the issue you were seeing disappeared
> when using devmem2 plus the resizing.

I think the problems are much deeper.  I've added this:

static void hdlcd_crtc_enable(struct drm_crtc *crtc)
{
        struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
printk("%s: active %d cmd %08x\n", __func__, crtc->state->active, hdlcd_read(hdlcd, HDLCD_REG_COMMAND));
        clk_prepare_enable(hdlcd->clk);

...
static void hdlcd_crtc_disable(struct drm_crtc *crtc)
{
        struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
printk("%s: active %d\n", __func__, crtc->state->active);
        if (!crtc->state->active)
                return;

What I see in the kernel log each time I change the resolution is:

[  221.409577] hdlcd_crtc_disable: active 0
[  221.430206] hdlcd_crtc_enable: active 1 cmd 00000001
[  239.264672] hdlcd_crtc_disable: active 0
[  239.285180] hdlcd_crtc_enable: active 1 cmd 00000001
[  278.712792] hdlcd_crtc_disable: active 0
[  278.730361] hdlcd_crtc_enable: active 1 cmd 00000001
[  281.633841] hdlcd_crtc_disable: active 0
[  281.668578] hdlcd_crtc_enable: active 1 cmd 00000001

So, when ->disable is called, active is always zero.  This
leads to...

$ head -n3 /sys/kernel/debug/clk/clk_summary
   clock                         enable_cnt  prepare_cnt        rate   accuracy
  phase
----------------------------------------------------------------------------------------
 pxlclk                                   6            6   148500000          0 0

the enable and prepare counts for this clock incrementing by one each
time I change the resolution.

> > Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> > the ->commit callback then?
> 
> I believe we need ->enable for the initial setup (cold boot or module
> reloading).

Yes, I found a comment in DRM saying that ->commit is for legacy drivers
only.

I think the problem is that hdlcd is not really knowing what the true
state of the CRTC is, as illustrated by the clock counts increasing
and the state of crtc->state->active.

I'm wondering if this is a core DRM bug though... the comments and
code do not align:

/**
 * drm_atomic_helper_commit_tail - commit atomic update to hardware
 * @state: new modeset state to be committed

void drm_atomic_helper_commit_tail(struct drm_atomic_state *state)
{
        struct drm_device *dev = state->dev;

        drm_atomic_helper_commit_modeset_disables(dev, state);

/**
 * drm_atomic_helper_commit_modeset_disables - modeset commit to disable outputs * @dev: DRM device
 * @old_state: atomic state object with old state structures
void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev,
                                               struct drm_atomic_state *old_state)

So, is "state" in drm_atomic_helper_commit_tail the old state or the
new state?  Should this state be passed to
drm_atomic_helper_commit_modeset_disables(), which seems to expect
the old state?

It looks _really_ screwed up here - in any case, it really doesn't
help when you're not experienced with atomic mode set to work out
what the hell this code is doing... it seems to be a horrible mess.
Maybe someone who understands this code ought to read through it
from the point of view of someone who doesn't understand it and fix
the comments, or get rid of the down-right misleading comments.

Comments are worse than useless if they mislead.  Better to have no
comments than misleading comments.

Daniel?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 11:32:12AM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> > I first noticed it when booting with the buggy I2C EDID reading, so
> > DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
> > down, I noticed that the framebuffer console was shifted.  It's actually
> > shifted to the left because framebuffer pixel 0,0 is not displayed.
> 
> I see. So the reason why I did not notice this was the EDID transfers
> mostly working for me.

It also happens when EDID transfers work too!

> > > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > > and repeated disable/enable cycles do not make the issue re-appear.
> > > 
> > > Do you resize the display mode as well afer re-enabling HDLCD?
> > 
> > I quite literally just did:
> > 
> > ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
> 
> Sorry, was not very clear. Under my assumption that you were resizing the
> display with xrandr, I was wondering if the issue you were seeing disappeared
> when using devmem2 plus the resizing.

I think the problems are much deeper.  I've added this:

static void hdlcd_crtc_enable(struct drm_crtc *crtc)
{
        struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
printk("%s: active %d cmd %08x\n", __func__, crtc->state->active, hdlcd_read(hdlcd, HDLCD_REG_COMMAND));
        clk_prepare_enable(hdlcd->clk);

...
static void hdlcd_crtc_disable(struct drm_crtc *crtc)
{
        struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
printk("%s: active %d\n", __func__, crtc->state->active);
        if (!crtc->state->active)
                return;

What I see in the kernel log each time I change the resolution is:

[  221.409577] hdlcd_crtc_disable: active 0
[  221.430206] hdlcd_crtc_enable: active 1 cmd 00000001
[  239.264672] hdlcd_crtc_disable: active 0
[  239.285180] hdlcd_crtc_enable: active 1 cmd 00000001
[  278.712792] hdlcd_crtc_disable: active 0
[  278.730361] hdlcd_crtc_enable: active 1 cmd 00000001
[  281.633841] hdlcd_crtc_disable: active 0
[  281.668578] hdlcd_crtc_enable: active 1 cmd 00000001

So, when ->disable is called, active is always zero.  This
leads to...

$ head -n3 /sys/kernel/debug/clk/clk_summary
   clock                         enable_cnt  prepare_cnt        rate   accuracy
  phase
----------------------------------------------------------------------------------------
 pxlclk                                   6            6   148500000          0 0

the enable and prepare counts for this clock incrementing by one each
time I change the resolution.

> > Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> > the ->commit callback then?
> 
> I believe we need ->enable for the initial setup (cold boot or module
> reloading).

Yes, I found a comment in DRM saying that ->commit is for legacy drivers
only.

I think the problem is that hdlcd is not really knowing what the true
state of the CRTC is, as illustrated by the clock counts increasing
and the state of crtc->state->active.

I'm wondering if this is a core DRM bug though... the comments and
code do not align:

/**
 * drm_atomic_helper_commit_tail - commit atomic update to hardware
 * @state: new modeset state to be committed

void drm_atomic_helper_commit_tail(struct drm_atomic_state *state)
{
        struct drm_device *dev = state->dev;

        drm_atomic_helper_commit_modeset_disables(dev, state);

/**
 * drm_atomic_helper_commit_modeset_disables - modeset commit to disable outputs * @dev: DRM device
 * @old_state: atomic state object with old state structures
void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev,
                                               struct drm_atomic_state *old_state)

So, is "state" in drm_atomic_helper_commit_tail the old state or the
new state?  Should this state be passed to
drm_atomic_helper_commit_modeset_disables(), which seems to expect
the old state?

It looks _really_ screwed up here - in any case, it really doesn't
help when you're not experienced with atomic mode set to work out
what the hell this code is doing... it seems to be a horrible mess.
Maybe someone who understands this code ought to read through it
from the point of view of someone who doesn't understand it and fix
the comments, or get rid of the down-right misleading comments.

Comments are worse than useless if they mislead.  Better to have no
comments than misleading comments.

Daniel?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 12:25:56PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:32:12AM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> > > I first noticed it when booting with the buggy I2C EDID reading, so
> > > DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
> > > down, I noticed that the framebuffer console was shifted.  It's actually
> > > shifted to the left because framebuffer pixel 0,0 is not displayed.
> > 
> > I see. So the reason why I did not notice this was the EDID transfers
> > mostly working for me.
> 
> It also happens when EDID transfers work too!
> 
> > > > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > > > and repeated disable/enable cycles do not make the issue re-appear.
> > > > 
> > > > Do you resize the display mode as well afer re-enabling HDLCD?
> > > 
> > > I quite literally just did:
> > > 
> > > ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
> > 
> > Sorry, was not very clear. Under my assumption that you were resizing the
> > display with xrandr, I was wondering if the issue you were seeing disappeared
> > when using devmem2 plus the resizing.
> 
> I think the problems are much deeper.  I've added this:
> 
> static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> {
>         struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> printk("%s: active %d cmd %08x\n", __func__, crtc->state->active, hdlcd_read(hdlcd, HDLCD_REG_COMMAND));
>         clk_prepare_enable(hdlcd->clk);
> 
> ...
> static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> {
>         struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> printk("%s: active %d\n", __func__, crtc->state->active);
>         if (!crtc->state->active)
>                 return;
> 
> What I see in the kernel log each time I change the resolution is:
> 
> [  221.409577] hdlcd_crtc_disable: active 0
> [  221.430206] hdlcd_crtc_enable: active 1 cmd 00000001
> [  239.264672] hdlcd_crtc_disable: active 0
> [  239.285180] hdlcd_crtc_enable: active 1 cmd 00000001
> [  278.712792] hdlcd_crtc_disable: active 0
> [  278.730361] hdlcd_crtc_enable: active 1 cmd 00000001
> [  281.633841] hdlcd_crtc_disable: active 0
> [  281.668578] hdlcd_crtc_enable: active 1 cmd 00000001
> 
> So, when ->disable is called, active is always zero.  

That is expected, the DRM framework will determine that the crtc is no longer active and
call ->disable hook on the CRTC helper struct.

> This leads to...
> 
> $ head -n3 /sys/kernel/debug/clk/clk_summary
>    clock                         enable_cnt  prepare_cnt        rate   accuracy
>   phase
> ----------------------------------------------------------------------------------------
>  pxlclk                                   6            6   148500000          0 0
> 
> the enable and prepare counts for this clock incrementing by one each
> time I change the resolution.

That is mostly due to the check in hdlcd_crtc_disable() which I should remove,
I've added it because I was getting a ->disable() hook call before any ->enable()
was called at startup time. I need to revisit this as I remember Daniel was commenting
that this was not needed.

> 
> > > Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> > > the ->commit callback then?
> > 
> > I believe we need ->enable for the initial setup (cold boot or module
> > reloading).
> 
> Yes, I found a comment in DRM saying that ->commit is for legacy drivers
> only.
> 
> I think the problem is that hdlcd is not really knowing what the true
> state of the CRTC is, as illustrated by the clock counts increasing
> and the state of crtc->state->active.

I think crtc->state->active is correct, we are just not acting as we should
in HDLCD.

> 
> I'm wondering if this is a core DRM bug though... the comments and
> code do not align:
> 
> /**
>  * drm_atomic_helper_commit_tail - commit atomic update to hardware
>  * @state: new modeset state to be committed
> 
> void drm_atomic_helper_commit_tail(struct drm_atomic_state *state)
> {
>         struct drm_device *dev = state->dev;
> 
>         drm_atomic_helper_commit_modeset_disables(dev, state);
> 
> /**
>  * drm_atomic_helper_commit_modeset_disables - modeset commit to disable outputs * @dev: DRM device
>  * @old_state: atomic state object with old state structures
> void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev,
>                                                struct drm_atomic_state *old_state)
> 
> So, is "state" in drm_atomic_helper_commit_tail the old state or the
> new state?  Should this state be passed to
> drm_atomic_helper_commit_modeset_disables(), which seems to expect
> the old state?

Yes, you have reached one (of the many?) DRM quirks. When drm_atomic_helper_commit_tail()
gets called the *state pointer contains the old state that was swapped
out by drm_atomic_helper_commit() function before calling commit_tail().
The comment on drm_atomic_helper_commit_tail function (and maybe parameter name)
should be updated.


> 
> It looks _really_ screwed up here - in any case, it really doesn't
> help when you're not experienced with atomic mode set to work out
> what the hell this code is doing... it seems to be a horrible mess.
> Maybe someone who understands this code ought to read through it
> from the point of view of someone who doesn't understand it and fix
> the comments, or get rid of the down-right misleading comments.
> 
> Comments are worse than useless if they mislead.  Better to have no
> comments than misleading comments.

Sometimes code gets shuffled around and functions that made sense in
one workflow are kept in the new workflow except their order gets changed.
I believe that was the case for the function above.

Best regards,
Liviu

> 
> Daniel?
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 12:25:56PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:32:12AM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> > > I first noticed it when booting with the buggy I2C EDID reading, so
> > > DRM wasn't seeing a valid EDID.  Then when Xorg started up and shut
> > > down, I noticed that the framebuffer console was shifted.  It's actually
> > > shifted to the left because framebuffer pixel 0,0 is not displayed.
> > 
> > I see. So the reason why I did not notice this was the EDID transfers
> > mostly working for me.
> 
> It also happens when EDID transfers work too!
> 
> > > > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > > > and repeated disable/enable cycles do not make the issue re-appear.
> > > > 
> > > > Do you resize the display mode as well afer re-enabling HDLCD?
> > > 
> > > I quite literally just did:
> > > 
> > > ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
> > 
> > Sorry, was not very clear. Under my assumption that you were resizing the
> > display with xrandr, I was wondering if the issue you were seeing disappeared
> > when using devmem2 plus the resizing.
> 
> I think the problems are much deeper.  I've added this:
> 
> static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> {
>         struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> printk("%s: active %d cmd %08x\n", __func__, crtc->state->active, hdlcd_read(hdlcd, HDLCD_REG_COMMAND));
>         clk_prepare_enable(hdlcd->clk);
> 
> ...
> static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> {
>         struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> printk("%s: active %d\n", __func__, crtc->state->active);
>         if (!crtc->state->active)
>                 return;
> 
> What I see in the kernel log each time I change the resolution is:
> 
> [  221.409577] hdlcd_crtc_disable: active 0
> [  221.430206] hdlcd_crtc_enable: active 1 cmd 00000001
> [  239.264672] hdlcd_crtc_disable: active 0
> [  239.285180] hdlcd_crtc_enable: active 1 cmd 00000001
> [  278.712792] hdlcd_crtc_disable: active 0
> [  278.730361] hdlcd_crtc_enable: active 1 cmd 00000001
> [  281.633841] hdlcd_crtc_disable: active 0
> [  281.668578] hdlcd_crtc_enable: active 1 cmd 00000001
> 
> So, when ->disable is called, active is always zero.  

That is expected, the DRM framework will determine that the crtc is no longer active and
call ->disable hook on the CRTC helper struct.

> This leads to...
> 
> $ head -n3 /sys/kernel/debug/clk/clk_summary
>    clock                         enable_cnt  prepare_cnt        rate   accuracy
>   phase
> ----------------------------------------------------------------------------------------
>  pxlclk                                   6            6   148500000          0 0
> 
> the enable and prepare counts for this clock incrementing by one each
> time I change the resolution.

That is mostly due to the check in hdlcd_crtc_disable() which I should remove,
I've added it because I was getting a ->disable() hook call before any ->enable()
was called at startup time. I need to revisit this as I remember Daniel was commenting
that this was not needed.

> 
> > > Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> > > the ->commit callback then?
> > 
> > I believe we need ->enable for the initial setup (cold boot or module
> > reloading).
> 
> Yes, I found a comment in DRM saying that ->commit is for legacy drivers
> only.
> 
> I think the problem is that hdlcd is not really knowing what the true
> state of the CRTC is, as illustrated by the clock counts increasing
> and the state of crtc->state->active.

I think crtc->state->active is correct, we are just not acting as we should
in HDLCD.

> 
> I'm wondering if this is a core DRM bug though... the comments and
> code do not align:
> 
> /**
>  * drm_atomic_helper_commit_tail - commit atomic update to hardware
>  * @state: new modeset state to be committed
> 
> void drm_atomic_helper_commit_tail(struct drm_atomic_state *state)
> {
>         struct drm_device *dev = state->dev;
> 
>         drm_atomic_helper_commit_modeset_disables(dev, state);
> 
> /**
>  * drm_atomic_helper_commit_modeset_disables - modeset commit to disable outputs * @dev: DRM device
>  * @old_state: atomic state object with old state structures
> void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev,
>                                                struct drm_atomic_state *old_state)
> 
> So, is "state" in drm_atomic_helper_commit_tail the old state or the
> new state?  Should this state be passed to
> drm_atomic_helper_commit_modeset_disables(), which seems to expect
> the old state?

Yes, you have reached one (of the many?) DRM quirks. When drm_atomic_helper_commit_tail()
gets called the *state pointer contains the old state that was swapped
out by drm_atomic_helper_commit() function before calling commit_tail().
The comment on drm_atomic_helper_commit_tail function (and maybe parameter name)
should be updated.


> 
> It looks _really_ screwed up here - in any case, it really doesn't
> help when you're not experienced with atomic mode set to work out
> what the hell this code is doing... it seems to be a horrible mess.
> Maybe someone who understands this code ought to read through it
> from the point of view of someone who doesn't understand it and fix
> the comments, or get rid of the down-right misleading comments.
> 
> Comments are worse than useless if they mislead.  Better to have no
> comments than misleading comments.

Sometimes code gets shuffled around and functions that made sense in
one workflow are kept in the new workflow except their order gets changed.
I believe that was the case for the function above.

Best regards,
Liviu

> 
> Daniel?
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> That is mostly due to the check in hdlcd_crtc_disable() which I should
> remove, I've added it because I was getting a ->disable() hook call
> before any ->enable() was called at startup time. I need to revisit
> this as I remember Daniel was commenting that this was not needed.

Removing that test results in:

[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out

and the kernel hanging, seemingly in an IRQs-off region.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> That is mostly due to the check in hdlcd_crtc_disable() which I should
> remove, I've added it because I was getting a ->disable() hook call
> before any ->enable() was called at startup time. I need to revisit
> this as I remember Daniel was commenting that this was not needed.

Removing that test results in:

[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out

and the kernel hanging, seemingly in an IRQs-off region.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any ->enable() was called at startup time. I need to revisit
> > this as I remember Daniel was commenting that this was not needed.
> 
> Removing that test results in:
> 
> [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> 
> and the kernel hanging, seemingly in an IRQs-off region.

Right, I need to sort this one out. Are you doing these tests out of
some tagged branch that I can get in sync with?

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any ->enable() was called at startup time. I need to revisit
> > this as I remember Daniel was commenting that this was not needed.
> 
> Removing that test results in:
> 
> [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> 
> and the kernel hanging, seemingly in an IRQs-off region.

Right, I need to sort this one out. Are you doing these tests out of
some tagged branch that I can get in sync with?

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > remove, I've added it because I was getting a ->disable() hook call
> > > before any ->enable() was called at startup time. I need to revisit
> > > this as I remember Daniel was commenting that this was not needed.
> > 
> > Removing that test results in:
> > 
> > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > 
> > and the kernel hanging, seemingly in an IRQs-off region.
> 
> Right, I need to sort this one out. Are you doing these tests out of
> some tagged branch that I can get in sync with?

No, not yet, and some of the changes I have are rather hacky.

I do always build my full tree of patches (which is currently running at
around 320 patches at the moment) but I never share that entire patch
set.  However, none of those touch i2c (apart from the ones I've recently
posted) and the only patches touching hdlcd are those I've posted so far.

Most of the problems I'm finding are through trying basic stuff - I'm not
doing anything special or unusual to find them, at the moment quite
literally just starting Xorg up and shutting it down.  For example, the
above was caused by logging in on serial, running:

	Xorg -terminate -verbose

and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
prompts on both the "framebuffer" and serial - I don't want Xorg coming
up when the machine is booting for its nightly KVM boot tests.)

I'm afraid that when I try someone elses code, I have a tendency to find
loads of seemingly trivial bugs when I try putting it through some basic
tests.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > remove, I've added it because I was getting a ->disable() hook call
> > > before any ->enable() was called at startup time. I need to revisit
> > > this as I remember Daniel was commenting that this was not needed.
> > 
> > Removing that test results in:
> > 
> > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > 
> > and the kernel hanging, seemingly in an IRQs-off region.
> 
> Right, I need to sort this one out. Are you doing these tests out of
> some tagged branch that I can get in sync with?

No, not yet, and some of the changes I have are rather hacky.

I do always build my full tree of patches (which is currently running at
around 320 patches at the moment) but I never share that entire patch
set.  However, none of those touch i2c (apart from the ones I've recently
posted) and the only patches touching hdlcd are those I've posted so far.

Most of the problems I'm finding are through trying basic stuff - I'm not
doing anything special or unusual to find them, at the moment quite
literally just starting Xorg up and shutting it down.  For example, the
above was caused by logging in on serial, running:

	Xorg -terminate -verbose

and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
prompts on both the "framebuffer" and serial - I don't want Xorg coming
up when the machine is booting for its nightly KVM boot tests.)

I'm afraid that when I try someone elses code, I have a tendency to find
loads of seemingly trivial bugs when I try putting it through some basic
tests.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any ->enable() was called at startup time. I need to revisit
> > this as I remember Daniel was commenting that this was not needed.
> 
> Removing that test results in:
> 
> [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> 
> and the kernel hanging, seemingly in an IRQs-off region.

Annoyingly, enabling DRM debug prevents the kernel hanging...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any ->enable() was called at startup time. I need to revisit
> > this as I remember Daniel was commenting that this was not needed.
> 
> Removing that test results in:
> 
> [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> 
> and the kernel hanging, seemingly in an IRQs-off region.

Annoyingly, enabling DRM debug prevents the kernel hanging...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 02:30:53PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > remove, I've added it because I was getting a ->disable() hook call
> > > before any ->enable() was called at startup time. I need to revisit
> > > this as I remember Daniel was commenting that this was not needed.
> > 
> > Removing that test results in:
> > 
> > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > 
> > and the kernel hanging, seemingly in an IRQs-off region.
> 
> Annoyingly, enabling DRM debug prevents the kernel hanging...

I've been trying to trace through what's happening with this flip_done
stuff, but I'm finding it _extremely_ difficult to follow the atomic
code.

(Sorry, I'm going to go over my usual 72 column limit for this due to
the damn long DRM function names.)

I can see that drm_atomic_helper_commit() calls drm_atomic_helper_setup_commit()
which sets up commit->flip_done for each CRTC, and sets up an event for
each.

drm_atomic_helper_commit() continues on to eventually call drm_atomic_helper_swap_state()
which then swaps the state for the CRTCs, but then ends up dropping
the event reference:

	state->crtcs[i].commit->event = NULL;

What I can't see is why this isn't a leaked pointer - I don't see
anything inbetween taking charge of that structure.  The _commit_
hasn't been swapped from what I can see, it's just state->crtcs[i].state
that have been swapped.

So I can't see who's responsible for generating this event, or how the
backend DRM drivers get to know about this event, and that they should
complete the flip.

What I also don't get is why DRM is wanting to wait for a flip event
when we're disabling the CRTC.  None of this makes sense to me, like
much of the atomic modeset code...

(I'm probably never going to convert Armada DRM to atomic modeset, I
just don't seem to be capable of understanding atomic modeset.  Maybe
I'm too old?)

[drm:drm_ioctl] pid=2178, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
[drm:drm_mode_object_unreference] OBJ ID: 38 (4)
[drm:drm_atomic_state_init] Allocated atomic state ffffffc974c7c300
[drm:drm_mode_object_reference] OBJ ID: 43 (1)
[drm:drm_atomic_get_crtc_state] Added [CRTC:24:crtc-0] ffffffc975e59400 state to ffffffc974c7c300
[drm:drm_mode_object_reference] OBJ ID: 38 (3)
[drm:drm_atomic_get_plane_state] Added [PLANE:23:plane-0] ffffffc974c7c100 state to ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 43 (2)
[drm:drm_atomic_set_mode_for_crtc] Set [NOMODE] for CRTC state ffffffc975e59400
[drm:drm_atomic_set_crtc_for_plane] Link plane state ffffffc974c7c100 to [NOCRTC]
[drm:drm_mode_object_unreference] OBJ ID: 38 (4)
[drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state ffffffc974c7c100
[drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:24:crtc-0] to ffffffc974c7c300
[drm:drm_mode_object_reference] OBJ ID: 26 (4)
[drm:drm_mode_object_reference] OBJ ID: 26 (5)
[drm:drm_atomic_get_connector_state] Added [CONNECTOR:26] ffffffc974c7c000 state to ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 26 (6)
[drm:drm_atomic_set_crtc_for_connector] Link connector state ffffffc974c7c000 to [NOCRTC]
[drm:drm_atomic_check_only] checking ffffffc974c7c300
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] mode changed
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] enable changed
[drm:drm_atomic_helper_check_modeset] Updating routing for [CONNECTOR:26:HDMI-A-1]
[drm:drm_atomic_helper_check_modeset] Disabling [CONNECTOR:26:HDMI-A-1]
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] active changed
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] needs all connectors, enable: n, active: n
[drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:24:crtc-0] to ffffffc974c7c300
[drm:drm_atomic_commit] commiting ffffffc974c7c300
[drm:drm_atomic_helper_commit_modeset_disables] disabling [ENCODER:25:TMDS-25]
[drm:drm_atomic_helper_commit_modeset_disables] disabling [CRTC:24:crtc-0]
hdlcd_crtc_disable: active 0
[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
[drm:drm_atomic_state_default_clear] Clearing atomic state ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 26 (5)
[drm:drm_mode_object_unreference] OBJ ID: 26 (4)
[drm:drm_mode_object_unreference] OBJ ID: 43 (1)
[drm:drm_mode_object_unreference] OBJ ID: 38 (3)
[drm:drm_atomic_state_free] Freeing atomic state ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 38 (2)
[drm:drm_mode_object_unreference] OBJ ID: 38 (1)


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 02:30:53PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > remove, I've added it because I was getting a ->disable() hook call
> > > before any ->enable() was called at startup time. I need to revisit
> > > this as I remember Daniel was commenting that this was not needed.
> > 
> > Removing that test results in:
> > 
> > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > 
> > and the kernel hanging, seemingly in an IRQs-off region.
> 
> Annoyingly, enabling DRM debug prevents the kernel hanging...

I've been trying to trace through what's happening with this flip_done
stuff, but I'm finding it _extremely_ difficult to follow the atomic
code.

(Sorry, I'm going to go over my usual 72 column limit for this due to
the damn long DRM function names.)

I can see that drm_atomic_helper_commit() calls drm_atomic_helper_setup_commit()
which sets up commit->flip_done for each CRTC, and sets up an event for
each.

drm_atomic_helper_commit() continues on to eventually call drm_atomic_helper_swap_state()
which then swaps the state for the CRTCs, but then ends up dropping
the event reference:

	state->crtcs[i].commit->event = NULL;

What I can't see is why this isn't a leaked pointer - I don't see
anything inbetween taking charge of that structure.  The _commit_
hasn't been swapped from what I can see, it's just state->crtcs[i].state
that have been swapped.

So I can't see who's responsible for generating this event, or how the
backend DRM drivers get to know about this event, and that they should
complete the flip.

What I also don't get is why DRM is wanting to wait for a flip event
when we're disabling the CRTC.  None of this makes sense to me, like
much of the atomic modeset code...

(I'm probably never going to convert Armada DRM to atomic modeset, I
just don't seem to be capable of understanding atomic modeset.  Maybe
I'm too old?)

[drm:drm_ioctl] pid=2178, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
[drm:drm_mode_object_unreference] OBJ ID: 38 (4)
[drm:drm_atomic_state_init] Allocated atomic state ffffffc974c7c300
[drm:drm_mode_object_reference] OBJ ID: 43 (1)
[drm:drm_atomic_get_crtc_state] Added [CRTC:24:crtc-0] ffffffc975e59400 state to ffffffc974c7c300
[drm:drm_mode_object_reference] OBJ ID: 38 (3)
[drm:drm_atomic_get_plane_state] Added [PLANE:23:plane-0] ffffffc974c7c100 state to ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 43 (2)
[drm:drm_atomic_set_mode_for_crtc] Set [NOMODE] for CRTC state ffffffc975e59400
[drm:drm_atomic_set_crtc_for_plane] Link plane state ffffffc974c7c100 to [NOCRTC]
[drm:drm_mode_object_unreference] OBJ ID: 38 (4)
[drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state ffffffc974c7c100
[drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:24:crtc-0] to ffffffc974c7c300
[drm:drm_mode_object_reference] OBJ ID: 26 (4)
[drm:drm_mode_object_reference] OBJ ID: 26 (5)
[drm:drm_atomic_get_connector_state] Added [CONNECTOR:26] ffffffc974c7c000 state to ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 26 (6)
[drm:drm_atomic_set_crtc_for_connector] Link connector state ffffffc974c7c000 to [NOCRTC]
[drm:drm_atomic_check_only] checking ffffffc974c7c300
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] mode changed
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] enable changed
[drm:drm_atomic_helper_check_modeset] Updating routing for [CONNECTOR:26:HDMI-A-1]
[drm:drm_atomic_helper_check_modeset] Disabling [CONNECTOR:26:HDMI-A-1]
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] active changed
[drm:drm_atomic_helper_check_modeset] [CRTC:24:crtc-0] needs all connectors, enable: n, active: n
[drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:24:crtc-0] to ffffffc974c7c300
[drm:drm_atomic_commit] commiting ffffffc974c7c300
[drm:drm_atomic_helper_commit_modeset_disables] disabling [ENCODER:25:TMDS-25]
[drm:drm_atomic_helper_commit_modeset_disables] disabling [CRTC:24:crtc-0]
hdlcd_crtc_disable: active 0
[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
[drm:drm_atomic_state_default_clear] Clearing atomic state ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 26 (5)
[drm:drm_mode_object_unreference] OBJ ID: 26 (4)
[drm:drm_mode_object_unreference] OBJ ID: 43 (1)
[drm:drm_mode_object_unreference] OBJ ID: 38 (3)
[drm:drm_atomic_state_free] Freeing atomic state ffffffc974c7c300
[drm:drm_mode_object_unreference] OBJ ID: 38 (2)
[drm:drm_mode_object_unreference] OBJ ID: 38 (1)


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > remove, I've added it because I was getting a ->disable() hook call
> > > > before any ->enable() was called at startup time. I need to revisit
> > > > this as I remember Daniel was commenting that this was not needed.
> > > 
> > > Removing that test results in:
> > > 
> > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > 
> > > and the kernel hanging, seemingly in an IRQs-off region.
> > 
> > Right, I need to sort this one out. Are you doing these tests out of
> > some tagged branch that I can get in sync with?

Hi Russell,

> 
> No, not yet, and some of the changes I have are rather hacky.
> 
> I do always build my full tree of patches (which is currently running at
> around 320 patches at the moment) but I never share that entire patch
> set.  However, none of those touch i2c (apart from the ones I've recently
> posted) and the only patches touching hdlcd are those I've posted so far.
> 
> Most of the problems I'm finding are through trying basic stuff - I'm not
> doing anything special or unusual to find them, at the moment quite
> literally just starting Xorg up and shutting it down.  For example, the
> above was caused by logging in on serial, running:
> 
> 	Xorg -terminate -verbose
> 
> and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
> prompts on both the "framebuffer" and serial - I don't want Xorg coming
> up when the machine is booting for its nightly KVM boot tests.)
> 
> I'm afraid that when I try someone elses code, I have a tendency to find
> loads of seemingly trivial bugs when I try putting it through some basic
> tests.

I'm not being able to reproduce your bug conditions. I'm running the following
setup when testing:

- mainline v4.9-rc6
- edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
  hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
- patched tda998x_drv.c to set interlace_allowed = 0, see below why
- modified the hdlcd_crtc.c file with the following patch:

-8<-----------------------------------------------------------------------
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae..656dc43 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
 {
 	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
-	if (!crtc->state->active)
-		return;
-
+	drm_crtc_vblank_off(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
 	clk_disable_unprepare(hdlcd->clk);
 }
->8-----------------------------------------------------------------------

That takes care of the pxlclk refcounting issue you were seeing. I've started
Xorg several times (and yes, I do see EDID checksum error every now and then,
specially when running xrandr). When closing down Xorg I get back the framebuffer
console with the login prompt and no image shifting. My monitor is a TV that
reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
propertly with each other to be able to set the interlaced mode correctly, so
I've had to disable support for interlacing mode in tda998x_drv.c and now the
preferred mode that gets picked up is 1920x1200 at 60Hz.

Please advise on what other steps I can take to try to reproduce this.

P.S: What revision of Juno do you have? Any chance you can capture the start
of the boot process where the firmware component prints the version numbers?

Best regards,
Liviu


> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > remove, I've added it because I was getting a ->disable() hook call
> > > > before any ->enable() was called at startup time. I need to revisit
> > > > this as I remember Daniel was commenting that this was not needed.
> > > 
> > > Removing that test results in:
> > > 
> > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > 
> > > and the kernel hanging, seemingly in an IRQs-off region.
> > 
> > Right, I need to sort this one out. Are you doing these tests out of
> > some tagged branch that I can get in sync with?

Hi Russell,

> 
> No, not yet, and some of the changes I have are rather hacky.
> 
> I do always build my full tree of patches (which is currently running at
> around 320 patches at the moment) but I never share that entire patch
> set.  However, none of those touch i2c (apart from the ones I've recently
> posted) and the only patches touching hdlcd are those I've posted so far.
> 
> Most of the problems I'm finding are through trying basic stuff - I'm not
> doing anything special or unusual to find them, at the moment quite
> literally just starting Xorg up and shutting it down.  For example, the
> above was caused by logging in on serial, running:
> 
> 	Xorg -terminate -verbose
> 
> and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
> prompts on both the "framebuffer" and serial - I don't want Xorg coming
> up when the machine is booting for its nightly KVM boot tests.)
> 
> I'm afraid that when I try someone elses code, I have a tendency to find
> loads of seemingly trivial bugs when I try putting it through some basic
> tests.

I'm not being able to reproduce your bug conditions. I'm running the following
setup when testing:

- mainline v4.9-rc6
- edited the juno-base.dtsi file to disable the hdlcd@7f600000 and
  hdmi-transmitter@70 nodes to remove the second HDMI output from the test.
- patched tda998x_drv.c to set interlace_allowed = 0, see below why
- modified the hdlcd_crtc.c file with the following patch:

-8<-----------------------------------------------------------------------
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae..656dc43 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
 {
 	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
-	if (!crtc->state->active)
-		return;
-
+	drm_crtc_vblank_off(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
 	clk_disable_unprepare(hdlcd->clk);
 }
->8-----------------------------------------------------------------------

That takes care of the pxlclk refcounting issue you were seeing. I've started
Xorg several times (and yes, I do see EDID checksum error every now and then,
specially when running xrandr). When closing down Xorg I get back the framebuffer
console with the login prompt and no image shifting. My monitor is a TV that
reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
propertly with each other to be able to set the interlaced mode correctly, so
I've had to disable support for interlacing mode in tda998x_drv.c and now the
preferred mode that gets picked up is 1920x1200@60Hz.

Please advise on what other steps I can take to try to reproduce this.

P.S: What revision of Juno do you have? Any chance you can capture the start
of the boot process where the firmware component prints the version numbers?

Best regards,
Liviu


> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 05:32:32PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > > remove, I've added it because I was getting a ->disable() hook call
> > > > > before any ->enable() was called at startup time. I need to revisit
> > > > > this as I remember Daniel was commenting that this was not needed.
> > > > 
> > > > Removing that test results in:
> > > > 
> > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > > 
> > > > and the kernel hanging, seemingly in an IRQs-off region.
> > > 
> > > Right, I need to sort this one out. Are you doing these tests out of
> > > some tagged branch that I can get in sync with?
> 
> Hi Russell,
> 
> > 
> > No, not yet, and some of the changes I have are rather hacky.
> > 
> > I do always build my full tree of patches (which is currently running at
> > around 320 patches at the moment) but I never share that entire patch
> > set.  However, none of those touch i2c (apart from the ones I've recently
> > posted) and the only patches touching hdlcd are those I've posted so far.
> > 
> > Most of the problems I'm finding are through trying basic stuff - I'm not
> > doing anything special or unusual to find them, at the moment quite
> > literally just starting Xorg up and shutting it down.  For example, the
> > above was caused by logging in on serial, running:
> > 
> > 	Xorg -terminate -verbose
> > 
> > and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
> > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > up when the machine is booting for its nightly KVM boot tests.)
> > 
> > I'm afraid that when I try someone elses code, I have a tendency to find
> > loads of seemingly trivial bugs when I try putting it through some basic
> > tests.
> 
> I'm not being able to reproduce your bug conditions. I'm running the following
> setup when testing:
> 
> - mainline v4.9-rc6
> - edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
>   hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
> - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> - modified the hdlcd_crtc.c file with the following patch:
> 
> -8<-----------------------------------------------------------------------
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae..656dc43 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
>  {
>  	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>  
> -	if (!crtc->state->active)
> -		return;
> -
> +	drm_crtc_vblank_off(crtc);

Don't you need a drm_crtc_vblank_on() call in the enable function?

>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
>  	clk_disable_unprepare(hdlcd->clk);
>  }
> ->8-----------------------------------------------------------------------
> 
> That takes care of the pxlclk refcounting issue you were seeing. I've started
> Xorg several times (and yes, I do see EDID checksum error every now and then,
> specially when running xrandr). When closing down Xorg I get back the framebuffer
> console with the login prompt and no image shifting.

For me, the image shift was 100% reproducable.  With the above patch
and a call to drm_crtc_vblank_on() in the enable path, it seems to
behave correctly - I can alternately switch between 1920x1080 and
1280x1024 and it behaves correctly.  Indeed, my debug prints show that
the right thing is happening wrt disabling the controller:

[   76.869136] hdlcd_crtc_disable: active 0
[   76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
[   85.262451] hdlcd_crtc_disable: active 0
[   85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
[   92.658038] hdlcd_crtc_disable: active 0
[   92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
[   97.805205] hdlcd_crtc_disable: active 0
[   97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   97.834423] hdlcd_crtc_enable: active 1 cmd 00000000

> My monitor is a TV that
> reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> propertly with each other to be able to set the interlaced mode correctly, so
> I've had to disable support for interlacing mode in tda998x_drv.c and now the
> preferred mode that gets picked up is 1920x1200 at 60Hz.

That's more of a generic DRM issue - the CRTC layer doesn't get a
look-in when a connector parses the modes supplied from the display,
so there's no real way for the CRTC layer to apply any kind of
limitations to the available modes, except when a mode is attempted
to be set.

I don't want to see an "interlace" DT property introduced for the
TDA998x, because that's the wrong approach - it would be adding a
property for the needs of the implementation, and not a description
of the hardware.

> Please advise on what other steps I can take to try to reproduce this.

I guess if you've tried and failed to reproduce it, there is something
very specific to my setup which I can't describe.

> P.S: What revision of Juno do you have? Any chance you can capture the start
> of the boot process where the firmware component prints the version numbers?

All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
(he spent _all_ of last Tuesday logged in to one of my systems trying
to upgrade the firmware) is now running the Linaro 16.10 firmware.
Sudeep says that my hardware is a very early revision which went out
the door without being properly calibrated.

Whether that has any bearing on the reproducability of this or not, I've
no idea.

If you want to see the boot messages, head to my autobuilder status page
and look at the juno-kvm entries - they contain all the boot messages
from initial power up of the juno.  I'll send you a link in private
mail so googlebot doesn't end up hammering on it after it expires.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 05:32:32PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > > remove, I've added it because I was getting a ->disable() hook call
> > > > > before any ->enable() was called at startup time. I need to revisit
> > > > > this as I remember Daniel was commenting that this was not needed.
> > > > 
> > > > Removing that test results in:
> > > > 
> > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > > 
> > > > and the kernel hanging, seemingly in an IRQs-off region.
> > > 
> > > Right, I need to sort this one out. Are you doing these tests out of
> > > some tagged branch that I can get in sync with?
> 
> Hi Russell,
> 
> > 
> > No, not yet, and some of the changes I have are rather hacky.
> > 
> > I do always build my full tree of patches (which is currently running at
> > around 320 patches at the moment) but I never share that entire patch
> > set.  However, none of those touch i2c (apart from the ones I've recently
> > posted) and the only patches touching hdlcd are those I've posted so far.
> > 
> > Most of the problems I'm finding are through trying basic stuff - I'm not
> > doing anything special or unusual to find them, at the moment quite
> > literally just starting Xorg up and shutting it down.  For example, the
> > above was caused by logging in on serial, running:
> > 
> > 	Xorg -terminate -verbose
> > 
> > and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
> > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > up when the machine is booting for its nightly KVM boot tests.)
> > 
> > I'm afraid that when I try someone elses code, I have a tendency to find
> > loads of seemingly trivial bugs when I try putting it through some basic
> > tests.
> 
> I'm not being able to reproduce your bug conditions. I'm running the following
> setup when testing:
> 
> - mainline v4.9-rc6
> - edited the juno-base.dtsi file to disable the hdlcd@7f600000 and
>   hdmi-transmitter@70 nodes to remove the second HDMI output from the test.
> - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> - modified the hdlcd_crtc.c file with the following patch:
> 
> -8<-----------------------------------------------------------------------
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae..656dc43 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
>  {
>  	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>  
> -	if (!crtc->state->active)
> -		return;
> -
> +	drm_crtc_vblank_off(crtc);

Don't you need a drm_crtc_vblank_on() call in the enable function?

>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
>  	clk_disable_unprepare(hdlcd->clk);
>  }
> ->8-----------------------------------------------------------------------
> 
> That takes care of the pxlclk refcounting issue you were seeing. I've started
> Xorg several times (and yes, I do see EDID checksum error every now and then,
> specially when running xrandr). When closing down Xorg I get back the framebuffer
> console with the login prompt and no image shifting.

For me, the image shift was 100% reproducable.  With the above patch
and a call to drm_crtc_vblank_on() in the enable path, it seems to
behave correctly - I can alternately switch between 1920x1080 and
1280x1024 and it behaves correctly.  Indeed, my debug prints show that
the right thing is happening wrt disabling the controller:

[   76.869136] hdlcd_crtc_disable: active 0
[   76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
[   85.262451] hdlcd_crtc_disable: active 0
[   85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
[   92.658038] hdlcd_crtc_disable: active 0
[   92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
[   97.805205] hdlcd_crtc_disable: active 0
[   97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[   97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[   97.834423] hdlcd_crtc_enable: active 1 cmd 00000000

> My monitor is a TV that
> reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> propertly with each other to be able to set the interlaced mode correctly, so
> I've had to disable support for interlacing mode in tda998x_drv.c and now the
> preferred mode that gets picked up is 1920x1200@60Hz.

That's more of a generic DRM issue - the CRTC layer doesn't get a
look-in when a connector parses the modes supplied from the display,
so there's no real way for the CRTC layer to apply any kind of
limitations to the available modes, except when a mode is attempted
to be set.

I don't want to see an "interlace" DT property introduced for the
TDA998x, because that's the wrong approach - it would be adding a
property for the needs of the implementation, and not a description
of the hardware.

> Please advise on what other steps I can take to try to reproduce this.

I guess if you've tried and failed to reproduce it, there is something
very specific to my setup which I can't describe.

> P.S: What revision of Juno do you have? Any chance you can capture the start
> of the boot process where the firmware component prints the version numbers?

All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
(he spent _all_ of last Tuesday logged in to one of my systems trying
to upgrade the firmware) is now running the Linaro 16.10 firmware.
Sudeep says that my hardware is a very early revision which went out
the door without being properly calibrated.

Whether that has any bearing on the reproducability of this or not, I've
no idea.

If you want to see the boot messages, head to my autobuilder status page
and look at the juno-kvm entries - they contain all the boot messages
from initial power up of the juno.  I'll send you a link in private
mail so googlebot doesn't end up hammering on it after it expires.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> For me, the image shift was 100% reproducable.  With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:

Here's my version of your patch:

8<=============
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] drm/arm: hdlcd: fix plane base address update

While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region.  (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.

This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.

Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.
Further debugging shows that we try to update the controller
configuration while enabled.

Alwys ensure that the HDLCD is disabled prior to updating the
controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
so that DRM knows whether it can expect vblank interrupts.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index c239616f5334..9d683be2e5d3 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
 	clk_prepare_enable(hdlcd->clk);
 	hdlcd_crtc_mode_set_nofb(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
+	drm_crtc_vblank_on(crtc);
 }
 
 static void hdlcd_crtc_disable(struct drm_crtc *crtc)
 {
 	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
-	if (!crtc->state->active)
-		return;
-
+	drm_crtc_vblank_off(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
 	clk_disable_unprepare(hdlcd->clk);
 }
-- 
2.7.4

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> For me, the image shift was 100% reproducable.  With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:

Here's my version of your patch:

8<=============
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] drm/arm: hdlcd: fix plane base address update

While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region.  (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.

This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.

Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.
Further debugging shows that we try to update the controller
configuration while enabled.

Alwys ensure that the HDLCD is disabled prior to updating the
controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
so that DRM knows whether it can expect vblank interrupts.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index c239616f5334..9d683be2e5d3 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
 	clk_prepare_enable(hdlcd->clk);
 	hdlcd_crtc_mode_set_nofb(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
+	drm_crtc_vblank_on(crtc);
 }
 
 static void hdlcd_crtc_disable(struct drm_crtc *crtc)
 {
 	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
-	if (!crtc->state->active)
-		return;
-
+	drm_crtc_vblank_off(crtc);
 	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
 	clk_disable_unprepare(hdlcd->clk);
 }
-- 
2.7.4

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:32:32PM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > > > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > > > remove, I've added it because I was getting a ->disable() hook call
> > > > > > before any ->enable() was called at startup time. I need to revisit
> > > > > > this as I remember Daniel was commenting that this was not needed.
> > > > > 
> > > > > Removing that test results in:
> > > > > 
> > > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > > > 
> > > > > and the kernel hanging, seemingly in an IRQs-off region.
> > > > 
> > > > Right, I need to sort this one out. Are you doing these tests out of
> > > > some tagged branch that I can get in sync with?
> > 
> > Hi Russell,
> > 
> > > 
> > > No, not yet, and some of the changes I have are rather hacky.
> > > 
> > > I do always build my full tree of patches (which is currently running at
> > > around 320 patches at the moment) but I never share that entire patch
> > > set.  However, none of those touch i2c (apart from the ones I've recently
> > > posted) and the only patches touching hdlcd are those I've posted so far.
> > > 
> > > Most of the problems I'm finding are through trying basic stuff - I'm not
> > > doing anything special or unusual to find them, at the moment quite
> > > literally just starting Xorg up and shutting it down.  For example, the
> > > above was caused by logging in on serial, running:
> > > 
> > > 	Xorg -terminate -verbose
> > > 
> > > and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
> > > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > > up when the machine is booting for its nightly KVM boot tests.)
> > > 
> > > I'm afraid that when I try someone elses code, I have a tendency to find
> > > loads of seemingly trivial bugs when I try putting it through some basic
> > > tests.
> > 
> > I'm not being able to reproduce your bug conditions. I'm running the following
> > setup when testing:
> > 
> > - mainline v4.9-rc6
> > - edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
> >   hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
> > - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> > - modified the hdlcd_crtc.c file with the following patch:
> > 
> > -8<-----------------------------------------------------------------------
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 48019ae..656dc43 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> >  {
> >  	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >  
> > -	if (!crtc->state->active)
> > -		return;
> > -
> > +	drm_crtc_vblank_off(crtc);
> 
> Don't you need a drm_crtc_vblank_on() call in the enable function?

I do, thanks for calling me on that!

> 
> >  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> >  	clk_disable_unprepare(hdlcd->clk);
> >  }
> > ->8-----------------------------------------------------------------------
> > 
> > That takes care of the pxlclk refcounting issue you were seeing. I've started
> > Xorg several times (and yes, I do see EDID checksum error every now and then,
> > specially when running xrandr). When closing down Xorg I get back the framebuffer
> > console with the login prompt and no image shifting.
> 
> For me, the image shift was 100% reproducable.  With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:

OK, so I'll take it that you did not also use your patch to fix the base plane
calculations, or was that included as well in your stack?

> 
> [   76.869136] hdlcd_crtc_disable: active 0
> [   76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
> [   85.262451] hdlcd_crtc_disable: active 0
> [   85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
> [   92.658038] hdlcd_crtc_disable: active 0
> [   92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
> [   97.805205] hdlcd_crtc_disable: active 0
> [   97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   97.834423] hdlcd_crtc_enable: active 1 cmd 00000000
> 
> > My monitor is a TV that
> > reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> > propertly with each other to be able to set the interlaced mode correctly, so
> > I've had to disable support for interlacing mode in tda998x_drv.c and now the
> > preferred mode that gets picked up is 1920x1200 at 60Hz.
> 
> That's more of a generic DRM issue - the CRTC layer doesn't get a
> look-in when a connector parses the modes supplied from the display,
> so there's no real way for the CRTC layer to apply any kind of
> limitations to the available modes, except when a mode is attempted
> to be set.
> 
> I don't want to see an "interlace" DT property introduced for the
> TDA998x, because that's the wrong approach - it would be adding a
> property for the needs of the implementation, and not a description
> of the hardware.

AFAICT the issue is the fact that while HDLCD could scan out the alternate
lines with a bit of a convoluted hack, there is no way to tell TDA19988
to generate the interlaced timings. And no, I'm not advocating introducing
a DT property as this is a runtime mode, depending on the resolution
selected by userspace.

> 
> > Please advise on what other steps I can take to try to reproduce this.
> 
> I guess if you've tried and failed to reproduce it, there is something
> very specific to my setup which I can't describe.
> 
> > P.S: What revision of Juno do you have? Any chance you can capture the start
> > of the boot process where the firmware component prints the version numbers?
> 
> All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
> (he spent _all_ of last Tuesday logged in to one of my systems trying
> to upgrade the firmware) is now running the Linaro 16.10 firmware.
> Sudeep says that my hardware is a very early revision which went out
> the door without being properly calibrated.

:) That is what you get for having special access to early samples of hardware :)

Might be worth asking your ARM contacts if a swap with an R2 is possible.

But, yes, my tests were also run on a Juno R0 (HBI0282B is just the R0 code)
and mine I'm pretty sure is earlier build than yours (board #13 no less).

> 
> Whether that has any bearing on the reproducability of this or not, I've
> no idea.

The one factor that could affect it is the capability of the SCP firmware
to generate the exact pixel clock for your 1080p mode. If it doesn't, then
restoring the old mode might lead to an incorrect synchronisation with the
TDA chip. Current (less than 1.5 years old I guess) SCP firmware has that
sorted via an hdlcd.dat file that pre-calculates a lot of common pixel clock
frequencies).

Best regards,
Liviu

> 
> If you want to see the boot messages, head to my autobuilder status page
> and look at the juno-kvm entries - they contain all the boot messages
> from initial power up of the juno.  I'll send you a link in private
> mail so googlebot doesn't end up hammering on it after it expires.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:32:32PM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 01:50:31PM +0000, Liviu Dudau wrote:
> > > > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > > > remove, I've added it because I was getting a ->disable() hook call
> > > > > > before any ->enable() was called at startup time. I need to revisit
> > > > > > this as I remember Daniel was commenting that this was not needed.
> > > > > 
> > > > > Removing that test results in:
> > > > > 
> > > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > > > 
> > > > > and the kernel hanging, seemingly in an IRQs-off region.
> > > > 
> > > > Right, I need to sort this one out. Are you doing these tests out of
> > > > some tagged branch that I can get in sync with?
> > 
> > Hi Russell,
> > 
> > > 
> > > No, not yet, and some of the changes I have are rather hacky.
> > > 
> > > I do always build my full tree of patches (which is currently running at
> > > around 320 patches at the moment) but I never share that entire patch
> > > set.  However, none of those touch i2c (apart from the ones I've recently
> > > posted) and the only patches touching hdlcd are those I've posted so far.
> > > 
> > > Most of the problems I'm finding are through trying basic stuff - I'm not
> > > doing anything special or unusual to find them, at the moment quite
> > > literally just starting Xorg up and shutting it down.  For example, the
> > > above was caused by logging in on serial, running:
> > > 
> > > 	Xorg -terminate -verbose
> > > 
> > > and then hitting ^C.  (I have lxdm disabled so systemd boots to VT login
> > > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > > up when the machine is booting for its nightly KVM boot tests.)
> > > 
> > > I'm afraid that when I try someone elses code, I have a tendency to find
> > > loads of seemingly trivial bugs when I try putting it through some basic
> > > tests.
> > 
> > I'm not being able to reproduce your bug conditions. I'm running the following
> > setup when testing:
> > 
> > - mainline v4.9-rc6
> > - edited the juno-base.dtsi file to disable the hdlcd@7f600000 and
> >   hdmi-transmitter@70 nodes to remove the second HDMI output from the test.
> > - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> > - modified the hdlcd_crtc.c file with the following patch:
> > 
> > -8<-----------------------------------------------------------------------
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 48019ae..656dc43 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> >  {
> >  	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >  
> > -	if (!crtc->state->active)
> > -		return;
> > -
> > +	drm_crtc_vblank_off(crtc);
> 
> Don't you need a drm_crtc_vblank_on() call in the enable function?

I do, thanks for calling me on that!

> 
> >  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> >  	clk_disable_unprepare(hdlcd->clk);
> >  }
> > ->8-----------------------------------------------------------------------
> > 
> > That takes care of the pxlclk refcounting issue you were seeing. I've started
> > Xorg several times (and yes, I do see EDID checksum error every now and then,
> > specially when running xrandr). When closing down Xorg I get back the framebuffer
> > console with the login prompt and no image shifting.
> 
> For me, the image shift was 100% reproducable.  With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:

OK, so I'll take it that you did not also use your patch to fix the base plane
calculations, or was that included as well in your stack?

> 
> [   76.869136] hdlcd_crtc_disable: active 0
> [   76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
> [   85.262451] hdlcd_crtc_disable: active 0
> [   85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
> [   92.658038] hdlcd_crtc_disable: active 0
> [   92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
> [   97.805205] hdlcd_crtc_disable: active 0
> [   97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [   97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [   97.834423] hdlcd_crtc_enable: active 1 cmd 00000000
> 
> > My monitor is a TV that
> > reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> > propertly with each other to be able to set the interlaced mode correctly, so
> > I've had to disable support for interlacing mode in tda998x_drv.c and now the
> > preferred mode that gets picked up is 1920x1200@60Hz.
> 
> That's more of a generic DRM issue - the CRTC layer doesn't get a
> look-in when a connector parses the modes supplied from the display,
> so there's no real way for the CRTC layer to apply any kind of
> limitations to the available modes, except when a mode is attempted
> to be set.
> 
> I don't want to see an "interlace" DT property introduced for the
> TDA998x, because that's the wrong approach - it would be adding a
> property for the needs of the implementation, and not a description
> of the hardware.

AFAICT the issue is the fact that while HDLCD could scan out the alternate
lines with a bit of a convoluted hack, there is no way to tell TDA19988
to generate the interlaced timings. And no, I'm not advocating introducing
a DT property as this is a runtime mode, depending on the resolution
selected by userspace.

> 
> > Please advise on what other steps I can take to try to reproduce this.
> 
> I guess if you've tried and failed to reproduce it, there is something
> very specific to my setup which I can't describe.
> 
> > P.S: What revision of Juno do you have? Any chance you can capture the start
> > of the boot process where the firmware component prints the version numbers?
> 
> All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
> (he spent _all_ of last Tuesday logged in to one of my systems trying
> to upgrade the firmware) is now running the Linaro 16.10 firmware.
> Sudeep says that my hardware is a very early revision which went out
> the door without being properly calibrated.

:) That is what you get for having special access to early samples of hardware :)

Might be worth asking your ARM contacts if a swap with an R2 is possible.

But, yes, my tests were also run on a Juno R0 (HBI0282B is just the R0 code)
and mine I'm pretty sure is earlier build than yours (board #13 no less).

> 
> Whether that has any bearing on the reproducability of this or not, I've
> no idea.

The one factor that could affect it is the capability of the SCP firmware
to generate the exact pixel clock for your 1080p mode. If it doesn't, then
restoring the old mode might lead to an incorrect synchronisation with the
TDA chip. Current (less than 1.5 years old I guess) SCP firmware has that
sorted via an hdlcd.dat file that pre-calculates a lot of common pixel clock
frequencies).

Best regards,
Liviu

> 
> If you want to see the boot messages, head to my autobuilder status page
> and look at the juno-kvm entries - they contain all the boot messages
> from initial power up of the juno.  I'll send you a link in private
> mail so googlebot doesn't end up hammering on it after it expires.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 06:16:16PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable.  With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave correctly - I can alternately switch between 1920x1080 and
> > 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> > the right thing is happening wrt disabling the controller:
> 
> Here's my version of your patch:

Thanks! I'll add it to my tree and see if David Airlie is happy to push it
this late into the release cycle. Otherwise it is going to end up in linux-next
quickly and then in drm-next before v4.10.

> 
> 8<=============
> From: Russell King <rmk+kernel@armlinux.org.uk>
> Subject: [PATCH] drm/arm: hdlcd: fix plane base address update
> 
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region.  (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
> 
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.
> 
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.
> Further debugging shows that we try to update the controller
> configuration while enabled.
> 
> Alwys ensure that the HDLCD is disabled prior to updating the
> controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
> so that DRM knows whether it can expect vblank interrupts.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index c239616f5334..9d683be2e5d3 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
>  	clk_prepare_enable(hdlcd->clk);
>  	hdlcd_crtc_mode_set_nofb(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> +	drm_crtc_vblank_on(crtc);
>  }
>  
>  static void hdlcd_crtc_disable(struct drm_crtc *crtc)
>  {
>  	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>  
> -	if (!crtc->state->active)
> -		return;
> -
> +	drm_crtc_vblank_off(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
>  	clk_disable_unprepare(hdlcd->clk);
>  }
> -- 
> 2.7.4
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

On Mon, Nov 21, 2016 at 06:16:16PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable.  With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave correctly - I can alternately switch between 1920x1080 and
> > 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> > the right thing is happening wrt disabling the controller:
> 
> Here's my version of your patch:

Thanks! I'll add it to my tree and see if David Airlie is happy to push it
this late into the release cycle. Otherwise it is going to end up in linux-next
quickly and then in drm-next before v4.10.

> 
> 8<=============
> From: Russell King <rmk+kernel@armlinux.org.uk>
> Subject: [PATCH] drm/arm: hdlcd: fix plane base address update
> 
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region.  (No sync bars are visible.)
> The timings are correct, it behaves as if the start address has been
> shifted many pixels _into_ the framebuffer.
> 
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.
> 
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.
> Further debugging shows that we try to update the controller
> configuration while enabled.
> 
> Alwys ensure that the HDLCD is disabled prior to updating the
> controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
> so that DRM knows whether it can expect vblank interrupts.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index c239616f5334..9d683be2e5d3 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
>  	clk_prepare_enable(hdlcd->clk);
>  	hdlcd_crtc_mode_set_nofb(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> +	drm_crtc_vblank_on(crtc);
>  }
>  
>  static void hdlcd_crtc_disable(struct drm_crtc *crtc)
>  {
>  	struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>  
> -	if (!crtc->state->active)
> -		return;
> -
> +	drm_crtc_vblank_off(crtc);
>  	hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
>  	clk_disable_unprepare(hdlcd->clk);
>  }
> -- 
> 2.7.4
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 06:23:24PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable.  With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave correctly - I can alternately switch between 1920x1080 and
> > 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> > the right thing is happening wrt disabling the controller:
> 
> OK, so I'll take it that you did not also use your patch to fix the base
> plane calculations, or was that included as well in your stack?

It was before that patch - so it was using crtc_x and crtc_y.  However,
I can guarantee that those were both zero (as I've previously
described.)

> > That's more of a generic DRM issue - the CRTC layer doesn't get a
> > look-in when a connector parses the modes supplied from the display,
> > so there's no real way for the CRTC layer to apply any kind of
> > limitations to the available modes, except when a mode is attempted
> > to be set.
> > 
> > I don't want to see an "interlace" DT property introduced for the
> > TDA998x, because that's the wrong approach - it would be adding a
> > property for the needs of the implementation, and not a description
> > of the hardware.
> 
> AFAICT the issue is the fact that while HDLCD could scan out the alternate
> lines with a bit of a convoluted hack, there is no way to tell TDA19988
> to generate the interlaced timings. And no, I'm not advocating introducing
> a DT property as this is a runtime mode, depending on the resolution
> selected by userspace.

The TDA998x doesn't "generate" the timings.  They come from the input
to it, the TDA998x merely tracks where it is within the frame, so it
knows where it can place things like the infoframes and other data.

So, the responsibility for generating the interlaced timings is with
the CRTC.

That means the CRTC needs to not only scan out alternate lines (which
is the easy bit - setting the pitch to twice the value) but it also
needs to be able to adjust the timing of the vertical sync by half
a line.  The HDLCD from what I can see does not support that, the
overall system does not support for interlaced modes.

> > Whether that has any bearing on the reproducability of this or not, I've
> > no idea.
> 
> The one factor that could affect it is the capability of the SCP firmware
> to generate the exact pixel clock for your 1080p mode. If it doesn't, then
> restoring the old mode might lead to an incorrect synchronisation with the
> TDA chip. Current (less than 1.5 years old I guess) SCP firmware has that
> sorted via an hdlcd.dat file that pre-calculates a lot of common pixel clock
> frequencies).

The TDA998x takes the sync signals itself to synchronise with the CRTC,
and the pixel clock had better be synchronous with the data being closed
out of the CRTC otherwise its going to be in violation of the RGB data
setup and hold timings - which will cause random colour errors.

That isn't what's going on here - the image is rock stable, it's just
shifted.

I tried inverting the sync signals from the CRTC to the TDA998x, and
that shifts the display (as I expect, because the TDA998x synchronises
on the transition of the sync signals not on their absolute values) and
at that point I get the black sync bars appearing - again as expected.

Same kind of effect if I swap the horizontal front and back porches.

Of course, adjusting such things necessitates the TDA998x to re-lock
to the CRTC each time something like that changes, and the image
shift remains.

As I described originally, the _only_ two things that solved the image
shift was (a) shifting the framebuffer start address earlier than it
should be, or (b) disabling the CRTC and re-enabling the CRTC.  Both
of those were tried using devmem2 in userspace with no patches to the
HDLCD code over v4.9-rc5.

The only patches that would be in effect are my TDA998x patch stack
(which you've already tested), the i2c-designware patches to sort that
crappy thing out, and a dirty patch to the TDA998x code to read the
EDID in 16 byte chunks [*], so that the i2c-designware crappage never
causes a problem.

* - I'm not submitting this patch, because while it may solve the
    EDID reading issue on Juno, it's putting intimate knowledge of
    i2c-designware into the TDA998x driver - it's a hack around the
    problem, it's not a real fix.  It's possible that there are other
    i2c-designware crappages out there which have even smaller FIFOs
    which would need us to read in even smaller chunks for reliability.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Nov 21, 2016 at 06:23:24PM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable.  With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave correctly - I can alternately switch between 1920x1080 and
> > 1280x1024 and it behaves correctly.  Indeed, my debug prints show that
> > the right thing is happening wrt disabling the controller:
> 
> OK, so I'll take it that you did not also use your patch to fix the base
> plane calculations, or was that included as well in your stack?

It was before that patch - so it was using crtc_x and crtc_y.  However,
I can guarantee that those were both zero (as I've previously
described.)

> > That's more of a generic DRM issue - the CRTC layer doesn't get a
> > look-in when a connector parses the modes supplied from the display,
> > so there's no real way for the CRTC layer to apply any kind of
> > limitations to the available modes, except when a mode is attempted
> > to be set.
> > 
> > I don't want to see an "interlace" DT property introduced for the
> > TDA998x, because that's the wrong approach - it would be adding a
> > property for the needs of the implementation, and not a description
> > of the hardware.
> 
> AFAICT the issue is the fact that while HDLCD could scan out the alternate
> lines with a bit of a convoluted hack, there is no way to tell TDA19988
> to generate the interlaced timings. And no, I'm not advocating introducing
> a DT property as this is a runtime mode, depending on the resolution
> selected by userspace.

The TDA998x doesn't "generate" the timings.  They come from the input
to it, the TDA998x merely tracks where it is within the frame, so it
knows where it can place things like the infoframes and other data.

So, the responsibility for generating the interlaced timings is with
the CRTC.

That means the CRTC needs to not only scan out alternate lines (which
is the easy bit - setting the pitch to twice the value) but it also
needs to be able to adjust the timing of the vertical sync by half
a line.  The HDLCD from what I can see does not support that, the
overall system does not support for interlaced modes.

> > Whether that has any bearing on the reproducability of this or not, I've
> > no idea.
> 
> The one factor that could affect it is the capability of the SCP firmware
> to generate the exact pixel clock for your 1080p mode. If it doesn't, then
> restoring the old mode might lead to an incorrect synchronisation with the
> TDA chip. Current (less than 1.5 years old I guess) SCP firmware has that
> sorted via an hdlcd.dat file that pre-calculates a lot of common pixel clock
> frequencies).

The TDA998x takes the sync signals itself to synchronise with the CRTC,
and the pixel clock had better be synchronous with the data being closed
out of the CRTC otherwise its going to be in violation of the RGB data
setup and hold timings - which will cause random colour errors.

That isn't what's going on here - the image is rock stable, it's just
shifted.

I tried inverting the sync signals from the CRTC to the TDA998x, and
that shifts the display (as I expect, because the TDA998x synchronises
on the transition of the sync signals not on their absolute values) and
at that point I get the black sync bars appearing - again as expected.

Same kind of effect if I swap the horizontal front and back porches.

Of course, adjusting such things necessitates the TDA998x to re-lock
to the CRTC each time something like that changes, and the image
shift remains.

As I described originally, the _only_ two things that solved the image
shift was (a) shifting the framebuffer start address earlier than it
should be, or (b) disabling the CRTC and re-enabling the CRTC.  Both
of those were tried using devmem2 in userspace with no patches to the
HDLCD code over v4.9-rc5.

The only patches that would be in effect are my TDA998x patch stack
(which you've already tested), the i2c-designware patches to sort that
crappy thing out, and a dirty patch to the TDA998x code to read the
EDID in 16 byte chunks [*], so that the i2c-designware crappage never
causes a problem.

* - I'm not submitting this patch, because while it may solve the
    EDID reading issue on Juno, it's putting intimate knowledge of
    i2c-designware into the TDA998x driver - it's a hack around the
    problem, it's not a real fix.  It's possible that there are other
    i2c-designware crappages out there which have even smaller FIFOs
    which would need us to read in even smaller chunks for reliability.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Daniel Vetter]

On Mon, Nov 21, 2016 at 02:55:28PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 02:30:53PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > remove, I've added it because I was getting a ->disable() hook call
> > > > before any ->enable() was called at startup time. I need to revisit
> > > > this as I remember Daniel was commenting that this was not needed.
> > > 
> > > Removing that test results in:
> > > 
> > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > 
> > > and the kernel hanging, seemingly in an IRQs-off region.
> > 
> > Annoyingly, enabling DRM debug prevents the kernel hanging...
> 
> I've been trying to trace through what's happening with this flip_done
> stuff, but I'm finding it _extremely_ difficult to follow the atomic
> code.
> 
> (Sorry, I'm going to go over my usual 72 column limit for this due to
> the damn long DRM function names.)
> 
> I can see that drm_atomic_helper_commit() calls drm_atomic_helper_setup_commit()
> which sets up commit->flip_done for each CRTC, and sets up an event for
> each.
> 
> drm_atomic_helper_commit() continues on to eventually call drm_atomic_helper_swap_state()
> which then swaps the state for the CRTCs, but then ends up dropping
> the event reference:
> 
> 	state->crtcs[i].commit->event = NULL;
> 
> What I can't see is why this isn't a leaked pointer - I don't see
> anything inbetween taking charge of that structure.  The _commit_
> hasn't been swapped from what I can see, it's just state->crtcs[i].state
> that have been swapped.

The event is also stored in crtc_state->event, which after swap_states
land in drm_crtc->state->event, which is the place drivers are supposed to
pick it up from for delivery.

> So I can't see who's responsible for generating this event, or how the
> backend DRM drivers get to know about this event, and that they should
> complete the flip.
> 
> What I also don't get is why DRM is wanting to wait for a flip event
> when we're disabling the CRTC.  None of this makes sense to me, like
> much of the atomic modeset code...

The DRM event has two uses:
- high-precision timestamp for when the new frame starts displaying.
- confirmation that the old buffers are no longer being used by the hw.
  This is used on Android's drm_hwcomposer in the new hwc2 mode.

Note that the crtc_state->event has 3 uses in total, all hidden behind the
abstraction:
- flip_done, for the atomic helpers
- drm event, for current userspace (also needed to emulate legacy flips)
- and out-fences, needed by android.

The trouble with ->event delivery was that many drivers didn't bother to
implement this at all, since driver submitters never even tested
pageflippping. And for those maintainers that did test pageflipping, they
only ever tested the legacy page_flip paths, which e.g. doesn't ever ask
for an event when disabling the CRTC (since you can't do that). But atomic
allows all this, and review wasn't enough to fight the influx of bad
drivers. Hence I opted to make the nonblocking support in the atomic
helpers enforce this part of the abi contract, even for blocking modesets.
If you're stuck on a flip_done, then your driver doesn't send out events
when disabling the CRTC.

All the waits have a 10s timeout, and none of them are in atomic contexts,
so no idea why this takes down your box. I suspect it's something
unrelated.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [BUG] hdlcd gets confused about base address

[Daniel Vetter]

On Mon, Nov 21, 2016 at 02:55:28PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 02:30:53PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > > remove, I've added it because I was getting a ->disable() hook call
> > > > before any ->enable() was called at startup time. I need to revisit
> > > > this as I remember Daniel was commenting that this was not needed.
> > > 
> > > Removing that test results in:
> > > 
> > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > 
> > > and the kernel hanging, seemingly in an IRQs-off region.
> > 
> > Annoyingly, enabling DRM debug prevents the kernel hanging...
> 
> I've been trying to trace through what's happening with this flip_done
> stuff, but I'm finding it _extremely_ difficult to follow the atomic
> code.
> 
> (Sorry, I'm going to go over my usual 72 column limit for this due to
> the damn long DRM function names.)
> 
> I can see that drm_atomic_helper_commit() calls drm_atomic_helper_setup_commit()
> which sets up commit->flip_done for each CRTC, and sets up an event for
> each.
> 
> drm_atomic_helper_commit() continues on to eventually call drm_atomic_helper_swap_state()
> which then swaps the state for the CRTCs, but then ends up dropping
> the event reference:
> 
> 	state->crtcs[i].commit->event = NULL;
> 
> What I can't see is why this isn't a leaked pointer - I don't see
> anything inbetween taking charge of that structure.  The _commit_
> hasn't been swapped from what I can see, it's just state->crtcs[i].state
> that have been swapped.

The event is also stored in crtc_state->event, which after swap_states
land in drm_crtc->state->event, which is the place drivers are supposed to
pick it up from for delivery.

> So I can't see who's responsible for generating this event, or how the
> backend DRM drivers get to know about this event, and that they should
> complete the flip.
> 
> What I also don't get is why DRM is wanting to wait for a flip event
> when we're disabling the CRTC.  None of this makes sense to me, like
> much of the atomic modeset code...

The DRM event has two uses:
- high-precision timestamp for when the new frame starts displaying.
- confirmation that the old buffers are no longer being used by the hw.
  This is used on Android's drm_hwcomposer in the new hwc2 mode.

Note that the crtc_state->event has 3 uses in total, all hidden behind the
abstraction:
- flip_done, for the atomic helpers
- drm event, for current userspace (also needed to emulate legacy flips)
- and out-fences, needed by android.

The trouble with ->event delivery was that many drivers didn't bother to
implement this at all, since driver submitters never even tested
pageflippping. And for those maintainers that did test pageflipping, they
only ever tested the legacy page_flip paths, which e.g. doesn't ever ask
for an event when disabling the CRTC (since you can't do that). But atomic
allows all this, and review wasn't enough to fight the influx of bad
drivers. Hence I opted to make the nonblocking support in the atomic
helpers enforce this part of the abi contract, even for blocking modesets.
If you're stuck on a flip_done, then your driver doesn't send out events
when disabling the CRTC.

All the waits have a 10s timeout, and none of them are in atomic contexts,
so no idea why this takes down your box. I suspect it's something
unrelated.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
> Surely this should be using src_[xy] (which are the position in the
> source - iow, memory, and not crtc_[xy] which is the position on the
> CRTC displayed window.  To put it another way, the src_* define the
> region of the source material that is mapped onto a rectangular area
> on the display defined by crtc_*.

This problem still exists...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
> Surely this should be using src_[xy] (which are the position in the
> source - iow, memory, and not crtc_[xy] which is the position on the
> CRTC displayed window.  To put it another way, the src_* define the
> region of the source material that is mapped onto a rectangular area
> on the display defined by crtc_*.

This problem still exists...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

Hi Russell,

On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > Something I also noticed is this:
> > 
> >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> >                 plane->state->crtc_x * bpp / 8;
> > 
> > Surely this should be using src_[xy] (which are the position in the
> > source - iow, memory, and not crtc_[xy] which is the position on the
> > CRTC displayed window.  To put it another way, the src_* define the
> > region of the source material that is mapped onto a rectangular area
> > on the display defined by crtc_*.
> 
> This problem still exists...

Sorry, looks like this fell through the cracks of us trying to fix the
other issues you were seeing. I'm attaching a patch, please let me know
if this works for you.

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-arm-hdlcd-Fix-the-calculation-of-scanout-start-addre.patch
Type: text/x-diff
Size: 1635 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170220/c264b8a0/attachment.bin>

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

Hi Russell,

On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > Something I also noticed is this:
> > 
> >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> >                 plane->state->crtc_x * bpp / 8;
> > 
> > Surely this should be using src_[xy] (which are the position in the
> > source - iow, memory, and not crtc_[xy] which is the position on the
> > CRTC displayed window.  To put it another way, the src_* define the
> > region of the source material that is mapped onto a rectangular area
> > on the display defined by crtc_*.
> 
> This problem still exists...

Sorry, looks like this fell through the cracks of us trying to fix the
other issues you were seeing. I'm attaching a patch, please let me know
if this works for you.

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[-- Attachment #2: 0001-arm-hdlcd-Fix-the-calculation-of-scanout-start-addre.patch --]
[-- Type: text/x-diff, Size: 1635 bytes --]

>From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001
From: Liviu Dudau <Liviu.Dudau@arm.com>
Date: Mon, 20 Feb 2017 17:44:42 +0000
Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address

The framebuffer start address uses the CRTC's x,y position rather
than the source framebuffer's. Fix that.

Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 798a3cc480a2..4c1ab73d9e07 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
 	struct drm_framebuffer *fb = plane->state->fb;
 	struct hdlcd_drm_private *hdlcd;
 	struct drm_gem_cma_object *gem;
-	u32 src_w, src_h, dest_w, dest_h;
+	u32 src_x, src_y, dest_w, dest_h;
 	dma_addr_t scanout_start;
 
 	if (!fb)
 		return;
 
-	src_w = plane->state->src_w >> 16;
-	src_h = plane->state->src_h >> 16;
+	src_x = plane->state->src_x >> 16;
+	src_y = plane->state->src_y >> 16;
 	dest_w = plane->state->crtc_w;
 	dest_h = plane->state->crtc_h;
 	gem = drm_fb_cma_get_gem_obj(fb, 0);
 	scanout_start = gem->paddr + fb->offsets[0] +
-		plane->state->crtc_y * fb->pitches[0] +
-		plane->state->crtc_x *
-		fb->format->cpp[0];
+		src_y * fb->pitches[0] +
+		src_x *	fb->format->cpp[0];
 
 	hdlcd = plane->dev->dev_private;
 	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
-- 
2.11.0


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

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

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> Sorry, looks like this fell through the cracks of us trying to fix the
> other issues you were seeing. I'm attaching a patch, please let me know
> if this works for you.

I don't have time to test right now, but it looks similar to what I
had.

Only nit is - is dest_w used apart from being written once?  (That's
probably something for a separate patch.)

There's also the issue which Daniel Vetter followed up with to my
comment about this calculation - the plane state validation is
insufficient, and it would be a good idea if it used
drm_plane_helper_check_state().

Also, I've since noticed that it doesn't check state->rotation, and
I don't think this driver supports any rotation options.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> Sorry, looks like this fell through the cracks of us trying to fix the
> other issues you were seeing. I'm attaching a patch, please let me know
> if this works for you.

I don't have time to test right now, but it looks similar to what I
had.

Only nit is - is dest_w used apart from being written once?  (That's
probably something for a separate patch.)

There's also the issue which Daniel Vetter followed up with to my
comment about this calculation - the plane state validation is
insufficient, and it would be a good idea if it used
drm_plane_helper_check_state().

Also, I've since noticed that it doesn't check state->rotation, and
I don't think this driver supports any rotation options.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Ville Syrjälä]

On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> Hi Russell,
> 
> On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > Something I also noticed is this:
> > > 
> > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > >                 plane->state->crtc_x * bpp / 8;
> > > 
> > > Surely this should be using src_[xy] (which are the position in the
> > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > CRTC displayed window.  To put it another way, the src_* define the
> > > region of the source material that is mapped onto a rectangular area
> > > on the display defined by crtc_*.
> > 
> > This problem still exists...
> 
> Sorry, looks like this fell through the cracks of us trying to fix the
> other issues you were seeing. I'm attaching a patch, please let me know
> if this works for you.
> 
> Best regards,
> Liviu
> 
> > 
> > -- 
> > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > according to speedtest.net.
> 
> -- 
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ?\_(?)_/?

> >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001
> From: Liviu Dudau <Liviu.Dudau@arm.com>
> Date: Mon, 20 Feb 2017 17:44:42 +0000
> Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address
> 
> The framebuffer start address uses the CRTC's x,y position rather
> than the source framebuffer's. Fix that.
> 
> Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 798a3cc480a2..4c1ab73d9e07 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
>  	struct drm_framebuffer *fb = plane->state->fb;
>  	struct hdlcd_drm_private *hdlcd;
>  	struct drm_gem_cma_object *gem;
> -	u32 src_w, src_h, dest_w, dest_h;
> +	u32 src_x, src_y, dest_w, dest_h;
>  	dma_addr_t scanout_start;
>  
>  	if (!fb)
>  		return;
>  
> -	src_w = plane->state->src_w >> 16;
> -	src_h = plane->state->src_h >> 16;
> +	src_x = plane->state->src_x >> 16;
> +	src_y = plane->state->src_y >> 16;

This stuff should be using the clipped coordinates, not the user
coordinates. And it doesn't look like this guy is even calling the
clip helper thing.

malidp seems to be calling that thing, but it still doesn't
manage to program the hw with the right coordinates from what
I can see.

/me feels a bit like a broken record...

>  	dest_w = plane->state->crtc_w;
>  	dest_h = plane->state->crtc_h;
>  	gem = drm_fb_cma_get_gem_obj(fb, 0);
>  	scanout_start = gem->paddr + fb->offsets[0] +
> -		plane->state->crtc_y * fb->pitches[0] +
> -		plane->state->crtc_x *
> -		fb->format->cpp[0];
> +		src_y * fb->pitches[0] +
> +		src_x *	fb->format->cpp[0];
>  
>  	hdlcd = plane->dev->dev_private;
>  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
> -- 
> 2.11.0
> 

> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Ville Syrj?l?
Intel OTC

Re: [BUG] hdlcd gets confused about base address

[Ville Syrjälä]

On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> Hi Russell,
> 
> On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > Something I also noticed is this:
> > > 
> > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > >                 plane->state->crtc_x * bpp / 8;
> > > 
> > > Surely this should be using src_[xy] (which are the position in the
> > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > CRTC displayed window.  To put it another way, the src_* define the
> > > region of the source material that is mapped onto a rectangular area
> > > on the display defined by crtc_*.
> > 
> > This problem still exists...
> 
> Sorry, looks like this fell through the cracks of us trying to fix the
> other issues you were seeing. I'm attaching a patch, please let me know
> if this works for you.
> 
> Best regards,
> Liviu
> 
> > 
> > -- 
> > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > according to speedtest.net.
> 
> -- 
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ¯\_(ツ)_/¯

> >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001
> From: Liviu Dudau <Liviu.Dudau@arm.com>
> Date: Mon, 20 Feb 2017 17:44:42 +0000
> Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address
> 
> The framebuffer start address uses the CRTC's x,y position rather
> than the source framebuffer's. Fix that.
> 
> Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 798a3cc480a2..4c1ab73d9e07 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
>  	struct drm_framebuffer *fb = plane->state->fb;
>  	struct hdlcd_drm_private *hdlcd;
>  	struct drm_gem_cma_object *gem;
> -	u32 src_w, src_h, dest_w, dest_h;
> +	u32 src_x, src_y, dest_w, dest_h;
>  	dma_addr_t scanout_start;
>  
>  	if (!fb)
>  		return;
>  
> -	src_w = plane->state->src_w >> 16;
> -	src_h = plane->state->src_h >> 16;
> +	src_x = plane->state->src_x >> 16;
> +	src_y = plane->state->src_y >> 16;

This stuff should be using the clipped coordinates, not the user
coordinates. And it doesn't look like this guy is even calling the
clip helper thing.

malidp seems to be calling that thing, but it still doesn't
manage to program the hw with the right coordinates from what
I can see.

/me feels a bit like a broken record...

>  	dest_w = plane->state->crtc_w;
>  	dest_h = plane->state->crtc_h;
>  	gem = drm_fb_cma_get_gem_obj(fb, 0);
>  	scanout_start = gem->paddr + fb->offsets[0] +
> -		plane->state->crtc_y * fb->pitches[0] +
> -		plane->state->crtc_x *
> -		fb->format->cpp[0];
> +		src_y * fb->pitches[0] +
> +		src_x *	fb->format->cpp[0];
>  
>  	hdlcd = plane->dev->dev_private;
>  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
> -- 
> 2.11.0
> 

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


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

[BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrj?l? wrote:
> This stuff should be using the clipped coordinates, not the user
> coordinates. And it doesn't look like this guy is even calling the
> clip helper thing.
> 
> malidp seems to be calling that thing, but it still doesn't
> manage to program the hw with the right coordinates from what
> I can see.
> 
> /me feels a bit like a broken record...

If you mean drm_plane_helper_check_state(), then...

$ grep drm_plane_helper_check_state Documentation/gpu/ -r

So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's
the following, and I think this really isn't helping people understand
what's required:

 * This helper library has two parts. The first part has support to implement
 * primary plane support on top of the normal CRTC configuration interface.
 * Since the legacy ->set_config interface ties the primary plane together with
 * the CRTC state this does not allow userspace to disable the primary plane
 * itself.  To avoid too much duplicated code use
 * drm_plane_helper_check_update() which can be used to enforce the same
 * restrictions as primary planes had thus. The default primary plane only
 * expose XRBG8888 and ARGB8888 as valid pixel formats for the attached
 * framebuffer.
 *
 * Drivers are highly recommended to implement proper support for primary
 * planes, and newly merged drivers must not rely upon these transitional
 * helpers.

Which functions are defined as "these transitional helpers" - the above
is rather ambiguous.  Is drm_plane_helper_check_state() a "transitional
helper" or is it not?  (It probably isn't, but the documentation does not
make that clear.)

It then goes on to:

 * The second part also implements transitional helpers which allow drivers to

So maybe the second paragraph needs to be moved after this line to
remove the confusion?

If you find that you're repeating something to many people, it's always
a good idea to re-read the documentation that's supposed to be giving
people guidance.

Now, when you say that we're supposed to program "clipped coordinates"
maybe you can give a hint what those are and where they come from?
Is that the vaguely documented "clip" parameter in
drm_plane_helper_check_state() ?

 * @clip: integer clipping coordinates

If it is, that doesn't really describe it, and neither does the
description of what the function does, nor what it returns:

 * Checks that a desired plane update is valid.  Drivers that provide
 * their own plane handling rather than helper-provided implementations may
 * still wish to call this function to avoid duplication of error checking
 * code.
 *
 * RETURNS:
 * Zero if update appears valid, error code on failure

So, some improvement there could go a long way towards eliminating
some of these issues...

Atomic modeset is hideously complex... having poor documentation doesn't
help.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [BUG] hdlcd gets confused about base address

[Russell King - ARM Linux]

On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> This stuff should be using the clipped coordinates, not the user
> coordinates. And it doesn't look like this guy is even calling the
> clip helper thing.
> 
> malidp seems to be calling that thing, but it still doesn't
> manage to program the hw with the right coordinates from what
> I can see.
> 
> /me feels a bit like a broken record...

If you mean drm_plane_helper_check_state(), then...

$ grep drm_plane_helper_check_state Documentation/gpu/ -r

So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's
the following, and I think this really isn't helping people understand
what's required:

 * This helper library has two parts. The first part has support to implement
 * primary plane support on top of the normal CRTC configuration interface.
 * Since the legacy ->set_config interface ties the primary plane together with
 * the CRTC state this does not allow userspace to disable the primary plane
 * itself.  To avoid too much duplicated code use
 * drm_plane_helper_check_update() which can be used to enforce the same
 * restrictions as primary planes had thus. The default primary plane only
 * expose XRBG8888 and ARGB8888 as valid pixel formats for the attached
 * framebuffer.
 *
 * Drivers are highly recommended to implement proper support for primary
 * planes, and newly merged drivers must not rely upon these transitional
 * helpers.

Which functions are defined as "these transitional helpers" - the above
is rather ambiguous.  Is drm_plane_helper_check_state() a "transitional
helper" or is it not?  (It probably isn't, but the documentation does not
make that clear.)

It then goes on to:

 * The second part also implements transitional helpers which allow drivers to

So maybe the second paragraph needs to be moved after this line to
remove the confusion?

If you find that you're repeating something to many people, it's always
a good idea to re-read the documentation that's supposed to be giving
people guidance.

Now, when you say that we're supposed to program "clipped coordinates"
maybe you can give a hint what those are and where they come from?
Is that the vaguely documented "clip" parameter in
drm_plane_helper_check_state() ?

 * @clip: integer clipping coordinates

If it is, that doesn't really describe it, and neither does the
description of what the function does, nor what it returns:

 * Checks that a desired plane update is valid.  Drivers that provide
 * their own plane handling rather than helper-provided implementations may
 * still wish to call this function to avoid duplication of error checking
 * code.
 *
 * RETURNS:
 * Zero if update appears valid, error code on failure

So, some improvement there could go a long way towards eliminating
some of these issues...

Atomic modeset is hideously complex... having poor documentation doesn't
help.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[BUG] hdlcd gets confused about base address

[Liviu Dudau]

Hi Ville,

On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrj?l? wrote:
> On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> > Hi Russell,
> > 
> > On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > > Something I also noticed is this:
> > > > 
> > > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > > >                 plane->state->crtc_x * bpp / 8;
> > > > 
> > > > Surely this should be using src_[xy] (which are the position in the
> > > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > > CRTC displayed window.  To put it another way, the src_* define the
> > > > region of the source material that is mapped onto a rectangular area
> > > > on the display defined by crtc_*.
> > > 
> > > This problem still exists...
> > 
> > Sorry, looks like this fell through the cracks of us trying to fix the
> > other issues you were seeing. I'm attaching a patch, please let me know
> > if this works for you.
> > 
> > Best regards,
> > Liviu
> > 
> > > 
> > > -- 
> > > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > > according to speedtest.net.
> 
> > >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001
> > From: Liviu Dudau <Liviu.Dudau@arm.com>
> > Date: Mon, 20 Feb 2017 17:44:42 +0000
> > Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address
> > 
> > The framebuffer start address uses the CRTC's x,y position rather
> > than the source framebuffer's. Fix that.
> > 
> > Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +++++------
> >  1 file changed, 5 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 798a3cc480a2..4c1ab73d9e07 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
> >  	struct drm_framebuffer *fb = plane->state->fb;
> >  	struct hdlcd_drm_private *hdlcd;
> >  	struct drm_gem_cma_object *gem;
> > -	u32 src_w, src_h, dest_w, dest_h;
> > +	u32 src_x, src_y, dest_w, dest_h;
> >  	dma_addr_t scanout_start;
> >  
> >  	if (!fb)
> >  		return;
> >  
> > -	src_w = plane->state->src_w >> 16;
> > -	src_h = plane->state->src_h >> 16;
> > +	src_x = plane->state->src_x >> 16;
> > +	src_y = plane->state->src_y >> 16;

While still waiting for your reply to Russell's comments ...

> 
> This stuff should be using the clipped coordinates, not the user
> coordinates. And it doesn't look like this guy is even calling the
> clip helper thing.

That's right, the code I believe predates the existence of the clip helper
thing (me reads it as "drm_plane_helper_check_state"), and I have not got
around to update the code here. Before I do that I would like to get a bit
more clarification on what you mean by the clipped coordinates, given
that HDLCD doesn't support dirty buffer updates.

> 
> malidp seems to be calling that thing, but it still doesn't
> manage to program the hw with the right coordinates from what
> I can see.

would like more clarity on what the right coordinates should be.

> 
> /me feels a bit like a broken record...

Sorry, I was not aware of your previous interventions on the subject of "right
coordinates". Could you please point me in the right direction, if it is not
much trouble?

Best regards,
Liviu

> 
> >  	dest_w = plane->state->crtc_w;
> >  	dest_h = plane->state->crtc_h;
> >  	gem = drm_fb_cma_get_gem_obj(fb, 0);
> >  	scanout_start = gem->paddr + fb->offsets[0] +
> > -		plane->state->crtc_y * fb->pitches[0] +
> > -		plane->state->crtc_x *
> > -		fb->format->cpp[0];
> > +		src_y * fb->pitches[0] +
> > +		src_x *	fb->format->cpp[0];
> >  
> >  	hdlcd = plane->dev->dev_private;
> >  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
> > -- 
> > 2.11.0
> > 
> 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> -- 
> Ville Syrj?l?
> Intel OTC

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [BUG] hdlcd gets confused about base address

[Liviu Dudau]

Hi Ville,

On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> > Hi Russell,
> > 
> > On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > > Something I also noticed is this:
> > > > 
> > > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > > >                 plane->state->crtc_x * bpp / 8;
> > > > 
> > > > Surely this should be using src_[xy] (which are the position in the
> > > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > > CRTC displayed window.  To put it another way, the src_* define the
> > > > region of the source material that is mapped onto a rectangular area
> > > > on the display defined by crtc_*.
> > > 
> > > This problem still exists...
> > 
> > Sorry, looks like this fell through the cracks of us trying to fix the
> > other issues you were seeing. I'm attaching a patch, please let me know
> > if this works for you.
> > 
> > Best regards,
> > Liviu
> > 
> > > 
> > > -- 
> > > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > > according to speedtest.net.
> 
> > >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001
> > From: Liviu Dudau <Liviu.Dudau@arm.com>
> > Date: Mon, 20 Feb 2017 17:44:42 +0000
> > Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address
> > 
> > The framebuffer start address uses the CRTC's x,y position rather
> > than the source framebuffer's. Fix that.
> > 
> > Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +++++------
> >  1 file changed, 5 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 798a3cc480a2..4c1ab73d9e07 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
> >  	struct drm_framebuffer *fb = plane->state->fb;
> >  	struct hdlcd_drm_private *hdlcd;
> >  	struct drm_gem_cma_object *gem;
> > -	u32 src_w, src_h, dest_w, dest_h;
> > +	u32 src_x, src_y, dest_w, dest_h;
> >  	dma_addr_t scanout_start;
> >  
> >  	if (!fb)
> >  		return;
> >  
> > -	src_w = plane->state->src_w >> 16;
> > -	src_h = plane->state->src_h >> 16;
> > +	src_x = plane->state->src_x >> 16;
> > +	src_y = plane->state->src_y >> 16;

While still waiting for your reply to Russell's comments ...

> 
> This stuff should be using the clipped coordinates, not the user
> coordinates. And it doesn't look like this guy is even calling the
> clip helper thing.

That's right, the code I believe predates the existence of the clip helper
thing (me reads it as "drm_plane_helper_check_state"), and I have not got
around to update the code here. Before I do that I would like to get a bit
more clarification on what you mean by the clipped coordinates, given
that HDLCD doesn't support dirty buffer updates.

> 
> malidp seems to be calling that thing, but it still doesn't
> manage to program the hw with the right coordinates from what
> I can see.

would like more clarity on what the right coordinates should be.

> 
> /me feels a bit like a broken record...

Sorry, I was not aware of your previous interventions on the subject of "right
coordinates". Could you please point me in the right direction, if it is not
much trouble?

Best regards,
Liviu

> 
> >  	dest_w = plane->state->crtc_w;
> >  	dest_h = plane->state->crtc_h;
> >  	gem = drm_fb_cma_get_gem_obj(fb, 0);
> >  	scanout_start = gem->paddr + fb->offsets[0] +
> > -		plane->state->crtc_y * fb->pitches[0] +
> > -		plane->state->crtc_x *
> > -		fb->format->cpp[0];
> > +		src_y * fb->pitches[0] +
> > +		src_x *	fb->format->cpp[0];
> >  
> >  	hdlcd = plane->dev->dev_private;
> >  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
> > -- 
> > 2.11.0
> > 
> 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] hdlcd gets confused about base address

[Ville Syrjälä]

On Wed, Feb 22, 2017 at 03:15:42PM +0000, Liviu Dudau wrote:
> Hi Ville,
> 
> On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrj?l? wrote:
> > On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> > > Hi Russell,
> > > 
> > > On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > > > Something I also noticed is this:
> > > > > 
> > > > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > > > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > > > >                 plane->state->crtc_x * bpp / 8;
> > > > > 
> > > > > Surely this should be using src_[xy] (which are the position in the
> > > > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > > > CRTC displayed window.  To put it another way, the src_* define the
> > > > > region of the source material that is mapped onto a rectangular area
> > > > > on the display defined by crtc_*.
> > > > 
> > > > This problem still exists...
> > > 
> > > Sorry, looks like this fell through the cracks of us trying to fix the
> > > other issues you were seeing. I'm attaching a patch, please let me know
> > > if this works for you.
> > > 
> > > Best regards,
> > > Liviu
> > > 
> > > > 
> > > > -- 
> > > > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > > > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > > > according to speedtest.net.
> > 
> > > >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001
> > > From: Liviu Dudau <Liviu.Dudau@arm.com>
> > > Date: Mon, 20 Feb 2017 17:44:42 +0000
> > > Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address
> > > 
> > > The framebuffer start address uses the CRTC's x,y position rather
> > > than the source framebuffer's. Fix that.
> > > 
> > > Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > > ---
> > >  drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +++++------
> > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > index 798a3cc480a2..4c1ab73d9e07 100644
> > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
> > >  	struct drm_framebuffer *fb = plane->state->fb;
> > >  	struct hdlcd_drm_private *hdlcd;
> > >  	struct drm_gem_cma_object *gem;
> > > -	u32 src_w, src_h, dest_w, dest_h;
> > > +	u32 src_x, src_y, dest_w, dest_h;
> > >  	dma_addr_t scanout_start;
> > >  
> > >  	if (!fb)
> > >  		return;
> > >  
> > > -	src_w = plane->state->src_w >> 16;
> > > -	src_h = plane->state->src_h >> 16;
> > > +	src_x = plane->state->src_x >> 16;
> > > +	src_y = plane->state->src_y >> 16;
> 
> While still waiting for your reply to Russell's comments ...
> 
> > 
> > This stuff should be using the clipped coordinates, not the user
> > coordinates. And it doesn't look like this guy is even calling the
> > clip helper thing.
> 
> That's right, the code I believe predates the existence of the clip helper
> thing (me reads it as "drm_plane_helper_check_state"), and I have not got
> around to update the code here. Before I do that I would like to get a bit
> more clarification on what you mean by the clipped coordinates, given
> that HDLCD doesn't support dirty buffer updates.

The requirement to handle out of bounds plane coordinates correctly
was always there even before the helper existed. It's just that most
people who wrote new drivers neglected to read the reference code (i915).
Granted, it would be better to have actual documentation, and now that
we have the clipped coordinates in the core state and we have some
helpers we should have a sensible place for said documentation as well.

> 
> > 
> > malidp seems to be calling that thing, but it still doesn't
> > manage to program the hw with the right coordinates from what
> > I can see.
> 
> would like more clarity on what the right coordinates should be.

state->src and state->dst

Well, that's assuming that you can't directly feed negative/large
coordinates to your hardware.

> 
> > 
> > /me feels a bit like a broken record...
> 
> Sorry, I was not aware of your previous interventions on the subject of "right
> coordinates". Could you please point me in the right direction, if it is not
> much trouble?
> 
> Best regards,
> Liviu
> 
> > 
> > >  	dest_w = plane->state->crtc_w;
> > >  	dest_h = plane->state->crtc_h;
> > >  	gem = drm_fb_cma_get_gem_obj(fb, 0);
> > >  	scanout_start = gem->paddr + fb->offsets[0] +
> > > -		plane->state->crtc_y * fb->pitches[0] +
> > > -		plane->state->crtc_x *
> > > -		fb->format->cpp[0];
> > > +		src_y * fb->pitches[0] +
> > > +		src_x *	fb->format->cpp[0];
> > >  
> > >  	hdlcd = plane->dev->dev_private;
> > >  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
> > > -- 
> > > 2.11.0
> > > 
> > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> > -- 
> > Ville Syrj?l?
> > Intel OTC
> 
> -- 
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ?\_(?)_/?

-- 
Ville Syrj?l?
Intel OTC

Re: [BUG] hdlcd gets confused about base address

[Ville Syrjälä]

On Wed, Feb 22, 2017 at 03:15:42PM +0000, Liviu Dudau wrote:
> Hi Ville,
> 
> On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 20, 2017 at 05:53:31PM +0000, Liviu Dudau wrote:
> > > Hi Russell,
> > > 
> > > On Mon, Feb 20, 2017 at 12:16:03PM +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > > > Something I also noticed is this:
> > > > > 
> > > > >         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > > > >                 plane->state->crtc_y * plane->state->fb->pitches[0] +
> > > > >                 plane->state->crtc_x * bpp / 8;
> > > > > 
> > > > > Surely this should be using src_[xy] (which are the position in the
> > > > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > > > CRTC displayed window.  To put it another way, the src_* define the
> > > > > region of the source material that is mapped onto a rectangular area
> > > > > on the display defined by crtc_*.
> > > > 
> > > > This problem still exists...
> > > 
> > > Sorry, looks like this fell through the cracks of us trying to fix the
> > > other issues you were seeing. I'm attaching a patch, please let me know
> > > if this works for you.
> > > 
> > > Best regards,
> > > Liviu
> > > 
> > > > 
> > > > -- 
> > > > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > > > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > > > according to speedtest.net.
> > 
> > > >From a495d262cb91fdeccb00685646ddb71774c18e7e Mon Sep 17 00:00:00 2001
> > > From: Liviu Dudau <Liviu.Dudau@arm.com>
> > > Date: Mon, 20 Feb 2017 17:44:42 +0000
> > > Subject: [PATCH] arm: hdlcd: Fix the calculation of scanout start address
> > > 
> > > The framebuffer start address uses the CRTC's x,y position rather
> > > than the source framebuffer's. Fix that.
> > > 
> > > Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > > ---
> > >  drivers/gpu/drm/arm/hdlcd_crtc.c | 11 +++++------
> > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > index 798a3cc480a2..4c1ab73d9e07 100644
> > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > @@ -244,21 +244,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
> > >  	struct drm_framebuffer *fb = plane->state->fb;
> > >  	struct hdlcd_drm_private *hdlcd;
> > >  	struct drm_gem_cma_object *gem;
> > > -	u32 src_w, src_h, dest_w, dest_h;
> > > +	u32 src_x, src_y, dest_w, dest_h;
> > >  	dma_addr_t scanout_start;
> > >  
> > >  	if (!fb)
> > >  		return;
> > >  
> > > -	src_w = plane->state->src_w >> 16;
> > > -	src_h = plane->state->src_h >> 16;
> > > +	src_x = plane->state->src_x >> 16;
> > > +	src_y = plane->state->src_y >> 16;
> 
> While still waiting for your reply to Russell's comments ...
> 
> > 
> > This stuff should be using the clipped coordinates, not the user
> > coordinates. And it doesn't look like this guy is even calling the
> > clip helper thing.
> 
> That's right, the code I believe predates the existence of the clip helper
> thing (me reads it as "drm_plane_helper_check_state"), and I have not got
> around to update the code here. Before I do that I would like to get a bit
> more clarification on what you mean by the clipped coordinates, given
> that HDLCD doesn't support dirty buffer updates.

The requirement to handle out of bounds plane coordinates correctly
was always there even before the helper existed. It's just that most
people who wrote new drivers neglected to read the reference code (i915).
Granted, it would be better to have actual documentation, and now that
we have the clipped coordinates in the core state and we have some
helpers we should have a sensible place for said documentation as well.

> 
> > 
> > malidp seems to be calling that thing, but it still doesn't
> > manage to program the hw with the right coordinates from what
> > I can see.
> 
> would like more clarity on what the right coordinates should be.

state->src and state->dst

Well, that's assuming that you can't directly feed negative/large
coordinates to your hardware.

> 
> > 
> > /me feels a bit like a broken record...
> 
> Sorry, I was not aware of your previous interventions on the subject of "right
> coordinates". Could you please point me in the right direction, if it is not
> much trouble?
> 
> Best regards,
> Liviu
> 
> > 
> > >  	dest_w = plane->state->crtc_w;
> > >  	dest_h = plane->state->crtc_h;
> > >  	gem = drm_fb_cma_get_gem_obj(fb, 0);
> > >  	scanout_start = gem->paddr + fb->offsets[0] +
> > > -		plane->state->crtc_y * fb->pitches[0] +
> > > -		plane->state->crtc_x *
> > > -		fb->format->cpp[0];
> > > +		src_y * fb->pitches[0] +
> > > +		src_x *	fb->format->cpp[0];
> > >  
> > >  	hdlcd = plane->dev->dev_private;
> > >  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
> > > -- 
> > > 2.11.0
> > > 
> > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> 
> -- 
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ¯\_(ツ)_/¯

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

[BUG] hdlcd gets confused about base address

[Ville Syrjälä]

On Mon, Feb 20, 2017 at 06:59:49PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrj?l? wrote:
> > This stuff should be using the clipped coordinates, not the user
> > coordinates. And it doesn't look like this guy is even calling the
> > clip helper thing.
> > 
> > malidp seems to be calling that thing, but it still doesn't
> > manage to program the hw with the right coordinates from what
> > I can see.
> > 
> > /me feels a bit like a broken record...
> 
> If you mean drm_plane_helper_check_state(), then...
> 
> $ grep drm_plane_helper_check_state Documentation/gpu/ -r
> 
> So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's
> the following, and I think this really isn't helping people understand
> what's required:
> 
>  * This helper library has two parts. The first part has support to implement
>  * primary plane support on top of the normal CRTC configuration interface.
>  * Since the legacy ->set_config interface ties the primary plane together with
>  * the CRTC state this does not allow userspace to disable the primary plane
>  * itself.  To avoid too much duplicated code use
>  * drm_plane_helper_check_update() which can be used to enforce the same
>  * restrictions as primary planes had thus. The default primary plane only
>  * expose XRBG8888 and ARGB8888 as valid pixel formats for the attached
>  * framebuffer.
>  *
>  * Drivers are highly recommended to implement proper support for primary
>  * planes, and newly merged drivers must not rely upon these transitional
>  * helpers.
> 
> Which functions are defined as "these transitional helpers" - the above
> is rather ambiguous.  Is drm_plane_helper_check_state() a "transitional
> helper" or is it not?  (It probably isn't, but the documentation does not
> make that clear.)

Nope. And I guess we might want to move it into some atomic code
instead. IIRC Daniel even suggested that but I was too lazy to do it at
the time.

> 
> It then goes on to:
> 
>  * The second part also implements transitional helpers which allow drivers to
> 
> So maybe the second paragraph needs to be moved after this line to
> remove the confusion?
> 
> If you find that you're repeating something to many people, it's always
> a good idea to re-read the documentation that's supposed to be giving
> people guidance.

Docs are such a new thing. I've not ever read them through myself TBH.

> 
> Now, when you say that we're supposed to program "clipped coordinates"
> maybe you can give a hint what those are and where they come from?
> Is that the vaguely documented "clip" parameter in
> drm_plane_helper_check_state() ?
> 
>  * @clip: integer clipping coordinatesa

/**
 * struct drm_plane_state - mutable plane state
 ...
 * @src: clipped source coordinates of the plane (in 16.16)
 * @dst: clipped destination coordinates of the plane

> 
> If it is, that doesn't really describe it, and neither does the
> description of what the function does, nor what it returns:
> 
>  * Checks that a desired plane update is valid.  Drivers that provide
>  * their own plane handling rather than helper-provided implementations may
>  * still wish to call this function to avoid duplication of error checking
>  * code.
>  *
>  * RETURNS:
>  * Zero if update appears valid, error code on failure
> 
> So, some improvement there could go a long way towards eliminating
> some of these issues...
> 
> Atomic modeset is hideously complex... having poor documentation doesn't
> help.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
Ville Syrj?l?
Intel OTC

Re: [BUG] hdlcd gets confused about base address

[Ville Syrjälä]

On Mon, Feb 20, 2017 at 06:59:49PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > This stuff should be using the clipped coordinates, not the user
> > coordinates. And it doesn't look like this guy is even calling the
> > clip helper thing.
> > 
> > malidp seems to be calling that thing, but it still doesn't
> > manage to program the hw with the right coordinates from what
> > I can see.
> > 
> > /me feels a bit like a broken record...
> 
> If you mean drm_plane_helper_check_state(), then...
> 
> $ grep drm_plane_helper_check_state Documentation/gpu/ -r
> 
> So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's
> the following, and I think this really isn't helping people understand
> what's required:
> 
>  * This helper library has two parts. The first part has support to implement
>  * primary plane support on top of the normal CRTC configuration interface.
>  * Since the legacy ->set_config interface ties the primary plane together with
>  * the CRTC state this does not allow userspace to disable the primary plane
>  * itself.  To avoid too much duplicated code use
>  * drm_plane_helper_check_update() which can be used to enforce the same
>  * restrictions as primary planes had thus. The default primary plane only
>  * expose XRBG8888 and ARGB8888 as valid pixel formats for the attached
>  * framebuffer.
>  *
>  * Drivers are highly recommended to implement proper support for primary
>  * planes, and newly merged drivers must not rely upon these transitional
>  * helpers.
> 
> Which functions are defined as "these transitional helpers" - the above
> is rather ambiguous.  Is drm_plane_helper_check_state() a "transitional
> helper" or is it not?  (It probably isn't, but the documentation does not
> make that clear.)

Nope. And I guess we might want to move it into some atomic code
instead. IIRC Daniel even suggested that but I was too lazy to do it at
the time.

> 
> It then goes on to:
> 
>  * The second part also implements transitional helpers which allow drivers to
> 
> So maybe the second paragraph needs to be moved after this line to
> remove the confusion?
> 
> If you find that you're repeating something to many people, it's always
> a good idea to re-read the documentation that's supposed to be giving
> people guidance.

Docs are such a new thing. I've not ever read them through myself TBH.

> 
> Now, when you say that we're supposed to program "clipped coordinates"
> maybe you can give a hint what those are and where they come from?
> Is that the vaguely documented "clip" parameter in
> drm_plane_helper_check_state() ?
> 
>  * @clip: integer clipping coordinatesa

/**
 * struct drm_plane_state - mutable plane state
 ...
 * @src: clipped source coordinates of the plane (in 16.16)
 * @dst: clipped destination coordinates of the plane

> 
> If it is, that doesn't really describe it, and neither does the
> description of what the function does, nor what it returns:
> 
>  * Checks that a desired plane update is valid.  Drivers that provide
>  * their own plane handling rather than helper-provided implementations may
>  * still wish to call this function to avoid duplication of error checking
>  * code.
>  *
>  * RETURNS:
>  * Zero if update appears valid, error code on failure
> 
> So, some improvement there could go a long way towards eliminating
> some of these issues...
> 
> Atomic modeset is hideously complex... having poor documentation doesn't
> help.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

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

[BUG] hdlcd gets confused about base address

[Daniel Vetter]

On Wed, Feb 22, 2017 at 05:42:30PM +0200, Ville Syrj?l? wrote:
> On Mon, Feb 20, 2017 at 06:59:49PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrj?l? wrote:
> > > This stuff should be using the clipped coordinates, not the user
> > > coordinates. And it doesn't look like this guy is even calling the
> > > clip helper thing.
> > > 
> > > malidp seems to be calling that thing, but it still doesn't
> > > manage to program the hw with the right coordinates from what
> > > I can see.
> > > 
> > > /me feels a bit like a broken record...
> > 
> > If you mean drm_plane_helper_check_state(), then...
> > 
> > $ grep drm_plane_helper_check_state Documentation/gpu/ -r
> > 
> > So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's
> > the following, and I think this really isn't helping people understand
> > what's required:
> > 
> >  * This helper library has two parts. The first part has support to implement
> >  * primary plane support on top of the normal CRTC configuration interface.
> >  * Since the legacy ->set_config interface ties the primary plane together with
> >  * the CRTC state this does not allow userspace to disable the primary plane
> >  * itself.  To avoid too much duplicated code use
> >  * drm_plane_helper_check_update() which can be used to enforce the same
> >  * restrictions as primary planes had thus. The default primary plane only
> >  * expose XRBG8888 and ARGB8888 as valid pixel formats for the attached
> >  * framebuffer.
> >  *
> >  * Drivers are highly recommended to implement proper support for primary
> >  * planes, and newly merged drivers must not rely upon these transitional
> >  * helpers.
> > 
> > Which functions are defined as "these transitional helpers" - the above
> > is rather ambiguous.  Is drm_plane_helper_check_state() a "transitional
> > helper" or is it not?  (It probably isn't, but the documentation does not
> > make that clear.)
> 
> Nope. And I guess we might want to move it into some atomic code
> instead. IIRC Daniel even suggested that but I was too lazy to do it at
> the time.

Yeah, this is a half-finished job with docs not really updated, and most
drivers also not really updated. I guess time to at least note this in our
shiny new todo.rst file. I'll type a patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [BUG] hdlcd gets confused about base address

[Daniel Vetter]

On Wed, Feb 22, 2017 at 05:42:30PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 06:59:49PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > > This stuff should be using the clipped coordinates, not the user
> > > coordinates. And it doesn't look like this guy is even calling the
> > > clip helper thing.
> > > 
> > > malidp seems to be calling that thing, but it still doesn't
> > > manage to program the hw with the right coordinates from what
> > > I can see.
> > > 
> > > /me feels a bit like a broken record...
> > 
> > If you mean drm_plane_helper_check_state(), then...
> > 
> > $ grep drm_plane_helper_check_state Documentation/gpu/ -r
> > 
> > So nothing there... but in drivers/gpu/drm/drm_plane_helper.c, there's
> > the following, and I think this really isn't helping people understand
> > what's required:
> > 
> >  * This helper library has two parts. The first part has support to implement
> >  * primary plane support on top of the normal CRTC configuration interface.
> >  * Since the legacy ->set_config interface ties the primary plane together with
> >  * the CRTC state this does not allow userspace to disable the primary plane
> >  * itself.  To avoid too much duplicated code use
> >  * drm_plane_helper_check_update() which can be used to enforce the same
> >  * restrictions as primary planes had thus. The default primary plane only
> >  * expose XRBG8888 and ARGB8888 as valid pixel formats for the attached
> >  * framebuffer.
> >  *
> >  * Drivers are highly recommended to implement proper support for primary
> >  * planes, and newly merged drivers must not rely upon these transitional
> >  * helpers.
> > 
> > Which functions are defined as "these transitional helpers" - the above
> > is rather ambiguous.  Is drm_plane_helper_check_state() a "transitional
> > helper" or is it not?  (It probably isn't, but the documentation does not
> > make that clear.)
> 
> Nope. And I guess we might want to move it into some atomic code
> instead. IIRC Daniel even suggested that but I was too lazy to do it at
> the time.

Yeah, this is a half-finished job with docs not really updated, and most
drivers also not really updated. I guess time to at least note this in our
shiny new todo.rst file. I'll type a patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

The calculation of the framebuffer's start address was wrongly using
the CRTC's x and y position rather than the one of the source
framebuffer. To fix that we need to update the plane_check code to
call drm_plane_helper_check_state() to clip the src and dst coordinates.
While there so some minor cleanup of redundant freeing of
devm_alloc-ated memory.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---

v1 was discussed here: https://lists.freedesktop.org/archives/dri-devel/2017-February/133379.html

 drivers/gpu/drm/arm/hdlcd_crtc.c | 47 ++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 20ebfb4fbdfa..c65116348281 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -10,6 +10,7 @@
  */
 
 #include <drm/drmP.h>
+#include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_crtc_helper.h>
@@ -206,16 +207,33 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
 				    struct drm_plane_state *state)
 {
-	u32 src_w, src_h;
+	struct drm_rect clip = { 0 };
+	struct drm_crtc_state *crtc_state;
+	u32 src_h = state->src_h >> 16;
 
-	src_w = state->src_w >> 16;
-	src_h = state->src_h >> 16;
+	/* only the HDLCD_REG_FB_LINE_COUNT register has a limit */
+	if (src_h >= HDLCD_MAX_YRES) {
+		DRM_DEBUG_KMS("Invalid source width: %d\n", src_h);
+		return -EINVAL;
+	}
+
+	if (!state->fb || !state->crtc)
+		return 0;
 
-	/* we can't do any scaling of the plane source */
-	if ((src_w != state->crtc_w) || (src_h != state->crtc_h))
+	crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+							state->crtc);
+	if (!crtc_state) {
+		DRM_DEBUG_KMS("Invalid crtc state\n");
 		return -EINVAL;
+	}
 
-	return 0;
+	clip.x2 = crtc_state->adjusted_mode.hdisplay;
+	clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+	return drm_plane_helper_check_state(state, &clip,
+					    DRM_PLANE_HELPER_NO_SCALING,
+					    DRM_PLANE_HELPER_NO_SCALING,
+					    false, true);
 }
 
 static void hdlcd_plane_atomic_update(struct drm_plane *plane,
@@ -224,21 +242,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
 	struct drm_framebuffer *fb = plane->state->fb;
 	struct hdlcd_drm_private *hdlcd;
 	struct drm_gem_cma_object *gem;
-	u32 src_w, src_h, dest_w, dest_h;
+	u32 src_x, src_y, dest_h;
 	dma_addr_t scanout_start;
 
 	if (!fb)
 		return;
 
-	src_w = plane->state->src_w >> 16;
-	src_h = plane->state->src_h >> 16;
-	dest_w = plane->state->crtc_w;
-	dest_h = plane->state->crtc_h;
+	src_x = plane->state->src.x1 >> 16;
+	src_y = plane->state->src.y1 >> 16;
+	dest_h = drm_rect_height(&plane->state->dst);
 	gem = drm_fb_cma_get_gem_obj(fb, 0);
+
 	scanout_start = gem->paddr + fb->offsets[0] +
-		plane->state->crtc_y * fb->pitches[0] +
-		plane->state->crtc_x *
-		fb->format->cpp[0];
+			src_y * fb->pitches[0] +
+			src_x *	fb->format->cpp[0];
 
 	hdlcd = plane->dev->dev_private;
 	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
@@ -285,7 +302,6 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
 				       formats, ARRAY_SIZE(formats),
 				       DRM_PLANE_TYPE_PRIMARY, NULL);
 	if (ret) {
-		devm_kfree(drm->dev, plane);
 		return ERR_PTR(ret);
 	}
 
@@ -309,7 +325,6 @@ int hdlcd_setup_crtc(struct drm_device *drm)
 					&hdlcd_crtc_funcs, NULL);
 	if (ret) {
 		hdlcd_plane_destroy(primary);
-		devm_kfree(drm->dev, primary);
 		return ret;
 	}
 
-- 
2.12.0

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

The calculation of the framebuffer's start address was wrongly using
the CRTC's x and y position rather than the one of the source
framebuffer. To fix that we need to update the plane_check code to
call drm_plane_helper_check_state() to clip the src and dst coordinates.
While there so some minor cleanup of redundant freeing of
devm_alloc-ated memory.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---

v1 was discussed here: https://lists.freedesktop.org/archives/dri-devel/2017-February/133379.html

 drivers/gpu/drm/arm/hdlcd_crtc.c | 47 ++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 20ebfb4fbdfa..c65116348281 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -10,6 +10,7 @@
  */
 
 #include <drm/drmP.h>
+#include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_crtc_helper.h>
@@ -206,16 +207,33 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
 				    struct drm_plane_state *state)
 {
-	u32 src_w, src_h;
+	struct drm_rect clip = { 0 };
+	struct drm_crtc_state *crtc_state;
+	u32 src_h = state->src_h >> 16;
 
-	src_w = state->src_w >> 16;
-	src_h = state->src_h >> 16;
+	/* only the HDLCD_REG_FB_LINE_COUNT register has a limit */
+	if (src_h >= HDLCD_MAX_YRES) {
+		DRM_DEBUG_KMS("Invalid source width: %d\n", src_h);
+		return -EINVAL;
+	}
+
+	if (!state->fb || !state->crtc)
+		return 0;
 
-	/* we can't do any scaling of the plane source */
-	if ((src_w != state->crtc_w) || (src_h != state->crtc_h))
+	crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+							state->crtc);
+	if (!crtc_state) {
+		DRM_DEBUG_KMS("Invalid crtc state\n");
 		return -EINVAL;
+	}
 
-	return 0;
+	clip.x2 = crtc_state->adjusted_mode.hdisplay;
+	clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+	return drm_plane_helper_check_state(state, &clip,
+					    DRM_PLANE_HELPER_NO_SCALING,
+					    DRM_PLANE_HELPER_NO_SCALING,
+					    false, true);
 }
 
 static void hdlcd_plane_atomic_update(struct drm_plane *plane,
@@ -224,21 +242,20 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
 	struct drm_framebuffer *fb = plane->state->fb;
 	struct hdlcd_drm_private *hdlcd;
 	struct drm_gem_cma_object *gem;
-	u32 src_w, src_h, dest_w, dest_h;
+	u32 src_x, src_y, dest_h;
 	dma_addr_t scanout_start;
 
 	if (!fb)
 		return;
 
-	src_w = plane->state->src_w >> 16;
-	src_h = plane->state->src_h >> 16;
-	dest_w = plane->state->crtc_w;
-	dest_h = plane->state->crtc_h;
+	src_x = plane->state->src.x1 >> 16;
+	src_y = plane->state->src.y1 >> 16;
+	dest_h = drm_rect_height(&plane->state->dst);
 	gem = drm_fb_cma_get_gem_obj(fb, 0);
+
 	scanout_start = gem->paddr + fb->offsets[0] +
-		plane->state->crtc_y * fb->pitches[0] +
-		plane->state->crtc_x *
-		fb->format->cpp[0];
+			src_y * fb->pitches[0] +
+			src_x *	fb->format->cpp[0];
 
 	hdlcd = plane->dev->dev_private;
 	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
@@ -285,7 +302,6 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
 				       formats, ARRAY_SIZE(formats),
 				       DRM_PLANE_TYPE_PRIMARY, NULL);
 	if (ret) {
-		devm_kfree(drm->dev, plane);
 		return ERR_PTR(ret);
 	}
 
@@ -309,7 +325,6 @@ int hdlcd_setup_crtc(struct drm_device *drm)
 					&hdlcd_crtc_funcs, NULL);
 	if (ret) {
 		hdlcd_plane_destroy(primary);
-		devm_kfree(drm->dev, primary);
 		return ret;
 	}
 
-- 
2.12.0

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

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> The calculation of the framebuffer's start address was wrongly using
> the CRTC's x and y position rather than the one of the source
> framebuffer. To fix that we need to update the plane_check code to
> call drm_plane_helper_check_state() to clip the src and dst coordinates.
> While there so some minor cleanup of redundant freeing of
> devm_alloc-ated memory.

The following series is what I came up with, although I've had no time
to test it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> The calculation of the framebuffer's start address was wrongly using
> the CRTC's x and y position rather than the one of the source
> framebuffer. To fix that we need to update the plane_check code to
> call drm_plane_helper_check_state() to clip the src and dst coordinates.
> While there so some minor cleanup of redundant freeing of
> devm_alloc-ated memory.

The following series is what I came up with, although I've had no time
to test it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King]

The hdlcd crtc is unable to place planes in arbitary positions and sizes
within the active area.  Use drm_plane_helper_check_state() to validate
the requested state.

Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 7d4e5aa77195..ba68fa2b5701 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -10,6 +10,7 @@
  */
 
 #include <drm/drmP.h>
+#include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_crtc_helper.h>
@@ -205,13 +206,30 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
 				    struct drm_plane_state *state)
 {
-	u32 src_w, src_h;
+	struct drm_crtc_state *crtc_state;
+	struct drm_crtc *crtc;
+	struct drm_rect clip = { 0 };
+	int ret;
+
+	crtc = state->crtc;
+	if (!crtc)
+		return 0;
 
-	src_w = state->src_w >> 16;
-	src_h = state->src_h >> 16;
+	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+	if (!crtc_state->enable)
+		return -EINVAL;
+
+	clip.x2 = crtc_state->adjusted_mode.hdisplay;
+	clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+	ret = drm_plane_helper_check_state(state, &clip,
+					   DRM_PLANE_HELPER_NO_SCALING,
+					   DRM_PLANE_HELPER_NO_SCALING,
+					   false, true);
+	if (ret)
+		return ret;
 
-	/* we can't do any scaling of the plane source */
-	if ((src_w != state->crtc_w) || (src_h != state->crtc_h))
+	if (!state->visible)
 		return -EINVAL;
 
 	return 0;
-- 
2.7.4

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King]

The hdlcd crtc is unable to place planes in arbitary positions and sizes
within the active area.  Use drm_plane_helper_check_state() to validate
the requested state.

Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 7d4e5aa77195..ba68fa2b5701 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -10,6 +10,7 @@
  */
 
 #include <drm/drmP.h>
+#include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_crtc_helper.h>
@@ -205,13 +206,30 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
 				    struct drm_plane_state *state)
 {
-	u32 src_w, src_h;
+	struct drm_crtc_state *crtc_state;
+	struct drm_crtc *crtc;
+	struct drm_rect clip = { 0 };
+	int ret;
+
+	crtc = state->crtc;
+	if (!crtc)
+		return 0;
 
-	src_w = state->src_w >> 16;
-	src_h = state->src_h >> 16;
+	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+	if (!crtc_state->enable)
+		return -EINVAL;
+
+	clip.x2 = crtc_state->adjusted_mode.hdisplay;
+	clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+	ret = drm_plane_helper_check_state(state, &clip,
+					   DRM_PLANE_HELPER_NO_SCALING,
+					   DRM_PLANE_HELPER_NO_SCALING,
+					   false, true);
+	if (ret)
+		return ret;
 
-	/* we can't do any scaling of the plane source */
-	if ((src_w != state->crtc_w) || (src_h != state->crtc_h))
+	if (!state->visible)
 		return -EINVAL;
 
 	return 0;
-- 
2.7.4

[PATCH 2/3] drm/arm: hdlcd: fix plane base address calculation

[Russell King]

The plane base address needs to be calculated using the source
coordinates to position the source correctly - it's possible to have
a larger source buffer than the CRTC size, and have several CRTCs
reading from different parts of the buffer.

In such a case, the pitch may be larger, and we will use the source
position to select an area of the buffer to scan out.

In order for this to work correctly, we need to also fix the atomic
check to do a fuller validation of the new state.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index ba68fa2b5701..cf70184fd028 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -240,21 +240,19 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
 {
 	struct hdlcd_drm_private *hdlcd;
 	struct drm_gem_cma_object *gem;
-	u32 src_w, src_h, dest_w, dest_h;
+	u32 src_x, src_y, dest_h;
 	dma_addr_t scanout_start;
 
 	if (!plane->state->fb)
 		return;
 
-	src_w = plane->state->src_w >> 16;
-	src_h = plane->state->src_h >> 16;
-	dest_w = plane->state->crtc_w;
-	dest_h = plane->state->crtc_h;
 	gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
+	src_x = plane->state->src_x >> 16;
+	src_y = plane->state->src_y >> 16;
+	dest_h = plane->state->crtc_h;
 	scanout_start = gem->paddr + plane->state->fb->offsets[0] +
-		plane->state->crtc_y * plane->state->fb->pitches[0] +
-		plane->state->crtc_x *
-		drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
+		src_y * plane->state->fb->pitches[0] +
+		src_x * drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
 
 	hdlcd = plane->dev->dev_private;
 	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, plane->state->fb->pitches[0]);
-- 
2.7.4

[PATCH 2/3] drm/arm: hdlcd: fix plane base address calculation

[Russell King]

The plane base address needs to be calculated using the source
coordinates to position the source correctly - it's possible to have
a larger source buffer than the CRTC size, and have several CRTCs
reading from different parts of the buffer.

In such a case, the pitch may be larger, and we will use the source
position to select an area of the buffer to scan out.

In order for this to work correctly, we need to also fix the atomic
check to do a fuller validation of the new state.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index ba68fa2b5701..cf70184fd028 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -240,21 +240,19 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
 {
 	struct hdlcd_drm_private *hdlcd;
 	struct drm_gem_cma_object *gem;
-	u32 src_w, src_h, dest_w, dest_h;
+	u32 src_x, src_y, dest_h;
 	dma_addr_t scanout_start;
 
 	if (!plane->state->fb)
 		return;
 
-	src_w = plane->state->src_w >> 16;
-	src_h = plane->state->src_h >> 16;
-	dest_w = plane->state->crtc_w;
-	dest_h = plane->state->crtc_h;
 	gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
+	src_x = plane->state->src_x >> 16;
+	src_y = plane->state->src_y >> 16;
+	dest_h = plane->state->crtc_h;
 	scanout_start = gem->paddr + plane->state->fb->offsets[0] +
-		plane->state->crtc_y * plane->state->fb->pitches[0] +
-		plane->state->crtc_x *
-		drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
+		src_y * plane->state->fb->pitches[0] +
+		src_x * drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
 
 	hdlcd = plane->dev->dev_private;
 	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, plane->state->fb->pitches[0]);
-- 
2.7.4

[PATCH 3/3] drm/arm: hdlcd: check for rotation

[Russell King]

hdlcd does not support rotation - check for it and reject plane updates
that try to rotate a plane.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf70184fd028..171acc842368 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -215,6 +215,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
 	if (!crtc)
 		return 0;
 
+	/* We do not support rotation */
+	if (state->rotation != DRM_ROTATE_0)
+		return -EINVAL;
+
 	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
 	if (!crtc_state->enable)
 		return -EINVAL;
-- 
2.7.4

[PATCH 3/3] drm/arm: hdlcd: check for rotation

[Russell King]

hdlcd does not support rotation - check for it and reject plane updates
that try to rotate a plane.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf70184fd028..171acc842368 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -215,6 +215,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
 	if (!crtc)
 		return 0;
 
+	/* We do not support rotation */
+	if (state->rotation != DRM_ROTATE_0)
+		return -EINVAL;
+
 	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
 	if (!crtc_state->enable)
 		return -EINVAL;
-- 
2.7.4

[PATCH 3/3] drm/arm: hdlcd: check for rotation

[Ville Syrjälä]

On Fri, Mar 31, 2017 at 10:51:52AM +0100, Russell King wrote:
> hdlcd does not support rotation - check for it and reject plane updates
> that try to rotate a plane.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index cf70184fd028..171acc842368 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -215,6 +215,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>  	if (!crtc)
>  		return 0;
>  
> +	/* We do not support rotation */
> +	if (state->rotation != DRM_ROTATE_0)
> +		return -EINVAL;

This can't happen unless you attach a rotation property with a bogus
set of supported rotations to the plane.

> +
>  	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
>  	if (!crtc_state->enable)
>  		return -EINVAL;
> -- 
> 2.7.4

-- 
Ville Syrj?l?
Intel OTC

Re: [PATCH 3/3] drm/arm: hdlcd: check for rotation

[Ville Syrjälä]

On Fri, Mar 31, 2017 at 10:51:52AM +0100, Russell King wrote:
> hdlcd does not support rotation - check for it and reject plane updates
> that try to rotate a plane.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index cf70184fd028..171acc842368 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -215,6 +215,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>  	if (!crtc)
>  		return 0;
>  
> +	/* We do not support rotation */
> +	if (state->rotation != DRM_ROTATE_0)
> +		return -EINVAL;

This can't happen unless you attach a rotation property with a bogus
set of supported rotations to the plane.

> +
>  	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
>  	if (!crtc_state->enable)
>  		return -EINVAL;
> -- 
> 2.7.4

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

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Liviu Dudau]

Hi Russell,

You were Cc-ed in a patch from March 8th that did all this:

https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html

I have not received any response from you, so I have already pushed the
patch in my public repo:

git://linux-arm.org/linux-ld.git for-upstream/hdlcd

It has been included into linux-next for at least a couple of weeks now.

Best regards,
Liviu

On Fri, Mar 31, 2017 at 10:51:41AM +0100, Russell King wrote:
> The hdlcd crtc is unable to place planes in arbitary positions and sizes
> within the active area.  Use drm_plane_helper_check_state() to validate
> the requested state.
> 
> Suggested-by: Daniel Vetter <daniel@ffwll.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 28 +++++++++++++++++++++++-----
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 7d4e5aa77195..ba68fa2b5701 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include <drm/drmP.h>
> +#include <drm/drm_atomic.h>
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_crtc_helper.h>
> @@ -205,13 +206,30 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
>  static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>  				    struct drm_plane_state *state)
>  {
> -	u32 src_w, src_h;
> +	struct drm_crtc_state *crtc_state;
> +	struct drm_crtc *crtc;
> +	struct drm_rect clip = { 0 };
> +	int ret;
> +
> +	crtc = state->crtc;
> +	if (!crtc)
> +		return 0;
>  
> -	src_w = state->src_w >> 16;
> -	src_h = state->src_h >> 16;
> +	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
> +	if (!crtc_state->enable)
> +		return -EINVAL;
> +
> +	clip.x2 = crtc_state->adjusted_mode.hdisplay;
> +	clip.y2 = crtc_state->adjusted_mode.vdisplay;
> +
> +	ret = drm_plane_helper_check_state(state, &clip,
> +					   DRM_PLANE_HELPER_NO_SCALING,
> +					   DRM_PLANE_HELPER_NO_SCALING,
> +					   false, true);
> +	if (ret)
> +		return ret;
>  
> -	/* we can't do any scaling of the plane source */
> -	if ((src_w != state->crtc_w) || (src_h != state->crtc_h))
> +	if (!state->visible)
>  		return -EINVAL;
>  
>  	return 0;
> -- 
> 2.7.4
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Liviu Dudau]

Hi Russell,

You were Cc-ed in a patch from March 8th that did all this:

https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html

I have not received any response from you, so I have already pushed the
patch in my public repo:

git://linux-arm.org/linux-ld.git for-upstream/hdlcd

It has been included into linux-next for at least a couple of weeks now.

Best regards,
Liviu

On Fri, Mar 31, 2017 at 10:51:41AM +0100, Russell King wrote:
> The hdlcd crtc is unable to place planes in arbitary positions and sizes
> within the active area.  Use drm_plane_helper_check_state() to validate
> the requested state.
> 
> Suggested-by: Daniel Vetter <daniel@ffwll.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 28 +++++++++++++++++++++++-----
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 7d4e5aa77195..ba68fa2b5701 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -10,6 +10,7 @@
>   */
>  
>  #include <drm/drmP.h>
> +#include <drm/drm_atomic.h>
>  #include <drm/drm_atomic_helper.h>
>  #include <drm/drm_crtc.h>
>  #include <drm/drm_crtc_helper.h>
> @@ -205,13 +206,30 @@ static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
>  static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>  				    struct drm_plane_state *state)
>  {
> -	u32 src_w, src_h;
> +	struct drm_crtc_state *crtc_state;
> +	struct drm_crtc *crtc;
> +	struct drm_rect clip = { 0 };
> +	int ret;
> +
> +	crtc = state->crtc;
> +	if (!crtc)
> +		return 0;
>  
> -	src_w = state->src_w >> 16;
> -	src_h = state->src_h >> 16;
> +	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
> +	if (!crtc_state->enable)
> +		return -EINVAL;
> +
> +	clip.x2 = crtc_state->adjusted_mode.hdisplay;
> +	clip.y2 = crtc_state->adjusted_mode.vdisplay;
> +
> +	ret = drm_plane_helper_check_state(state, &clip,
> +					   DRM_PLANE_HELPER_NO_SCALING,
> +					   DRM_PLANE_HELPER_NO_SCALING,
> +					   false, true);
> +	if (ret)
> +		return ret;
>  
> -	/* we can't do any scaling of the plane source */
> -	if ((src_w != state->crtc_w) || (src_h != state->crtc_h))
> +	if (!state->visible)
>  		return -EINVAL;
>  
>  	return 0;
> -- 
> 2.7.4
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> Hi Russell,
> 
> You were Cc-ed in a patch from March 8th that did all this:
> 
> https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html

I'm aware of that (you may notice that this was threaded to that patch.)

> I have not received any response from you, so I have already pushed the
> patch in my public repo:
> 
> git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> 
> It has been included into linux-next for at least a couple of weeks now.

I've not had a chance to test any of this, but I believe that your
patch does not fully address the issue, due to bits missing from
the validation path.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> Hi Russell,
> 
> You were Cc-ed in a patch from March 8th that did all this:
> 
> https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html

I'm aware of that (you may notice that this was threaded to that patch.)

> I have not received any response from you, so I have already pushed the
> patch in my public repo:
> 
> git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> 
> It has been included into linux-next for at least a couple of weeks now.

I've not had a chance to test any of this, but I believe that your
patch does not fully address the issue, due to bits missing from
the validation path.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 3/3] drm/arm: hdlcd: check for rotation

[Liviu Dudau]

On Fri, Mar 31, 2017 at 01:11:23PM +0300, Ville Syrj?l? wrote:
> On Fri, Mar 31, 2017 at 10:51:52AM +0100, Russell King wrote:
> > hdlcd does not support rotation - check for it and reject plane updates
> > that try to rotate a plane.
> > 
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> >  drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index cf70184fd028..171acc842368 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -215,6 +215,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
> >  	if (!crtc)
> >  		return 0;
> >  
> > +	/* We do not support rotation */
> > +	if (state->rotation != DRM_ROTATE_0)
> > +		return -EINVAL;
> 
> This can't happen unless you attach a rotation property with a bogus
> set of supported rotations to the plane.

Which we don't. I did toy with the idea of adding it as one can hack support for 0? and 180?
rotation by playing with the line pitch, I've even created a patch but in the end I've
decided not to publish it. If there is anyone interested at some moment on this, I can dig it out.

Best regards,
Liviu

> 
> > +
> >  	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
> >  	if (!crtc_state->enable)
> >  		return -EINVAL;
> > -- 
> > 2.7.4
> 
> -- 
> Ville Syrj?l?
> Intel OTC

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 3/3] drm/arm: hdlcd: check for rotation

[Liviu Dudau]

On Fri, Mar 31, 2017 at 01:11:23PM +0300, Ville Syrjälä wrote:
> On Fri, Mar 31, 2017 at 10:51:52AM +0100, Russell King wrote:
> > hdlcd does not support rotation - check for it and reject plane updates
> > that try to rotate a plane.
> > 
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> >  drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index cf70184fd028..171acc842368 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -215,6 +215,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
> >  	if (!crtc)
> >  		return 0;
> >  
> > +	/* We do not support rotation */
> > +	if (state->rotation != DRM_ROTATE_0)
> > +		return -EINVAL;
> 
> This can't happen unless you attach a rotation property with a bogus
> set of supported rotations to the plane.

Which we don't. I did toy with the idea of adding it as one can hack support for 0° and 180°
rotation by playing with the line pitch, I've even created a patch but in the end I've
decided not to publish it. If there is anyone interested at some moment on this, I can dig it out.

Best regards,
Liviu

> 
> > +
> >  	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
> >  	if (!crtc_state->enable)
> >  		return -EINVAL;
> > -- 
> > 2.7.4
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Liviu Dudau]

On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > Hi Russell,
> > 
> > You were Cc-ed in a patch from March 8th that did all this:
> > 
> > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> 
> I'm aware of that (you may notice that this was threaded to that patch.)
> 
> > I have not received any response from you, so I have already pushed the
> > patch in my public repo:
> > 
> > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > 
> > It has been included into linux-next for at least a couple of weeks now.
> 
> I've not had a chance to test any of this, but I believe that your
> patch does not fully address the issue, due to bits missing from
> the validation path.

Care to point out which bits were missing from my patch that are in yours?

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Liviu Dudau]

On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > Hi Russell,
> > 
> > You were Cc-ed in a patch from March 8th that did all this:
> > 
> > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> 
> I'm aware of that (you may notice that this was threaded to that patch.)
> 
> > I have not received any response from you, so I have already pushed the
> > patch in my public repo:
> > 
> > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > 
> > It has been included into linux-next for at least a couple of weeks now.
> 
> I've not had a chance to test any of this, but I believe that your
> patch does not fully address the issue, due to bits missing from
> the validation path.

Care to point out which bits were missing from my patch that are in yours?

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > Hi Russell,
> > > 
> > > You were Cc-ed in a patch from March 8th that did all this:
> > > 
> > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > 
> > I'm aware of that (you may notice that this was threaded to that patch.)
> > 
> > > I have not received any response from you, so I have already pushed the
> > > patch in my public repo:
> > > 
> > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > 
> > > It has been included into linux-next for at least a couple of weeks now.
> > 
> > I've not had a chance to test any of this, but I believe that your
> > patch does not fully address the issue, due to bits missing from
> > the validation path.
> 
> Care to point out which bits were missing from my patch that are in yours?

The visible check?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > Hi Russell,
> > > 
> > > You were Cc-ed in a patch from March 8th that did all this:
> > > 
> > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > 
> > I'm aware of that (you may notice that this was threaded to that patch.)
> > 
> > > I have not received any response from you, so I have already pushed the
> > > patch in my public repo:
> > > 
> > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > 
> > > It has been included into linux-next for at least a couple of weeks now.
> > 
> > I've not had a chance to test any of this, but I believe that your
> > patch does not fully address the issue, due to bits missing from
> > the validation path.
> 
> Care to point out which bits were missing from my patch that are in yours?

The visible check?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Liviu Dudau]

On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > > Hi Russell,
> > > > 
> > > > You were Cc-ed in a patch from March 8th that did all this:
> > > > 
> > > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > > 
> > > I'm aware of that (you may notice that this was threaded to that patch.)
> > > 
> > > > I have not received any response from you, so I have already pushed the
> > > > patch in my public repo:
> > > > 
> > > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > > 
> > > > It has been included into linux-next for at least a couple of weeks now.
> > > 
> > > I've not had a chance to test any of this, but I believe that your
> > > patch does not fully address the issue, due to bits missing from
> > > the validation path.
> > 
> > Care to point out which bits were missing from my patch that are in yours?
> 
> The visible check?

A plane's ->atomic_check() hook can be called with TEST_ONLY to figure out from
userspace if the given configuration is a valid one that can be accepted by
the hardware. There should be no error if the plane will not be visible, as we
are not programming anything yet.

I would also argue that the test that you remove and replace with state->visible
is important. We can't do *any* scaling, while with your patch we could accept
src_w != crtc_w as long as it is visible. Hardware is not capable of handling that.

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Liviu Dudau]

On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > > Hi Russell,
> > > > 
> > > > You were Cc-ed in a patch from March 8th that did all this:
> > > > 
> > > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > > 
> > > I'm aware of that (you may notice that this was threaded to that patch.)
> > > 
> > > > I have not received any response from you, so I have already pushed the
> > > > patch in my public repo:
> > > > 
> > > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > > 
> > > > It has been included into linux-next for at least a couple of weeks now.
> > > 
> > > I've not had a chance to test any of this, but I believe that your
> > > patch does not fully address the issue, due to bits missing from
> > > the validation path.
> > 
> > Care to point out which bits were missing from my patch that are in yours?
> 
> The visible check?

A plane's ->atomic_check() hook can be called with TEST_ONLY to figure out from
userspace if the given configuration is a valid one that can be accepted by
the hardware. There should be no error if the plane will not be visible, as we
are not programming anything yet.

I would also argue that the test that you remove and replace with state->visible
is important. We can't do *any* scaling, while with your patch we could accept
src_w != crtc_w as long as it is visible. Hardware is not capable of handling that.

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 12:41:30PM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> > > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > > > Hi Russell,
> > > > > 
> > > > > You were Cc-ed in a patch from March 8th that did all this:
> > > > > 
> > > > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > > > 
> > > > I'm aware of that (you may notice that this was threaded to that patch.)
> > > > 
> > > > > I have not received any response from you, so I have already pushed the
> > > > > patch in my public repo:
> > > > > 
> > > > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > > > 
> > > > > It has been included into linux-next for at least a couple of weeks now.
> > > > 
> > > > I've not had a chance to test any of this, but I believe that your
> > > > patch does not fully address the issue, due to bits missing from
> > > > the validation path.
> > > 
> > > Care to point out which bits were missing from my patch that are in yours?
> > 
> > The visible check?
> 
> A plane's ->atomic_check() hook can be called with TEST_ONLY to figure out from
> userspace if the given configuration is a valid one that can be accepted by
> the hardware. There should be no error if the plane will not be visible, as we
> are not programming anything yet.
> 
> I would also argue that the test that you remove and replace with state->visible
> is important. We can't do *any* scaling, while with your patch we could accept
> src_w != crtc_w as long as it is visible. Hardware is not capable of handling that.

That's what the "DRM_PLANE_HELPER_NO_SCALING" arguments to
drm_plane_helper_check_state() are doing:

	drm_plane_helper_check_state()
		drm_rect_calc_hscale()

		        if (hscale < min_hscale || hscale > max_hscale)
                		return -ERANGE;

		drm_rect_calc_vscale()

		        if (vscale < min_vscale || vscale > max_vscale)
                		return -ERANGE;

where DRM_PLANE_HELPER_NO_SCALING is 1.0 in 16:16 format.  So, this
ensures that the scaling factor is 1.0, returning -ERANGE if it isn't.

If this lets through a scaled source, then there's a bug that needs
fixing in the helper.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 12:41:30PM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> > > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > > > Hi Russell,
> > > > > 
> > > > > You were Cc-ed in a patch from March 8th that did all this:
> > > > > 
> > > > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > > > 
> > > > I'm aware of that (you may notice that this was threaded to that patch.)
> > > > 
> > > > > I have not received any response from you, so I have already pushed the
> > > > > patch in my public repo:
> > > > > 
> > > > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > > > 
> > > > > It has been included into linux-next for at least a couple of weeks now.
> > > > 
> > > > I've not had a chance to test any of this, but I believe that your
> > > > patch does not fully address the issue, due to bits missing from
> > > > the validation path.
> > > 
> > > Care to point out which bits were missing from my patch that are in yours?
> > 
> > The visible check?
> 
> A plane's ->atomic_check() hook can be called with TEST_ONLY to figure out from
> userspace if the given configuration is a valid one that can be accepted by
> the hardware. There should be no error if the plane will not be visible, as we
> are not programming anything yet.
> 
> I would also argue that the test that you remove and replace with state->visible
> is important. We can't do *any* scaling, while with your patch we could accept
> src_w != crtc_w as long as it is visible. Hardware is not capable of handling that.

That's what the "DRM_PLANE_HELPER_NO_SCALING" arguments to
drm_plane_helper_check_state() are doing:

	drm_plane_helper_check_state()
		drm_rect_calc_hscale()

		        if (hscale < min_hscale || hscale > max_hscale)
                		return -ERANGE;

		drm_rect_calc_vscale()

		        if (vscale < min_vscale || vscale > max_vscale)
                		return -ERANGE;

where DRM_PLANE_HELPER_NO_SCALING is 1.0 in 16:16 format.  So, this
ensures that the scaling factor is 1.0, returning -ERANGE if it isn't.

If this lets through a scaled source, then there's a bug that needs
fixing in the helper.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/3] drm/arm: hdlcd: fix plane base address calculation

[Liviu Dudau]

On Fri, Mar 31, 2017 at 10:51:46AM +0100, Russell King wrote:
> The plane base address needs to be calculated using the source
> coordinates to position the source correctly - it's possible to have
> a larger source buffer than the CRTC size, and have several CRTCs
> reading from different parts of the buffer.
> 
> In such a case, the pitch may be larger, and we will use the source
> position to select an area of the buffer to scan out.
> 
> In order for this to work correctly, we need to also fix the atomic
> check to do a fuller validation of the new state.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

This patch does not apply for me. You seem to be missing patch 59477fa90bfec
("drm/arm: Add local 'fb' variables) from your tree.

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index ba68fa2b5701..cf70184fd028 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -240,21 +240,19 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
>  {
>  	struct hdlcd_drm_private *hdlcd;
>  	struct drm_gem_cma_object *gem;
> -	u32 src_w, src_h, dest_w, dest_h;
> +	u32 src_x, src_y, dest_h;
>  	dma_addr_t scanout_start;
>  
>  	if (!plane->state->fb)
>  		return;
>  
> -	src_w = plane->state->src_w >> 16;
> -	src_h = plane->state->src_h >> 16;
> -	dest_w = plane->state->crtc_w;
> -	dest_h = plane->state->crtc_h;
>  	gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
> +	src_x = plane->state->src_x >> 16;
> +	src_y = plane->state->src_y >> 16;
> +	dest_h = plane->state->crtc_h;
>  	scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> -		plane->state->crtc_y * plane->state->fb->pitches[0] +
> -		plane->state->crtc_x *
> -		drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
> +		src_y * plane->state->fb->pitches[0] +
> +		src_x * drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
>  
>  	hdlcd = plane->dev->dev_private;
>  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, plane->state->fb->pitches[0]);
> -- 
> 2.7.4
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 2/3] drm/arm: hdlcd: fix plane base address calculation

[Liviu Dudau]

On Fri, Mar 31, 2017 at 10:51:46AM +0100, Russell King wrote:
> The plane base address needs to be calculated using the source
> coordinates to position the source correctly - it's possible to have
> a larger source buffer than the CRTC size, and have several CRTCs
> reading from different parts of the buffer.
> 
> In such a case, the pitch may be larger, and we will use the source
> position to select an area of the buffer to scan out.
> 
> In order for this to work correctly, we need to also fix the atomic
> check to do a fuller validation of the new state.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

This patch does not apply for me. You seem to be missing patch 59477fa90bfec
("drm/arm: Add local 'fb' variables) from your tree.

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index ba68fa2b5701..cf70184fd028 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -240,21 +240,19 @@ static void hdlcd_plane_atomic_update(struct drm_plane *plane,
>  {
>  	struct hdlcd_drm_private *hdlcd;
>  	struct drm_gem_cma_object *gem;
> -	u32 src_w, src_h, dest_w, dest_h;
> +	u32 src_x, src_y, dest_h;
>  	dma_addr_t scanout_start;
>  
>  	if (!plane->state->fb)
>  		return;
>  
> -	src_w = plane->state->src_w >> 16;
> -	src_h = plane->state->src_h >> 16;
> -	dest_w = plane->state->crtc_w;
> -	dest_h = plane->state->crtc_h;
>  	gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
> +	src_x = plane->state->src_x >> 16;
> +	src_y = plane->state->src_y >> 16;
> +	dest_h = plane->state->crtc_h;
>  	scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> -		plane->state->crtc_y * plane->state->fb->pitches[0] +
> -		plane->state->crtc_x *
> -		drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
> +		src_y * plane->state->fb->pitches[0] +
> +		src_x * drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
>  
>  	hdlcd = plane->dev->dev_private;
>  	hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, plane->state->fb->pitches[0]);
> -- 
> 2.7.4
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> > The calculation of the framebuffer's start address was wrongly using
> > the CRTC's x and y position rather than the one of the source
> > framebuffer. To fix that we need to update the plane_check code to
> > call drm_plane_helper_check_state() to clip the src and dst coordinates.
> > While there so some minor cleanup of redundant freeing of
> > devm_alloc-ated memory.
> 
> The following series is what I came up with, although I've had no time
> to test it.

I'm afraid I'm going to NAK this series. It would've been nicer for you to
comment on the v2 patch that I have sent rather than going around and coming
back with effectively the same thing but split into 2 patches. I'm having
trouble applying your series to the v4.11-rc4 (specially 2/3). Also 3/3 is
superfluous, as we don't expose the DRM_ROTATE property to userspace.

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> > The calculation of the framebuffer's start address was wrongly using
> > the CRTC's x and y position rather than the one of the source
> > framebuffer. To fix that we need to update the plane_check code to
> > call drm_plane_helper_check_state() to clip the src and dst coordinates.
> > While there so some minor cleanup of redundant freeing of
> > devm_alloc-ated memory.
> 
> The following series is what I came up with, although I've had no time
> to test it.

I'm afraid I'm going to NAK this series. It would've been nicer for you to
comment on the v2 patch that I have sent rather than going around and coming
back with effectively the same thing but split into 2 patches. I'm having
trouble applying your series to the v4.11-rc4 (specially 2/3). Also 3/3 is
superfluous, as we don't expose the DRM_ROTATE property to userspace.

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> > > The calculation of the framebuffer's start address was wrongly using
> > > the CRTC's x and y position rather than the one of the source
> > > framebuffer. To fix that we need to update the plane_check code to
> > > call drm_plane_helper_check_state() to clip the src and dst coordinates.
> > > While there so some minor cleanup of redundant freeing of
> > > devm_alloc-ated memory.
> > 
> > The following series is what I came up with, although I've had no time
> > to test it.
> 
> I'm afraid I'm going to NAK this series. It would've been nicer for you to
> comment on the v2 patch that I have sent rather than going around and coming
> back with effectively the same thing but split into 2 patches. I'm having
> trouble applying your series to the v4.11-rc4 (specially 2/3). Also 3/3 is
> superfluous, as we don't expose the DRM_ROTATE property to userspace.

Rather than throwing accusations, let's look at what happened.

I reported the bug on 18th November 2016 - I quote:

   Something I also noticed is this:

        scanout_start = gem->paddr + plane->state->fb->offsets[0] +
                plane->state->crtc_y * plane->state->fb->pitches[0] +
                plane->state->crtc_x * bpp / 8;

   Surely this should be using src_[xy] (which are the position in the
   source - iow, memory, and not crtc_[xy] which is the position on the
   CRTC displayed window.  To put it another way, the src_* define the
   region of the source material that is mapped onto a rectangular area
   on the display defined by crtc_*.

This got ignored, and on 21st November, I came up with an initial patch
to solve it at the time, but we were busy discussing the base address
issue.

I sent a reminder on 20th February about it, and we discussed it, and I
said at the time I did not have time to test your patch.  Ville commented
on your patch, which confused me a little, but having worked it out, I
reworked the patch from 21st November to fix that, creating this patch
series.

I did not post it, because I hadn't tested it (since the Juno requires
a long-winded way to update the kernel), so I never got around to
testing this.  So, this series pre-dates your v2 patch by a good few
weeks.

You posted your v2 patch on March 8th, and I've not had a chance to
test that, nor have I had a chance to test my own three patch series.

Today, I noticed that I still had the three patch series, so I thought
I ought to get it out in the wild.

Now, due to the amount of patches I carry:

$ git lg origin.. | wc -l
491

I work against Linus' tree _only_, so all patches I post are based on
Linus' kernel, and not random other git trees.  I do not randomly fetch
other git trees to base patches on them, because that would cause me
insane merging issues so that I can test half the stuff I'm carrying.

Now, it's true that they're not against -rc, but are currently against
4.10 - it seems that I missed rebasing _this_ particular branch to
4.11-rc yet, although most of my other branches are.

What was I so busy with when you posted your patch on the 8th March?
Oh yes, that was the week _after_ the merge window closed, and was the
week I was doing the mass rebase of about 500 patches.

Sorry I didn't get around to testing your patch, and sorry for eventually
getting around to posting my patches.  Obviously, I should just fuck off
and do something else.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> > > The calculation of the framebuffer's start address was wrongly using
> > > the CRTC's x and y position rather than the one of the source
> > > framebuffer. To fix that we need to update the plane_check code to
> > > call drm_plane_helper_check_state() to clip the src and dst coordinates.
> > > While there so some minor cleanup of redundant freeing of
> > > devm_alloc-ated memory.
> > 
> > The following series is what I came up with, although I've had no time
> > to test it.
> 
> I'm afraid I'm going to NAK this series. It would've been nicer for you to
> comment on the v2 patch that I have sent rather than going around and coming
> back with effectively the same thing but split into 2 patches. I'm having
> trouble applying your series to the v4.11-rc4 (specially 2/3). Also 3/3 is
> superfluous, as we don't expose the DRM_ROTATE property to userspace.

Rather than throwing accusations, let's look at what happened.

I reported the bug on 18th November 2016 - I quote:

   Something I also noticed is this:

        scanout_start = gem->paddr + plane->state->fb->offsets[0] +
                plane->state->crtc_y * plane->state->fb->pitches[0] +
                plane->state->crtc_x * bpp / 8;

   Surely this should be using src_[xy] (which are the position in the
   source - iow, memory, and not crtc_[xy] which is the position on the
   CRTC displayed window.  To put it another way, the src_* define the
   region of the source material that is mapped onto a rectangular area
   on the display defined by crtc_*.

This got ignored, and on 21st November, I came up with an initial patch
to solve it at the time, but we were busy discussing the base address
issue.

I sent a reminder on 20th February about it, and we discussed it, and I
said at the time I did not have time to test your patch.  Ville commented
on your patch, which confused me a little, but having worked it out, I
reworked the patch from 21st November to fix that, creating this patch
series.

I did not post it, because I hadn't tested it (since the Juno requires
a long-winded way to update the kernel), so I never got around to
testing this.  So, this series pre-dates your v2 patch by a good few
weeks.

You posted your v2 patch on March 8th, and I've not had a chance to
test that, nor have I had a chance to test my own three patch series.

Today, I noticed that I still had the three patch series, so I thought
I ought to get it out in the wild.

Now, due to the amount of patches I carry:

$ git lg origin.. | wc -l
491

I work against Linus' tree _only_, so all patches I post are based on
Linus' kernel, and not random other git trees.  I do not randomly fetch
other git trees to base patches on them, because that would cause me
insane merging issues so that I can test half the stuff I'm carrying.

Now, it's true that they're not against -rc, but are currently against
4.10 - it seems that I missed rebasing _this_ particular branch to
4.11-rc yet, although most of my other branches are.

What was I so busy with when you posted your patch on the 8th March?
Oh yes, that was the week _after_ the merge window closed, and was the
week I was doing the mass rebase of about 500 patches.

Sorry I didn't get around to testing your patch, and sorry for eventually
getting around to posting my patches.  Obviously, I should just fuck off
and do something else.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> > > On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> > > > The calculation of the framebuffer's start address was wrongly using
> > > > the CRTC's x and y position rather than the one of the source
> > > > framebuffer. To fix that we need to update the plane_check code to
> > > > call drm_plane_helper_check_state() to clip the src and dst coordinates.
> > > > While there so some minor cleanup of redundant freeing of
> > > > devm_alloc-ated memory.
> > > 
> > > The following series is what I came up with, although I've had no time
> > > to test it.
> > 
> > I'm afraid I'm going to NAK this series. It would've been nicer for you to
> > comment on the v2 patch that I have sent rather than going around and coming
> > back with effectively the same thing but split into 2 patches. I'm having
> > trouble applying your series to the v4.11-rc4 (specially 2/3). Also 3/3 is
> > superfluous, as we don't expose the DRM_ROTATE property to userspace.
> 
> Rather than throwing accusations, let's look at what happened.

No accusations were thrown, just explanations of my decision.

> 
> I reported the bug on 18th November 2016 - I quote:
> 
>    Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
>    Surely this should be using src_[xy] (which are the position in the
>    source - iow, memory, and not crtc_[xy] which is the position on the
>    CRTC displayed window.  To put it another way, the src_* define the
>    region of the source material that is mapped onto a rectangular area
>    on the display defined by crtc_*.
> 
> This got ignored, and on 21st November, I came up with an initial patch
> to solve it at the time, but we were busy discussing the base address
> issue.

As I've replied to the 20th February email, I did not ignore it, just lost
track of it.

> 
> I sent a reminder on 20th February about it, and we discussed it, and I
> said at the time I did not have time to test your patch.  Ville commented
> on your patch, which confused me a little, but having worked it out, I
> reworked the patch from 21st November to fix that, creating this patch
> series.
> 
> I did not post it, because I hadn't tested it (since the Juno requires
> a long-winded way to update the kernel), so I never got around to
> testing this.  So, this series pre-dates your v2 patch by a good few
> weeks.

That information was privy to you and would've been nice to share with me.

> 
> You posted your v2 patch on March 8th, and I've not had a chance to
> test that, nor have I had a chance to test my own three patch series.
> 
> Today, I noticed that I still had the three patch series, so I thought
> I ought to get it out in the wild.

Hey, look, a clasic case of comedy of errors when people don't talk to each other!!!

Sorry, Russell, but I'm not inside your brain or your computer, so I don't know
intimately the history of things. Thanks for enlightening me but I also
read your story as a clear example why a small paragraph after the commit
log explaining why this series has been submitted would have gone a long
way clearing the fog.

> 
> Now, due to the amount of patches I carry:
> 
> $ git lg origin.. | wc -l
> 491
> 
> I work against Linus' tree _only_, so all patches I post are based on
> Linus' kernel, and not random other git trees.  I do not randomly fetch
> other git trees to base patches on them, because that would cause me
> insane merging issues so that I can test half the stuff I'm carrying.

I understand (to the best of my abilities) your position and the fact that
as a maintainer of a large subsystem you have a specific workflow that you
don't want to polute with minor exceptions. I would also ask you to understand
that not everyone works in the same way as you and that other maintainers
and other subsystems have different workflows and requirements. Having my
tree as part of the DRM subtree means that we work mostly on the recent
Linus' -rc up until about -rc4 and the quickly switch to linux-next. So one
way of approaching this is to drop the arch/arm frame of thought when
contributing to other trees and adopt their workflow (you know, the "when
in Rome, do what romans do" attitude). The other way is to go to different
maintainers and ask for special status and tell them that their puny drivers
and tree don't matter that much compared to your mighty workflow and they
should all bend to your greatness (the "all your bases belong to us" mindset).

> 
> Now, it's true that they're not against -rc, but are currently against
> 4.10 - it seems that I missed rebasing _this_ particular branch to
> 4.11-rc yet, although most of my other branches are.

And how would you have handled this situation? Another maintainer sending
you a patchset based on an older tree that doesn't match your currently
published one? Would you have gone to the trouble of rebasing their work,
or ask them do get back to you with a better series?

> 
> What was I so busy with when you posted your patch on the 8th March?
> Oh yes, that was the week _after_ the merge window closed, and was the
> week I was doing the mass rebase of about 500 patches.

I've seen people sending emails (not while they are busy, 8th March was 3
weeks prior to this whole thread) saying "I'm still interested in this, I
will test it when I get a chance". Or something more personal, like "I
already had something in my tree, if I don't get around testing your
patch then I will publish mine based on an old tree, so be prepared"

> 
> Sorry I didn't get around to testing your patch, and sorry for eventually
> getting around to posting my patches.  Obviously, I should just fuck off
> and do something else.

Please don't! I am happy that you show interest in this driver and you help
me improve it, and I do not wish to repeat the current conflict in the future.
I'm just hoping that we can improve the flow of information between us and
give you more peace of mind.

Best regards,
Liviu


> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> > > On Wed, Mar 08, 2017 at 04:30:25PM +0000, Liviu Dudau wrote:
> > > > The calculation of the framebuffer's start address was wrongly using
> > > > the CRTC's x and y position rather than the one of the source
> > > > framebuffer. To fix that we need to update the plane_check code to
> > > > call drm_plane_helper_check_state() to clip the src and dst coordinates.
> > > > While there so some minor cleanup of redundant freeing of
> > > > devm_alloc-ated memory.
> > > 
> > > The following series is what I came up with, although I've had no time
> > > to test it.
> > 
> > I'm afraid I'm going to NAK this series. It would've been nicer for you to
> > comment on the v2 patch that I have sent rather than going around and coming
> > back with effectively the same thing but split into 2 patches. I'm having
> > trouble applying your series to the v4.11-rc4 (specially 2/3). Also 3/3 is
> > superfluous, as we don't expose the DRM_ROTATE property to userspace.
> 
> Rather than throwing accusations, let's look at what happened.

No accusations were thrown, just explanations of my decision.

> 
> I reported the bug on 18th November 2016 - I quote:
> 
>    Something I also noticed is this:
> 
>         scanout_start = gem->paddr + plane->state->fb->offsets[0] +
>                 plane->state->crtc_y * plane->state->fb->pitches[0] +
>                 plane->state->crtc_x * bpp / 8;
> 
>    Surely this should be using src_[xy] (which are the position in the
>    source - iow, memory, and not crtc_[xy] which is the position on the
>    CRTC displayed window.  To put it another way, the src_* define the
>    region of the source material that is mapped onto a rectangular area
>    on the display defined by crtc_*.
> 
> This got ignored, and on 21st November, I came up with an initial patch
> to solve it at the time, but we were busy discussing the base address
> issue.

As I've replied to the 20th February email, I did not ignore it, just lost
track of it.

> 
> I sent a reminder on 20th February about it, and we discussed it, and I
> said at the time I did not have time to test your patch.  Ville commented
> on your patch, which confused me a little, but having worked it out, I
> reworked the patch from 21st November to fix that, creating this patch
> series.
> 
> I did not post it, because I hadn't tested it (since the Juno requires
> a long-winded way to update the kernel), so I never got around to
> testing this.  So, this series pre-dates your v2 patch by a good few
> weeks.

That information was privy to you and would've been nice to share with me.

> 
> You posted your v2 patch on March 8th, and I've not had a chance to
> test that, nor have I had a chance to test my own three patch series.
> 
> Today, I noticed that I still had the three patch series, so I thought
> I ought to get it out in the wild.

Hey, look, a clasic case of comedy of errors when people don't talk to each other!!!

Sorry, Russell, but I'm not inside your brain or your computer, so I don't know
intimately the history of things. Thanks for enlightening me but I also
read your story as a clear example why a small paragraph after the commit
log explaining why this series has been submitted would have gone a long
way clearing the fog.

> 
> Now, due to the amount of patches I carry:
> 
> $ git lg origin.. | wc -l
> 491
> 
> I work against Linus' tree _only_, so all patches I post are based on
> Linus' kernel, and not random other git trees.  I do not randomly fetch
> other git trees to base patches on them, because that would cause me
> insane merging issues so that I can test half the stuff I'm carrying.

I understand (to the best of my abilities) your position and the fact that
as a maintainer of a large subsystem you have a specific workflow that you
don't want to polute with minor exceptions. I would also ask you to understand
that not everyone works in the same way as you and that other maintainers
and other subsystems have different workflows and requirements. Having my
tree as part of the DRM subtree means that we work mostly on the recent
Linus' -rc up until about -rc4 and the quickly switch to linux-next. So one
way of approaching this is to drop the arch/arm frame of thought when
contributing to other trees and adopt their workflow (you know, the "when
in Rome, do what romans do" attitude). The other way is to go to different
maintainers and ask for special status and tell them that their puny drivers
and tree don't matter that much compared to your mighty workflow and they
should all bend to your greatness (the "all your bases belong to us" mindset).

> 
> Now, it's true that they're not against -rc, but are currently against
> 4.10 - it seems that I missed rebasing _this_ particular branch to
> 4.11-rc yet, although most of my other branches are.

And how would you have handled this situation? Another maintainer sending
you a patchset based on an older tree that doesn't match your currently
published one? Would you have gone to the trouble of rebasing their work,
or ask them do get back to you with a better series?

> 
> What was I so busy with when you posted your patch on the 8th March?
> Oh yes, that was the week _after_ the merge window closed, and was the
> week I was doing the mass rebase of about 500 patches.

I've seen people sending emails (not while they are busy, 8th March was 3
weeks prior to this whole thread) saying "I'm still interested in this, I
will test it when I get a chance". Or something more personal, like "I
already had something in my tree, if I don't get around testing your
patch then I will publish mine based on an old tree, so be prepared"

> 
> Sorry I didn't get around to testing your patch, and sorry for eventually
> getting around to posting my patches.  Obviously, I should just fuck off
> and do something else.

Please don't! I am happy that you show interest in this driver and you help
me improve it, and I do not wish to repeat the current conflict in the future.
I'm just hoping that we can improve the flow of information between us and
give you more peace of mind.

Best regards,
Liviu


> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Mon, Apr 03, 2017 at 11:31:34AM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> > I sent a reminder on 20th February about it, and we discussed it, and I
> > said at the time I did not have time to test your patch.  Ville commented
> > on your patch, which confused me a little, but having worked it out, I
> > reworked the patch from 21st November to fix that, creating this patch
> > series.
> > 
> > I did not post it, because I hadn't tested it (since the Juno requires
> > a long-winded way to update the kernel), so I never got around to
> > testing this.  So, this series pre-dates your v2 patch by a good few
> > weeks.
> 
> That information was privy to you and would've been nice to share with me.

So what the _hell_ do you think _this_ sentence means?  It _was_ shared
with you.

  The following series is what I came up with, although I've had no time
  to test it.

which was in the mail which was the parent to the series?  Does it
mean I'm bouncing a ball around the back yard maybe?

No, the information was there, you chose not to read it, and *you*
fucked up.  Notice that it is PAST TENSE, which means it HAPPENED IN
THE PAST.  NOT PRESENT.  This is basic english comprehension.

> > Now, due to the amount of patches I carry:
> > 
> > $ git lg origin.. | wc -l
> > 491
> > 
> > I work against Linus' tree _only_, so all patches I post are based on
> > Linus' kernel, and not random other git trees.  I do not randomly fetch
> > other git trees to base patches on them, because that would cause me
> > insane merging issues so that I can test half the stuff I'm carrying.
> 
> I understand (to the best of my abilities) your position and the fact that
> as a maintainer of a large subsystem you have a specific workflow that you
> don't want to polute with minor exceptions. I would also ask you to understand
> that not everyone works in the same way as you and that other maintainers
> and other subsystems have different workflows and requirements. Having my
> tree as part of the DRM subtree means that we work mostly on the recent
> Linus' -rc up until about -rc4 and the quickly switch to linux-next. So one
> way of approaching this is to drop the arch/arm frame of thought when
> contributing to other trees and adopt their workflow (you know, the "when
> in Rome, do what romans do" attitude). The other way is to go to different
> maintainers and ask for special status and tell them that their puny drivers
> and tree don't matter that much compared to your mighty workflow and they
> should all bend to your greatness (the "all your bases belong to us" mindset).

For christ sake, I sent the patches out because I thought it would be
useful to show what I had come up with, because I believed it to be of
use.

I won't make that mistake again, I'll just delete such work, because
it's obviously far too much hassle to work with other people, because
they don't READ.

> > Now, it's true that they're not against -rc, but are currently against
> > 4.10 - it seems that I missed rebasing _this_ particular branch to
> > 4.11-rc yet, although most of my other branches are.
> 
> And how would you have handled this situation? Another maintainer sending
> you a patchset based on an older tree that doesn't match your currently
> published one? Would you have gone to the trouble of rebasing their work,
> or ask them do get back to you with a better series?

If the other work is better, then I would have replaced what I had
already merged with the better version, or ask for an update against
the current version.

I doubt that I'm going to get any time what so ever to test either
version, so I'm going to delete my version and wait for your version
to trickle through - which I guess will be in about two months time,
after the next merge window.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Mon, Apr 03, 2017 at 11:31:34AM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> > I sent a reminder on 20th February about it, and we discussed it, and I
> > said at the time I did not have time to test your patch.  Ville commented
> > on your patch, which confused me a little, but having worked it out, I
> > reworked the patch from 21st November to fix that, creating this patch
> > series.
> > 
> > I did not post it, because I hadn't tested it (since the Juno requires
> > a long-winded way to update the kernel), so I never got around to
> > testing this.  So, this series pre-dates your v2 patch by a good few
> > weeks.
> 
> That information was privy to you and would've been nice to share with me.

So what the _hell_ do you think _this_ sentence means?  It _was_ shared
with you.

  The following series is what I came up with, although I've had no time
  to test it.

which was in the mail which was the parent to the series?  Does it
mean I'm bouncing a ball around the back yard maybe?

No, the information was there, you chose not to read it, and *you*
fucked up.  Notice that it is PAST TENSE, which means it HAPPENED IN
THE PAST.  NOT PRESENT.  This is basic english comprehension.

> > Now, due to the amount of patches I carry:
> > 
> > $ git lg origin.. | wc -l
> > 491
> > 
> > I work against Linus' tree _only_, so all patches I post are based on
> > Linus' kernel, and not random other git trees.  I do not randomly fetch
> > other git trees to base patches on them, because that would cause me
> > insane merging issues so that I can test half the stuff I'm carrying.
> 
> I understand (to the best of my abilities) your position and the fact that
> as a maintainer of a large subsystem you have a specific workflow that you
> don't want to polute with minor exceptions. I would also ask you to understand
> that not everyone works in the same way as you and that other maintainers
> and other subsystems have different workflows and requirements. Having my
> tree as part of the DRM subtree means that we work mostly on the recent
> Linus' -rc up until about -rc4 and the quickly switch to linux-next. So one
> way of approaching this is to drop the arch/arm frame of thought when
> contributing to other trees and adopt their workflow (you know, the "when
> in Rome, do what romans do" attitude). The other way is to go to different
> maintainers and ask for special status and tell them that their puny drivers
> and tree don't matter that much compared to your mighty workflow and they
> should all bend to your greatness (the "all your bases belong to us" mindset).

For christ sake, I sent the patches out because I thought it would be
useful to show what I had come up with, because I believed it to be of
use.

I won't make that mistake again, I'll just delete such work, because
it's obviously far too much hassle to work with other people, because
they don't READ.

> > Now, it's true that they're not against -rc, but are currently against
> > 4.10 - it seems that I missed rebasing _this_ particular branch to
> > 4.11-rc yet, although most of my other branches are.
> 
> And how would you have handled this situation? Another maintainer sending
> you a patchset based on an older tree that doesn't match your currently
> published one? Would you have gone to the trouble of rebasing their work,
> or ask them do get back to you with a better series?

If the other work is better, then I would have replaced what I had
already merged with the better version, or ask for an update against
the current version.

I doubt that I'm going to get any time what so ever to test either
version, so I'm going to delete my version and wait for your version
to trickle through - which I guess will be in about two months time,
after the next merge window.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

On Mon, Apr 03, 2017 at 02:13:48PM +0100, Russell King - ARM Linux wrote:
> On Mon, Apr 03, 2017 at 11:31:34AM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> > > I sent a reminder on 20th February about it, and we discussed it, and I
> > > said at the time I did not have time to test your patch.  Ville commented
> > > on your patch, which confused me a little, but having worked it out, I
> > > reworked the patch from 21st November to fix that, creating this patch
> > > series.
> > > 
> > > I did not post it, because I hadn't tested it (since the Juno requires
> > > a long-winded way to update the kernel), so I never got around to
> > > testing this.  So, this series pre-dates your v2 patch by a good few
> > > weeks.
> > 
> > That information was privy to you and would've been nice to share with me.
> 
> So what the _hell_ do you think _this_ sentence means?  It _was_ shared
> with you.
> 
>   The following series is what I came up with, although I've had no time
>   to test it.
> 
> which was in the mail which was the parent to the series?  Does it
> mean I'm bouncing a ball around the back yard maybe?
> 
> No, the information was there, you chose not to read it, and *you*
> fucked up.  Notice that it is PAST TENSE, which means it HAPPENED IN
> THE PAST.  NOT PRESENT.  This is basic english comprehension.

Hey, you fail basic english comprehension too! My sentence was referring to your
last sentence: "So, this series pre-dates your v2 patch by a good few weeks."
That was the information that you have failed to share.

> 
> > > Now, due to the amount of patches I carry:
> > > 
> > > $ git lg origin.. | wc -l
> > > 491
> > > 
> > > I work against Linus' tree _only_, so all patches I post are based on
> > > Linus' kernel, and not random other git trees.  I do not randomly fetch
> > > other git trees to base patches on them, because that would cause me
> > > insane merging issues so that I can test half the stuff I'm carrying.
> > 
> > I understand (to the best of my abilities) your position and the fact that
> > as a maintainer of a large subsystem you have a specific workflow that you
> > don't want to polute with minor exceptions. I would also ask you to understand
> > that not everyone works in the same way as you and that other maintainers
> > and other subsystems have different workflows and requirements. Having my
> > tree as part of the DRM subtree means that we work mostly on the recent
> > Linus' -rc up until about -rc4 and the quickly switch to linux-next. So one
> > way of approaching this is to drop the arch/arm frame of thought when
> > contributing to other trees and adopt their workflow (you know, the "when
> > in Rome, do what romans do" attitude). The other way is to go to different
> > maintainers and ask for special status and tell them that their puny drivers
> > and tree don't matter that much compared to your mighty workflow and they
> > should all bend to your greatness (the "all your bases belong to us" mindset).
> 
> For christ sake, I sent the patches out because I thought it would be
> useful to show what I had come up with, because I believed it to be of
> use.
> 
> I won't make that mistake again, I'll just delete such work, because
> it's obviously far too much hassle to work with other people, because
> they don't READ.
> 
> > > Now, it's true that they're not against -rc, but are currently against
> > > 4.10 - it seems that I missed rebasing _this_ particular branch to
> > > 4.11-rc yet, although most of my other branches are.
> > 
> > And how would you have handled this situation? Another maintainer sending
> > you a patchset based on an older tree that doesn't match your currently
> > published one? Would you have gone to the trouble of rebasing their work,
> > or ask them do get back to you with a better series?
> 
> If the other work is better, then I would have replaced what I had
> already merged with the better version, or ask for an update against
> the current version.
> 
> I doubt that I'm going to get any time what so ever to test either
> version, so I'm going to delete my version and wait for your version
> to trickle through - which I guess will be in about two months time,
> after the next merge window.

Good. Thanks!

Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Liviu Dudau]

On Mon, Apr 03, 2017 at 02:13:48PM +0100, Russell King - ARM Linux wrote:
> On Mon, Apr 03, 2017 at 11:31:34AM +0100, Liviu Dudau wrote:
> > On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote:
> > > I sent a reminder on 20th February about it, and we discussed it, and I
> > > said at the time I did not have time to test your patch.  Ville commented
> > > on your patch, which confused me a little, but having worked it out, I
> > > reworked the patch from 21st November to fix that, creating this patch
> > > series.
> > > 
> > > I did not post it, because I hadn't tested it (since the Juno requires
> > > a long-winded way to update the kernel), so I never got around to
> > > testing this.  So, this series pre-dates your v2 patch by a good few
> > > weeks.
> > 
> > That information was privy to you and would've been nice to share with me.
> 
> So what the _hell_ do you think _this_ sentence means?  It _was_ shared
> with you.
> 
>   The following series is what I came up with, although I've had no time
>   to test it.
> 
> which was in the mail which was the parent to the series?  Does it
> mean I'm bouncing a ball around the back yard maybe?
> 
> No, the information was there, you chose not to read it, and *you*
> fucked up.  Notice that it is PAST TENSE, which means it HAPPENED IN
> THE PAST.  NOT PRESENT.  This is basic english comprehension.

Hey, you fail basic english comprehension too! My sentence was referring to your
last sentence: "So, this series pre-dates your v2 patch by a good few weeks."
That was the information that you have failed to share.

> 
> > > Now, due to the amount of patches I carry:
> > > 
> > > $ git lg origin.. | wc -l
> > > 491
> > > 
> > > I work against Linus' tree _only_, so all patches I post are based on
> > > Linus' kernel, and not random other git trees.  I do not randomly fetch
> > > other git trees to base patches on them, because that would cause me
> > > insane merging issues so that I can test half the stuff I'm carrying.
> > 
> > I understand (to the best of my abilities) your position and the fact that
> > as a maintainer of a large subsystem you have a specific workflow that you
> > don't want to polute with minor exceptions. I would also ask you to understand
> > that not everyone works in the same way as you and that other maintainers
> > and other subsystems have different workflows and requirements. Having my
> > tree as part of the DRM subtree means that we work mostly on the recent
> > Linus' -rc up until about -rc4 and the quickly switch to linux-next. So one
> > way of approaching this is to drop the arch/arm frame of thought when
> > contributing to other trees and adopt their workflow (you know, the "when
> > in Rome, do what romans do" attitude). The other way is to go to different
> > maintainers and ask for special status and tell them that their puny drivers
> > and tree don't matter that much compared to your mighty workflow and they
> > should all bend to your greatness (the "all your bases belong to us" mindset).
> 
> For christ sake, I sent the patches out because I thought it would be
> useful to show what I had come up with, because I believed it to be of
> use.
> 
> I won't make that mistake again, I'll just delete such work, because
> it's obviously far too much hassle to work with other people, because
> they don't READ.
> 
> > > Now, it's true that they're not against -rc, but are currently against
> > > 4.10 - it seems that I missed rebasing _this_ particular branch to
> > > 4.11-rc yet, although most of my other branches are.
> > 
> > And how would you have handled this situation? Another maintainer sending
> > you a patchset based on an older tree that doesn't match your currently
> > published one? Would you have gone to the trouble of rebasing their work,
> > or ask them do get back to you with a better series?
> 
> If the other work is better, then I would have replaced what I had
> already merged with the better version, or ask for an update against
> the current version.
> 
> I doubt that I'm going to get any time what so ever to test either
> version, so I'm going to delete my version and wait for your version
> to trickle through - which I guess will be in about two months time,
> after the next merge window.

Good. Thanks!

Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Jani Nikula]

On Mon, 03 Apr 2017, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> So what the _hell_ do you think _this_ sentence means?  It _was_ shared
> with you.
>
>   The following series is what I came up with, although I've had no time
>   to test it.
>
> which was in the mail which was the parent to the series?  Does it
> mean I'm bouncing a ball around the back yard maybe?
>
> No, the information was there, you chose not to read it, and *you*
> fucked up.  Notice that it is PAST TENSE, which means it HAPPENED IN
> THE PAST.  NOT PRESENT.  This is basic english comprehension.

[...]

> For christ sake, I sent the patches out because I thought it would be
> useful to show what I had come up with, because I believed it to be of
> use.
>
> I won't make that mistake again, I'll just delete such work, because
> it's obviously far too much hassle to work with other people, because
> they don't READ.

Please keep the discussion civil. We try to maintain a friendly
collaborative atmosphere on dri-devel, and this kind of interaction is
not welcome in our community. Thanks for your understanding.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Jani Nikula]

On Mon, 03 Apr 2017, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> So what the _hell_ do you think _this_ sentence means?  It _was_ shared
> with you.
>
>   The following series is what I came up with, although I've had no time
>   to test it.
>
> which was in the mail which was the parent to the series?  Does it
> mean I'm bouncing a ball around the back yard maybe?
>
> No, the information was there, you chose not to read it, and *you*
> fucked up.  Notice that it is PAST TENSE, which means it HAPPENED IN
> THE PAST.  NOT PRESENT.  This is basic english comprehension.

[...]

> For christ sake, I sent the patches out because I thought it would be
> useful to show what I had come up with, because I believed it to be of
> use.
>
> I won't make that mistake again, I'll just delete such work, because
> it's obviously far too much hassle to work with other people, because
> they don't READ.

Please keep the discussion civil. We try to maintain a friendly
collaborative atmosphere on dri-devel, and this kind of interaction is
not welcome in our community. Thanks for your understanding.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel