| Message ID | 1353613037-15808-1-git-send-email-thierry.reding@avionic-design.de (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On 22.11.2012 21:37, Thierry Reding wrote: > Instead of using the stride derived from the display mode, use the pitch > associated with the currently active framebuffer. This fixes a bug where > the LCD display content would be skewed when enabling HDMI with a video > mode different from that of the LCD. > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Hi, I tested and verified that this fixes our stride problem. Thanks! Tested-by: Terje Bergstrom <tbergstrom@nvidia.com>
Tested-by: Mark Zhang <markz@nvidia.com> On my Tegra 3 cardhu. Mark On 11/23/2012 03:37 AM, Thierry Reding wrote: > Instead of using the stride derived from the display mode, use the pitch > associated with the currently active framebuffer. This fixes a bug where > the LCD display content would be skewed when enabling HDMI with a video > mode different from that of the LCD. > > Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> > --- > drivers/gpu/drm/tegra/dc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c > index 94686e5..41cde76 100644 > --- a/drivers/gpu/drm/tegra/dc.c > +++ b/drivers/gpu/drm/tegra/dc.c > @@ -218,7 +218,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc, > } > > bpp = crtc->fb->bits_per_pixel / 8; > - win.stride = win.outw * bpp; > + win.stride = crtc->fb->pitches[0]; > > /* program window registers */ > value = tegra_dc_readl(dc, DC_CMD_DISPLAY_WINDOW_HEADER); >
On 11/22/2012 12:37 PM, Thierry Reding wrote: > Instead of using the stride derived from the display mode, use the pitch > associated with the currently active framebuffer. This fixes a bug where > the LCD display content would be skewed when enabling HDMI with a video > mode different from that of the LCD. This patch certainly doesn't cause any additional issues for me, so: Tested-by: Stephen Warren <swarren@nvidia.com> Howwever, it still doesn't allow both Cardhu's LCD panel and external HDMI port (1080p) to be active at once. If I boot with both enabled, or boot with just the LCD enabled and hot-plug HDMI, as soon as both heads are active, then some kind of display corruption starts; it looks like a clocking issue or perhaps memory underflow. Mark, can you please investigate this. I haven't tested to see if the issue is Tegra30-specific, or also happens on Tegra20.
On 11/27/2012 06:37 AM, Stephen Warren wrote: > On 11/22/2012 12:37 PM, Thierry Reding wrote: >> Instead of using the stride derived from the display mode, use the pitch >> associated with the currently active framebuffer. This fixes a bug where >> the LCD display content would be skewed when enabling HDMI with a video >> mode different from that of the LCD. > > This patch certainly doesn't cause any additional issues for me, so: > > Tested-by: Stephen Warren <swarren@nvidia.com> > > Howwever, it still doesn't allow both Cardhu's LCD panel and external > HDMI port (1080p) to be active at once. If I boot with both enabled, or > boot with just the LCD enabled and hot-plug HDMI, as soon as both heads > are active, then some kind of display corruption starts; it looks like a > clocking issue or perhaps memory underflow. > I haven't observed this issue. What kind of display corruption you mean? Did it recover after some seconds or the display in LVDS panel was always corrupted? During my testing, I connected HDMI while booting cardhu and I can see the LVDS and HDMI working with no corruptions. > Mark, can you please investigate this. I haven't tested to see if the > issue is Tegra30-specific, or also happens on Tegra20. >
On 11/26/2012 08:16 PM, Mark Zhang wrote: > On 11/27/2012 06:37 AM, Stephen Warren wrote: >> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>> Instead of using the stride derived from the display mode, use the pitch >>> associated with the currently active framebuffer. This fixes a bug where >>> the LCD display content would be skewed when enabling HDMI with a video >>> mode different from that of the LCD. >> >> This patch certainly doesn't cause any additional issues for me, so: >> >> Tested-by: Stephen Warren <swarren@nvidia.com> >> >> Howwever, it still doesn't allow both Cardhu's LCD panel and external >> HDMI port (1080p) to be active at once. If I boot with both enabled, or >> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads >> are active, then some kind of display corruption starts; it looks like a >> clocking issue or perhaps memory underflow. > > I haven't observed this issue. What kind of display corruption you mean? > Did it recover after some seconds or the display in LVDS panel was > always corrupted? > > During my testing, I connected HDMI while booting cardhu and I can see > the LVDS and HDMI working with no corruptions. For your viewing pleasure (and playing with my new phone) :-) http://www.youtube.com/watch?v=ZJxJnONz7DA The external monitor is 1920x1200 I believe.
On 11/27/2012 11:17 AM, Stephen Warren wrote: > On 11/26/2012 08:16 PM, Mark Zhang wrote: >> On 11/27/2012 06:37 AM, Stephen Warren wrote: >>> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>>> Instead of using the stride derived from the display mode, use the pitch >>>> associated with the currently active framebuffer. This fixes a bug where >>>> the LCD display content would be skewed when enabling HDMI with a video >>>> mode different from that of the LCD. >>> >>> This patch certainly doesn't cause any additional issues for me, so: >>> >>> Tested-by: Stephen Warren <swarren@nvidia.com> >>> >>> Howwever, it still doesn't allow both Cardhu's LCD panel and external >>> HDMI port (1080p) to be active at once. If I boot with both enabled, or >>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads >>> are active, then some kind of display corruption starts; it looks like a >>> clocking issue or perhaps memory underflow. >> >> I haven't observed this issue. What kind of display corruption you mean? >> Did it recover after some seconds or the display in LVDS panel was >> always corrupted? >> >> During my testing, I connected HDMI while booting cardhu and I can see >> the LVDS and HDMI working with no corruptions. > > For your viewing pleasure (and playing with my new phone) :-) > http://www.youtube.com/watch?v=ZJxJnONz7DA > > The external monitor is 1920x1200 I believe. Jon Mayo says the corruption in the video is display (memory fetch) underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu programs the memory controller at a slow rate, and the bootloader and/or kernel is supposed to bump up the rate to the max, but that's not implemented anywhere yet upstream. If you're testing with "fastboot" instead of U-Boot, that might be re-programming the memory frequencies, and hence avoiding this. I guess we have a fun time ahead of us with mode validation and memory controller programming.
Am Dienstag, den 27.11.2012, 14:39 -0700 schrieb Stephen Warren: > > For your viewing pleasure (and playing with my new phone) :-) > > http://www.youtube.com/watch?v=ZJxJnONz7DA > > > > The external monitor is 1920x1200 I believe. > > Jon Mayo says the corruption in the video is display (memory fetch) > underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu > programs the memory controller at a slow rate, and the bootloader and/or > kernel is supposed to bump up the rate to the max, but that's not > implemented anywhere yet upstream. If you're testing with "fastboot" > instead of U-Boot, that might be re-programming the memory frequencies, > and hence avoiding this. > > I guess we have a fun time ahead of us with mode validation and memory > controller programming. Maybe it's not insufficient memory bandwidth, but just the request missing the deadline in the memory controller. You may try to adjust the values in reg MC_LATENCY_ALLOWANCE_DC_0_0 for example. Regards, Lucas
On 11/28/2012 05:39 AM, Stephen Warren wrote: > On 11/27/2012 11:17 AM, Stephen Warren wrote: >> On 11/26/2012 08:16 PM, Mark Zhang wrote: >>> On 11/27/2012 06:37 AM, Stephen Warren wrote: >>>> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>>>> Instead of using the stride derived from the display mode, use the pitch >>>>> associated with the currently active framebuffer. This fixes a bug where >>>>> the LCD display content would be skewed when enabling HDMI with a video >>>>> mode different from that of the LCD. >>>> >>>> This patch certainly doesn't cause any additional issues for me, so: >>>> >>>> Tested-by: Stephen Warren <swarren@nvidia.com> >>>> >>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external >>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or >>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads >>>> are active, then some kind of display corruption starts; it looks like a >>>> clocking issue or perhaps memory underflow. >>> >>> I haven't observed this issue. What kind of display corruption you mean? >>> Did it recover after some seconds or the display in LVDS panel was >>> always corrupted? >>> >>> During my testing, I connected HDMI while booting cardhu and I can see >>> the LVDS and HDMI working with no corruptions. >> >> For your viewing pleasure (and playing with my new phone) :-) >> http://www.youtube.com/watch?v=ZJxJnONz7DA >> >> The external monitor is 1920x1200 I believe. > > Jon Mayo says the corruption in the video is display (memory fetch) > underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu > programs the memory controller at a slow rate, and the bootloader and/or > kernel is supposed to bump up the rate to the max, but that's not > implemented anywhere yet upstream. If you're testing with "fastboot" > instead of U-Boot, that might be re-programming the memory frequencies, > and hence avoiding this. > All right, I just test the framebuffer console and "xinit", I didn't install the whole ubuntu. I'll install the ubuntu in my cardhu and see whether I have this kind of issues. Mark > I guess we have a fun time ahead of us with mode validation and memory > controller programming. > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On 11/28/2012 02:37 PM, Mark Zhang wrote: > On 11/28/2012 05:39 AM, Stephen Warren wrote: >> On 11/27/2012 11:17 AM, Stephen Warren wrote: >>> On 11/26/2012 08:16 PM, Mark Zhang wrote: >>>> On 11/27/2012 06:37 AM, Stephen Warren wrote: >>>>> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>>>>> Instead of using the stride derived from the display mode, use the pitch >>>>>> associated with the currently active framebuffer. This fixes a bug where >>>>>> the LCD display content would be skewed when enabling HDMI with a video >>>>>> mode different from that of the LCD. >>>>> >>>>> This patch certainly doesn't cause any additional issues for me, so: >>>>> >>>>> Tested-by: Stephen Warren <swarren@nvidia.com> >>>>> >>>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external >>>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or >>>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads >>>>> are active, then some kind of display corruption starts; it looks like a >>>>> clocking issue or perhaps memory underflow. >>>> >>>> I haven't observed this issue. What kind of display corruption you mean? >>>> Did it recover after some seconds or the display in LVDS panel was >>>> always corrupted? >>>> >>>> During my testing, I connected HDMI while booting cardhu and I can see >>>> the LVDS and HDMI working with no corruptions. >>> >>> For your viewing pleasure (and playing with my new phone) :-) >>> http://www.youtube.com/watch?v=ZJxJnONz7DA >>> >>> The external monitor is 1920x1200 I believe. >> >> Jon Mayo says the corruption in the video is display (memory fetch) >> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu >> programs the memory controller at a slow rate, and the bootloader and/or >> kernel is supposed to bump up the rate to the max, but that's not >> implemented anywhere yet upstream. If you're testing with "fastboot" >> instead of U-Boot, that might be re-programming the memory frequencies, >> and hence avoiding this. >> > > All right, I just test the framebuffer console and "xinit", I didn't > install the whole ubuntu. > > I'll install the ubuntu in my cardhu and see whether I have this kind of > issues. Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue you described. The display worked with no corruptions. I can show you the video if you want. What I used for testing is a cardhu board with our downstream U-Boot. But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080@60HZ". So sounds like the clock setting has some problems... I'll have a look at this. Mark > > Mark >> I guess we have a fun time ahead of us with mode validation and memory >> controller programming. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >>
On 12/03/2012 08:00 PM, Mark Zhang wrote: > On 11/28/2012 02:37 PM, Mark Zhang wrote: >> On 11/28/2012 05:39 AM, Stephen Warren wrote: >>> On 11/27/2012 11:17 AM, Stephen Warren wrote: >>>> On 11/26/2012 08:16 PM, Mark Zhang wrote: >>>>> On 11/27/2012 06:37 AM, Stephen Warren wrote: >>>>>> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>>>>>> Instead of using the stride derived from the display mode, use the pitch >>>>>>> associated with the currently active framebuffer. This fixes a bug where >>>>>>> the LCD display content would be skewed when enabling HDMI with a video >>>>>>> mode different from that of the LCD. >>>>>> >>>>>> This patch certainly doesn't cause any additional issues for me, so: >>>>>> >>>>>> Tested-by: Stephen Warren <swarren@nvidia.com> >>>>>> >>>>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external >>>>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or >>>>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads >>>>>> are active, then some kind of display corruption starts; it looks like a >>>>>> clocking issue or perhaps memory underflow. >>>>> >>>>> I haven't observed this issue. What kind of display corruption you mean? >>>>> Did it recover after some seconds or the display in LVDS panel was >>>>> always corrupted? >>>>> >>>>> During my testing, I connected HDMI while booting cardhu and I can see >>>>> the LVDS and HDMI working with no corruptions. >>>> >>>> For your viewing pleasure (and playing with my new phone) :-) >>>> http://www.youtube.com/watch?v=ZJxJnONz7DA >>>> >>>> The external monitor is 1920x1200 I believe. >>> >>> Jon Mayo says the corruption in the video is display (memory fetch) >>> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu >>> programs the memory controller at a slow rate, and the bootloader and/or >>> kernel is supposed to bump up the rate to the max, but that's not >>> implemented anywhere yet upstream. If you're testing with "fastboot" >>> instead of U-Boot, that might be re-programming the memory frequencies, >>> and hence avoiding this. >>> >> >> All right, I just test the framebuffer console and "xinit", I didn't >> install the whole ubuntu. >> >> I'll install the ubuntu in my cardhu and see whether I have this kind of >> issues. > > Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue > you described. The display worked with no corruptions. I can show you > the video if you want. > > What I used for testing is a cardhu board with our downstream U-Boot. > > But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY > THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080@60HZ". So > sounds like the clock setting has some problems... I'll have a look at this. Oh, I thought I'd followed up on this - Jon Mayo said it was display underflow due to lack of memory bandwidth. IIRC, this may be due to the BCT programming the memory controller for conservative settings that don't require non-default voltages from the PMIC, with the expectation that the bootloader or kernel will reprogram everything for correct performance.
On 12/04/2012 11:50 AM, Stephen Warren wrote: > On 12/03/2012 08:00 PM, Mark Zhang wrote: >> On 11/28/2012 02:37 PM, Mark Zhang wrote: >>> On 11/28/2012 05:39 AM, Stephen Warren wrote: >>>> On 11/27/2012 11:17 AM, Stephen Warren wrote: >>>>> On 11/26/2012 08:16 PM, Mark Zhang wrote: >>>>>> On 11/27/2012 06:37 AM, Stephen Warren wrote: >>>>>>> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>>>>>>> Instead of using the stride derived from the display mode, use the pitch >>>>>>>> associated with the currently active framebuffer. This fixes a bug where >>>>>>>> the LCD display content would be skewed when enabling HDMI with a video >>>>>>>> mode different from that of the LCD. >>>>>>> >>>>>>> This patch certainly doesn't cause any additional issues for me, so: >>>>>>> >>>>>>> Tested-by: Stephen Warren <swarren@nvidia.com> >>>>>>> >>>>>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external >>>>>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or >>>>>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads >>>>>>> are active, then some kind of display corruption starts; it looks like a >>>>>>> clocking issue or perhaps memory underflow. >>>>>> >>>>>> I haven't observed this issue. What kind of display corruption you mean? >>>>>> Did it recover after some seconds or the display in LVDS panel was >>>>>> always corrupted? >>>>>> >>>>>> During my testing, I connected HDMI while booting cardhu and I can see >>>>>> the LVDS and HDMI working with no corruptions. >>>>> >>>>> For your viewing pleasure (and playing with my new phone) :-) >>>>> http://www.youtube.com/watch?v=ZJxJnONz7DA >>>>> >>>>> The external monitor is 1920x1200 I believe. >>>> >>>> Jon Mayo says the corruption in the video is display (memory fetch) >>>> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu >>>> programs the memory controller at a slow rate, and the bootloader and/or >>>> kernel is supposed to bump up the rate to the max, but that's not >>>> implemented anywhere yet upstream. If you're testing with "fastboot" >>>> instead of U-Boot, that might be re-programming the memory frequencies, >>>> and hence avoiding this. >>>> >>> >>> All right, I just test the framebuffer console and "xinit", I didn't >>> install the whole ubuntu. >>> >>> I'll install the ubuntu in my cardhu and see whether I have this kind of >>> issues. >> >> Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue >> you described. The display worked with no corruptions. I can show you >> the video if you want. >> >> What I used for testing is a cardhu board with our downstream U-Boot. >> >> But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY >> THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080@60HZ". So >> sounds like the clock setting has some problems... I'll have a look at this. > > Oh, I thought I'd followed up on this - Jon Mayo said it was display > underflow due to lack of memory bandwidth. IIRC, this may be due to the > BCT programming the memory controller for conservative settings that > don't require non-default voltages from the PMIC, with the expectation > that the bootloader or kernel will reprogram everything for correct > performance. > OK, I see. But my HDMI doesn't work so I will spend some time digging it. Mark
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 94686e5..41cde76 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -218,7 +218,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc, } bpp = crtc->fb->bits_per_pixel / 8; - win.stride = win.outw * bpp; + win.stride = crtc->fb->pitches[0]; /* program window registers */ value = tegra_dc_readl(dc, DC_CMD_DISPLAY_WINDOW_HEADER);
Instead of using the stride derived from the display mode, use the pitch associated with the currently active framebuffer. This fixes a bug where the LCD display content would be skewed when enabling HDMI with a video mode different from that of the LCD. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> --- drivers/gpu/drm/tegra/dc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)