[PATCH 0/6] ARM: davinci: da850-lcdk: add support for tilcdc

[PATCH 0/6] ARM: davinci: da850-lcdk: add support for tilcdc

[Bartosz Golaszewski]

This series enables the tilcdc support for da850-lcdk. Besides the
device tree changes it contains some tweaks needed to make it work.

Tested with a da850-lcdk board with an LCD display connected over
VGA with the following modes:

  modetest -M tilcdc -s 26:800x600 at RG16
  modetest -M tilcdc -s 26:1024x768 at RG16

Rebased on top of some necessary changes in the tilcdc drm driver.
These changes will go upstream through the drm tree.

Bartosz Golaszewski (3):
  ARM: dts: da850-lcdk: add support for 1024x768 resolution
  ARM: davinci: enable the LCDC DRM driver in defconfig
  ARM: da850: adjust memory settings for tilcdc

Karl Beldan (3):
  ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc
  ARM: dts: da850: add a node for the LCD controller
  ARM: dts: da850-lcdk: enable the LCD controller

 arch/arm/boot/dts/da850-lcdk.dts           | 71 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/da850.dtsi               |  8 ++++
 arch/arm/configs/davinci_all_defconfig     |  2 +
 arch/arm/mach-davinci/da8xx-dt.c           | 44 ++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |  4 ++
 5 files changed, 129 insertions(+)

-- 
2.7.4

[PATCH 1/6] ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for lcdc

[Bartosz Golaszewski]

From: Karl Beldan <kbeldan@baylibre.com>

This is required for tilcdc to be able to acquire a functional clock.

Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
[Bartosz: added the commit description]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e92..f8ecc02 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -38,6 +38,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 		       NULL),
 	OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
 	OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+	OF_DEV_AUXDATA("ti,am33xx-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
 	{}
 };
 
-- 
2.7.4

[PATCH 2/6] ARM: dts: da850: add a node for the LCD controller

[Bartosz Golaszewski]

From: Karl Beldan <kbeldan@baylibre.com>

Add a disabled LCDC node to be reused in device trees including
da850.dtsi for boards equipped with tilcdc enabled.

Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
[Bartosz: added the commit description]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/boot/dts/da850.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..9f39296 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -399,6 +399,14 @@
 				<&edma0 0 1>;
 			dma-names = "tx", "rx";
 		};
+
+		lcdc: lcdc at 213000 {
+			compatible = "ti,am33xx-tilcdc";
+			reg = <0x213000 0x1000>;
+			interrupt-parent = <&intc>;
+			interrupts = <52>;
+			status = "disabled";
+		};
 	};
 	aemif: aemif at 68000000 {
 		compatible = "ti,da850-aemif";
-- 
2.7.4

[PATCH 2/6] ARM: dts: da850: add a node for the LCD controller

[Sekhar Nori]

On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
> 
> Add a disabled LCDC node to be reused in device trees including
> da850.dtsi for boards equipped with tilcdc enabled.
> 
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [Bartosz: added the commit description]
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b9..9f39296 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -399,6 +399,14 @@
>  				<&edma0 0 1>;
>  			dma-names = "tx", "rx";
>  		};
> +
> +		lcdc: lcdc at 213000 {

node name should be generic per the ePAPR so please use "display".

> +			compatible = "ti,am33xx-tilcdc";

Can you please introduce a da850 specific compatible. Something like:

compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";

Even if you dont use it in the driver today, please have it in the .dts
I am pretty sure there will be some da850 specific tweak required for
the LCDC at some point. Having a compatible already in place will make
migration easier. You will have to document the compatible though.

This will affect 1/6 too.

Thanks,
Sekhar

[PATCH 2/6] ARM: dts: da850: add a node for the LCD controller

[Bartosz Golaszewski]

2016-09-30 11:34 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
>> From: Karl Beldan <kbeldan@baylibre.com>
>>
>> Add a disabled LCDC node to be reused in device trees including
>> da850.dtsi for boards equipped with tilcdc enabled.
>>
>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>> [Bartosz: added the commit description]
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>>  arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..9f39296 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -399,6 +399,14 @@
>>                               <&edma0 0 1>;
>>                       dma-names = "tx", "rx";
>>               };
>> +
>> +             lcdc: lcdc at 213000 {
>
> node name should be generic per the ePAPR so please use "display".
>
>> +                     compatible = "ti,am33xx-tilcdc";
>
> Can you please introduce a da850 specific compatible. Something like:
>
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>

I sent a relevant patch to the drm mailing list.

> Even if you dont use it in the driver today, please have it in the .dts
> I am pretty sure there will be some da850 specific tweak required for
> the LCDC at some point. Having a compatible already in place will make
> migration easier. You will have to document the compatible though.
>
> This will affect 1/6 too.
>

I'll include these changes in v2.

Thanks,
Bartosz

[PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller

[Bartosz Golaszewski]

From: Karl Beldan <kbeldan@baylibre.com>

This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
with some default timings for 800x600.

Tested on an LCDK connected on the VGA port (the LCDC is connected to
this port via a THS8135).

Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
[Bartosz:
  - fixed whitespace errors
  - tweaked the description
  - fixed the incorrect hback-porch value
  - other minor tweaks]
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/boot/dts/da850-lcdk.dts | 60 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..6ca5d48 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -50,6 +50,40 @@
 			system-clock-frequency = <24576000>;
 		};
 	};
+
+	panel {
+		compatible = "ti,tilcdc,panel";
+		pinctrl-names = "default";
+		pinctrl-0 = <&lcd_pins>;
+		status = "okay";
+
+		panel-info {
+			ac-bias           = <0>;
+			ac-bias-intrpt    = <0>;
+			dma-burst-sz      = <16>;
+			bpp               = <16>;
+			fdd               = <255>;
+			sync-edge         = <0>;
+			sync-ctrl         = <0>;
+			raster-order      = <0>;
+			fifo-th           = <5>;
+		};
+
+		display-timings {
+			native-mode = <&svga_timings>;
+			svga_timings: 800x600 {
+				clock-frequency = <37500000>;
+				hactive = <800>;
+				hback-porch = <140>;
+				hfront-porch = <40>;
+				hsync-len = <128>;
+				vactive = <600>;
+				vback-porch = <23>;
+				vfront-porch = <1>;
+				vsync-len = <4>;
+			};
+		};
+	};
 };
 
 &pmx_core {
@@ -84,6 +118,28 @@
 			0x30 0x01100000  0x0ff00000
 		>;
 	};
+
+	lcd_pins: pinmux_lcd_pins {
+		pinctrl-single,bits = <
+			/*
+			 * LCD_D[2], LCD_D[3], LCD_D[4], LCD_D[5],
+			 * LCD_D[6], LCD_D[7]
+			 */
+			0x40 0x22222200 0xffffff00
+			/*
+			 * LCD_D[10], LCD_D[11], LCD_D[12], LCD_D[13],
+			 * LCD_D[14], LCD_D[15], LCD_D[0], LCD_D[1]
+			 */
+			0x44 0x22222222 0xffffffff
+			/* LCD_D[8], LCD_D[9] */
+			0x48 0x00000022 0x000000ff
+
+			/* LCD_PCLK */
+			0x48 0x02000000 0x0f000000
+			/* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC */
+			0x4c 0x02000022 0x0f0000ff
+		>;
+	};
 };
 
 &serial2 {
@@ -219,3 +275,7 @@
 		};
 	};
 };
+
+&lcdc {
+	status = "okay";
+};
-- 
2.7.4

[PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller

[Karl Beldan]

Hi,

On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
> 
> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
> with some default timings for 800x600.
> 
> Tested on an LCDK connected on the VGA port (the LCDC is connected to
> this port via a THS8135).
> 
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [Bartosz:
>   - fixed whitespace errors
>   - tweaked the description

The description tweak you mention is the removal of an erratum which is
in the mentioned commit I put on github @
(https://github.com/kbeldan/linux/commit/b7720bc983c00a083dece119f68ea9d2f522c6c4)
it included an erratum wrt FIFO threshold I think is worth keeping:
{
There is an erratum (fifo-th) "LCDC: Underflow During Initialization":
[...]
"This problem may occur if the LCDC FIFO threshold size (
LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset.
Increasing the FIFO threshold size will reduce or eliminate underflows.
Setting the threshold size to 256 double words or larger is
recommended."
}

>   - fixed the incorrect hback-porch value

It can't be a fix, this value depends on the monitor connected.

>   - other minor tweaks]

I didn't see any other change while diffing.

Regards, 
Karl Beldan

> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  arch/arm/boot/dts/da850-lcdk.dts | 60 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 60 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 7b8ab21..6ca5d48 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -50,6 +50,40 @@
>  			system-clock-frequency = <24576000>;
>  		};
>  	};
> +
> +	panel {
> +		compatible = "ti,tilcdc,panel";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&lcd_pins>;
> +		status = "okay";
> +
> +		panel-info {
> +			ac-bias           = <0>;
> +			ac-bias-intrpt    = <0>;
> +			dma-burst-sz      = <16>;
> +			bpp               = <16>;
> +			fdd               = <255>;
> +			sync-edge         = <0>;
> +			sync-ctrl         = <0>;
> +			raster-order      = <0>;
> +			fifo-th           = <5>;
> +		};
> +
> +		display-timings {
> +			native-mode = <&svga_timings>;
> +			svga_timings: 800x600 {
> +				clock-frequency = <37500000>;
> +				hactive = <800>;
> +				hback-porch = <140>;
> +				hfront-porch = <40>;
> +				hsync-len = <128>;
> +				vactive = <600>;
> +				vback-porch = <23>;
> +				vfront-porch = <1>;
> +				vsync-len = <4>;
> +			};
> +		};
> +	};
>  };
>  
>  &pmx_core {
> @@ -84,6 +118,28 @@
>  			0x30 0x01100000  0x0ff00000
>  		>;
>  	};
> +
> +	lcd_pins: pinmux_lcd_pins {
> +		pinctrl-single,bits = <
> +			/*
> +			 * LCD_D[2], LCD_D[3], LCD_D[4], LCD_D[5],
> +			 * LCD_D[6], LCD_D[7]
> +			 */
> +			0x40 0x22222200 0xffffff00
> +			/*
> +			 * LCD_D[10], LCD_D[11], LCD_D[12], LCD_D[13],
> +			 * LCD_D[14], LCD_D[15], LCD_D[0], LCD_D[1]
> +			 */
> +			0x44 0x22222222 0xffffffff
> +			/* LCD_D[8], LCD_D[9] */
> +			0x48 0x00000022 0x000000ff
> +
> +			/* LCD_PCLK */
> +			0x48 0x02000000 0x0f000000
> +			/* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC */
> +			0x4c 0x02000022 0x0f0000ff
> +		>;
> +	};
>  };
>  
>  &serial2 {
> @@ -219,3 +275,7 @@
>  		};
>  	};
>  };
> +
> +&lcdc {
> +	status = "okay";
> +};
> -- 
> 2.7.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller

[Bartosz Golaszewski]

2016-09-29 20:40 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
>> From: Karl Beldan <kbeldan@baylibre.com>
>>
>> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
>> with some default timings for 800x600.
>>
>> Tested on an LCDK connected on the VGA port (the LCDC is connected to
>> this port via a THS8135).
>>
>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>> [Bartosz:
>>   - fixed whitespace errors
>>   - tweaked the description
>
> The description tweak you mention is the removal of an erratum which is
> in the mentioned commit I put on github @
> (https://github.com/kbeldan/linux/commit/b7720bc983c00a083dece119f68ea9d2f522c6c4)
> it included an erratum wrt FIFO threshold I think is worth keeping:
> {
> There is an erratum (fifo-th) "LCDC: Underflow During Initialization":
> [...]
> "This problem may occur if the LCDC FIFO threshold size (
> LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset.
> Increasing the FIFO threshold size will reduce or eliminate underflows.
> Setting the threshold size to 256 double words or larger is
> recommended."
> }

Isn't this the issue that is fixed by changing the memory priority for lcdc?

>
>>   - fixed the incorrect hback-porch value
>
> It can't be a fix, this value depends on the monitor connected.
>

Thanks, I'm new to drm. From reading the datasheet it seemed to me
that this depends on the resolution. FWIW it seems that most LCDs are
able to adjust to this themselves - I tested with two different
displays and the value I introduced worked on both while the previous
one shifted the image to the right. I'll look into that.

>>   - other minor tweaks]
>
> I didn't see any other change while diffing.
>

Dropped the refresh rate from the timings node name.

Thanks,
Bartosz

[PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller

[Karl Beldan]

On Fri, Sep 30, 2016 at 11:42:14AM +0200, Bartosz Golaszewski wrote:
> 2016-09-29 20:40 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> > Hi,
> >
> > On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
> >> From: Karl Beldan <kbeldan@baylibre.com>
> >>
> >> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
> >> with some default timings for 800x600.
> >>
> >> Tested on an LCDK connected on the VGA port (the LCDC is connected to
> >> this port via a THS8135).
> >>
> >> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> >> [Bartosz:
> >>   - fixed whitespace errors
> >>   - tweaked the description
> >
> > The description tweak you mention is the removal of an erratum which is
> > in the mentioned commit I put on github @
> > (https://github.com/kbeldan/linux/commit/b7720bc983c00a083dece119f68ea9d2f522c6c4)
> > it included an erratum wrt FIFO threshold I think is worth keeping:
> > {
> > There is an erratum (fifo-th) "LCDC: Underflow During Initialization":
> > [...]
> > "This problem may occur if the LCDC FIFO threshold size (
> > LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset.
> > Increasing the FIFO threshold size will reduce or eliminate underflows.
> > Setting the threshold size to 256 double words or larger is
> > recommended."
> > }
> 
> Isn't this the issue that is fixed by changing the memory priority for lcdc?
> 

It is possible that the erratum and the memory priority settings try to
address the symptoms of the same underlying issue, it is impossible to
state with the publicly available information, however, the erratum
relates to the LCDC registers settings, namely the fifo-th propperty of
panel-info in the dts, which is really different from the memory
priority adjustments in the SYSCFG and DDR_CTL.

Regards, 
Karl

> >
> >>   - fixed the incorrect hback-porch value
> >
> > It can't be a fix, this value depends on the monitor connected.
> >
> 
> Thanks, I'm new to drm. From reading the datasheet it seemed to me
> that this depends on the resolution. FWIW it seems that most LCDs are
> able to adjust to this themselves - I tested with two different
> displays and the value I introduced worked on both while the previous
> one shifted the image to the right. I'll look into that.
> 
> >>   - other minor tweaks]
> >
> > I didn't see any other change while diffing.
> >
> 
> Dropped the refresh rate from the timings node name.
> 
> Thanks,
> Bartosz

[PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller

[Sekhar Nori]

On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
> 
> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
> with some default timings for 800x600.
> 
> Tested on an LCDK connected on the VGA port (the LCDC is connected to
> this port via a THS8135).
> 
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [Bartosz:
>   - fixed whitespace errors
>   - tweaked the description
>   - fixed the incorrect hback-porch value
>   - other minor tweaks]
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---

> +	lcd_pins: pinmux_lcd_pins {
> +		pinctrl-single,bits = <
> +			/*
> +			 * LCD_D[2], LCD_D[3], LCD_D[4], LCD_D[5],
> +			 * LCD_D[6], LCD_D[7]
> +			 */
> +			0x40 0x22222200 0xffffff00
> +			/*
> +			 * LCD_D[10], LCD_D[11], LCD_D[12], LCD_D[13],
> +			 * LCD_D[14], LCD_D[15], LCD_D[0], LCD_D[1]
> +			 */
> +			0x44 0x22222222 0xffffffff
> +			/* LCD_D[8], LCD_D[9] */
> +			0x48 0x00000022 0x000000ff
> +
> +			/* LCD_PCLK */
> +			0x48 0x02000000 0x0f000000
> +			/* LCD_AC_ENB_CS, LCD_VSYNC, LCD_HSYNC */
> +			0x4c 0x02000022 0x0f0000ff
> +		>;
> +	};

Since almost all boards that use LCD will configure the pins in the same
way, we can move this to da850.dtsi. Please see existing examples of the
same.

The only place where we don't do this is if the common pinmux definition
may not find much reuse because of differing nature of how the external
peripherals are interfaced.

Thanks,
Sekhar

[PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

[Bartosz Golaszewski]

Add svga timings for 1024x768 resolution to the da850-lcdk
device tree.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/boot/dts/da850-lcdk.dts | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 6ca5d48..6e4288c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -70,8 +70,8 @@
 		};
 
 		display-timings {
-			native-mode = <&svga_timings>;
-			svga_timings: 800x600 {
+			native-mode = <&svga_timing0>;
+			svga_timing0: 800x600 {
 				clock-frequency = <37500000>;
 				hactive = <800>;
 				hback-porch = <140>;
@@ -82,6 +82,17 @@
 				vfront-porch = <1>;
 				vsync-len = <4>;
 			};
+			svga_timing1: 1024x768 {
+				clock-frequency = <72000000>;
+				hactive = <1024>;
+				hback-porch = <140>;
+				hfront-porch = <40>;
+				hsync-len = <128>;
+				vactive = <768>;
+				vback-porch = <23>;
+				vfront-porch = <1>;
+				vsync-len = <4>;
+			};
 		};
 	};
 };
-- 
2.7.4

[PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

[Karl Beldan]

Hi,

On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
> Add svga timings for 1024x768 resolution to the da850-lcdk
> device tree.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  arch/arm/boot/dts/da850-lcdk.dts | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 6ca5d48..6e4288c 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -70,8 +70,8 @@
>  		};
>  
>  		display-timings {
> -			native-mode = <&svga_timings>;
> -			svga_timings: 800x600 {
> +			native-mode = <&svga_timing0>;
> +			svga_timing0: 800x600 {
>  				clock-frequency = <37500000>;
>  				hactive = <800>;
>  				hback-porch = <140>;
> @@ -82,6 +82,17 @@
>  				vfront-porch = <1>;
>  				vsync-len = <4>;
>  			};
> +			svga_timing1: 1024x768 {
> +				clock-frequency = <72000000>;
> +				hactive = <1024>;
> +				hback-porch = <140>;
> +				hfront-porch = <40>;
> +				hsync-len = <128>;
> +				vactive = <768>;
> +				vback-porch = <23>;
> +				vfront-porch = <1>;
> +				vsync-len = <4>;
> +			};

Why do you also call 1024x768 svga ?

I don't think the LCDK can cope with this resolution at this frequency
(in terms of mem bandwidth), at least that's what I observed back in
August. If confirmed I think it is worth mentioning in the log at least,
but then I doubt adding this config would be useful.

Regards, 
Karl

>  		};
>  	};
>  };
> -- 
> 2.7.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

[Bartosz Golaszewski]

2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>> Add svga timings for 1024x768 resolution to the da850-lcdk
>> device tree.
>>
>

[snip]

>
> Why do you also call 1024x768 svga ?
>

Thanks, should have been xga. will fix in v2.

> I don't think the LCDK can cope with this resolution at this frequency
> (in terms of mem bandwidth), at least that's what I observed back in
> August. If confirmed I think it is worth mentioning in the log at least,
> but then I doubt adding this config would be useful.
>

Thanks for the heads up. How would that manifest itself? This seems to
work fine for me - I'm not getting any warnings on a simple system -
maybe if I added some additional memory load it would complain.

Thanks,
Bartosz

[PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

[Sekhar Nori]

On Friday 30 September 2016 03:07 PM, Bartosz Golaszewski wrote:
> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> Hi,
>>
>> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>>> Add svga timings for 1024x768 resolution to the da850-lcdk
>>> device tree.
>>>
>>
> 
> [snip]
> 
>>
>> Why do you also call 1024x768 svga ?
>>
> 
> Thanks, should have been xga. will fix in v2.

When you send the v2, can you please include the driver folks too. I am
no expert on DRM and LCDC and would like to ensure they had a look at
the dts patches too.

Thanks,
Sekhar

[PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

[Karl Beldan]

On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote:
> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> > Hi,
> >
> > On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
> >> Add svga timings for 1024x768 resolution to the da850-lcdk
> >> device tree.
> >>
> >
> 
> [snip]
> 
> >
> > Why do you also call 1024x768 svga ?
> >
> 
> Thanks, should have been xga. will fix in v2.
> 
> > I don't think the LCDK can cope with this resolution at this frequency
> > (in terms of mem bandwidth), at least that's what I observed back in
> > August. If confirmed I think it is worth mentioning in the log at least,
> > but then I doubt adding this config would be useful.
> >
> 
> Thanks for the heads up. How would that manifest itself? This seems to
> work fine for me - I'm not getting any warnings on a simple system -
> maybe if I added some additional memory load it would complain.
> 

A mere dmesg > /dev/tty0 (or repeatedly cat-ting a file to /dev/tty0)
should suffice to make the issue visible and trigger FIFO underflows.

Regards, 
Karl

[PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

[Bartosz Golaszewski]

2016-09-30 14:49 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote:
>> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> > Hi,
>> >
>> > On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>> >> Add svga timings for 1024x768 resolution to the da850-lcdk
>> >> device tree.
>> >>
>> >
>>
>> [snip]
>>
>> >
>> > Why do you also call 1024x768 svga ?
>> >
>>
>> Thanks, should have been xga. will fix in v2.
>>
>> > I don't think the LCDK can cope with this resolution at this frequency
>> > (in terms of mem bandwidth), at least that's what I observed back in
>> > August. If confirmed I think it is worth mentioning in the log at least,
>> > but then I doubt adding this config would be useful.
>> >
>>
>> Thanks for the heads up. How would that manifest itself? This seems to
>> work fine for me - I'm not getting any warnings on a simple system -
>> maybe if I added some additional memory load it would complain.
>>
>
> A mere dmesg > /dev/tty0 (or repeatedly cat-ting a file to /dev/tty0)
> should suffice to make the issue visible and trigger FIFO underflows.
>

Thanks, this is correct unfortunately.

Best regards,
Bartosz Golaszewski

[PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

[Sekhar Nori]

On Friday 30 September 2016 07:18 PM, Bartosz Golaszewski wrote:
> 2016-09-30 14:49 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote:
>>> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>>>> Hi,
>>>>
>>>> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
>>>>> Add svga timings for 1024x768 resolution to the da850-lcdk
>>>>> device tree.
>>>>>
>>>>
>>>
>>> [snip]
>>>
>>>>
>>>> Why do you also call 1024x768 svga ?
>>>>
>>>
>>> Thanks, should have been xga. will fix in v2.
>>>
>>>> I don't think the LCDK can cope with this resolution at this frequency
>>>> (in terms of mem bandwidth), at least that's what I observed back in
>>>> August. If confirmed I think it is worth mentioning in the log at least,
>>>> but then I doubt adding this config would be useful.
>>>>
>>>
>>> Thanks for the heads up. How would that manifest itself? This seems to
>>> work fine for me - I'm not getting any warnings on a simple system -
>>> maybe if I added some additional memory load it would complain.
>>>
>>
>> A mere dmesg > /dev/tty0 (or repeatedly cat-ting a file to /dev/tty0)
>> should suffice to make the issue visible and trigger FIFO underflows.
>>
> 
> Thanks, this is correct unfortunately.

The OMAP-L138 datasheet documents 37.5 MHz as the maximum pixel clock
possible on the device. Looks like you need 72MHz pixel clock for
1024x768 which is definitely out of spec.

Thanks,
Sekhar

[PATCH 5/6] ARM: davinci: enable the LCDC DRM driver in defconfig

[Bartosz Golaszewski]

With the device tree changes for tilcdc in place, we can now enable
the driver by default in the davinci_all defconfig file.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 5e5dd6b..58d04f1 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -123,6 +123,8 @@ CONFIG_TPS6507X=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_TPS6507X=y
+CONFIG_DRM=m
+CONFIG_DRM_TILCDC=m
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_DA8XX=y
-- 
2.7.4

[PATCH 5/6] ARM: davinci: enable the LCDC DRM driver in defconfig

[Sekhar Nori]

On Thursday 29 September 2016 10:01 PM, Bartosz Golaszewski wrote:
> With the device tree changes for tilcdc in place, we can now enable
> the driver by default in the davinci_all defconfig file.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Applied to v4.10/defconfig branch of my tree. Adjusted the subject line
to be consistent with how patches for defconfig are usually headlines.

ARM: davinci_all_defconfig: enable LCDC DRM driver

defconfig updates are last in the pull request I will send up, so the
description will make sense when finally merged.

Thanks,
Sekhar

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Bartosz Golaszewski]

Default memory settings of da850 do not meet the throughput/latency
requirements of tilcdc. This results in the image displayed being
incorrect and the following warning being displayed by the LCDC
drm driver:

  tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow

Reconfigure the LCDC priority to the highest. This is a workaround
for the da850-lcdk board which has the LCD controller enabled in
the device tree, but a long-term, system-wide fix is needed for
all davinci boards.

This patch has been modified for mainline linux. It comes from a
downstream TI release for da850[1].

Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>

[1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/mach-davinci/da8xx-dt.c           | 43 ++++++++++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/da8xx.h |  4 +++
 2 files changed, 47 insertions(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index f8ecc02..9d29670 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -44,9 +44,52 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 
 #ifdef CONFIG_ARCH_DAVINCI_DA850
 
+/*
+ * Adjust the default memory settings to cope with the LCDC
+ *
+ * REVISIT: This issue occurs on other davinci boards as well. Find
+ * a proper system-wide fix.
+ */
+static void da850_lcdc_adjust_memory_bandwidth(void)
+{
+	void __iomem *cfg_mstpri1_base;
+	void __iomem *cfg_mstpri2_base;
+	void __iomem *emifb;
+	u32 val;
+
+	/*
+	 * Default master priorities in reg 0 are all lower by default than LCD
+	 * which is set below to 0. Hence don't need to change here.
+	 */
+
+	/* set EDMA30TC0 and TC1 to lower than LCDC (4 < 0) */
+	cfg_mstpri1_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI1_REG);
+	val = __raw_readl(cfg_mstpri1_base);
+	val &= 0xFFFF00FF;
+	val |= 4 << 8;             /* 0-high, 7-low priority*/
+	val |= 4 << 12;            /* 0-high, 7-low priority*/
+	__raw_writel(val, cfg_mstpri1_base);
+
+	/*
+	 * Reconfigure the LCDC priority to the highest to ensure that
+	 * the throughput/latency requirements for the LCDC are met.
+	 */
+	cfg_mstpri2_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI2_REG);
+
+	val = __raw_readl(cfg_mstpri2_base);
+	val &= 0x0fffffff;
+	__raw_writel(val, cfg_mstpri2_base);
+
+	/* set BPRIO */
+	emifb = ioremap(DA8XX_DDR_CTL_BASE, SZ_4K);
+	__raw_writel(0x20, emifb + DA8XX_PBBPR_REG);
+	iounmap(emifb);
+}
+
 static void __init da850_init_machine(void)
 {
 	of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
+	da850_lcdc_adjust_memory_bandwidth();
 }
 
 static const char *const da850_boards_compat[] __initconst = {
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index f9f9713..5549eff 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -56,6 +56,8 @@ extern unsigned int da850_max_speed;
 #define DA8XX_SYSCFG0_VIRT(x)	(da8xx_syscfg0_base + (x))
 #define DA8XX_JTAG_ID_REG	0x18
 #define DA8XX_HOST1CFG_REG	0x44
+#define DA8XX_MSTPRI1_REG	0x114
+#define DA8XX_MSTPRI2_REG	0x118
 #define DA8XX_CHIPSIG_REG	0x174
 #define DA8XX_CFGCHIP0_REG	0x17c
 #define DA8XX_CFGCHIP1_REG	0x180
@@ -79,6 +81,8 @@ extern unsigned int da850_max_speed;
 #define DA8XX_AEMIF_CTL_BASE	0x68000000
 #define DA8XX_SHARED_RAM_BASE	0x80000000
 #define DA8XX_ARM_RAM_BASE	0xffff0000
+#define DA8XX_DDR_CTL_BASE	0xB0000000
+#define DA8XX_PBBPR_REG		0x00000020
 
 void da830_init(void);
 void da850_init(void);
-- 
2.7.4

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Karl Beldan]

Hi,

On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
> Default memory settings of da850 do not meet the throughput/latency
> requirements of tilcdc. This results in the image displayed being
> incorrect and the following warning being displayed by the LCDC
> drm driver:
> 
>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
> 
> Reconfigure the LCDC priority to the highest. This is a workaround
> for the da850-lcdk board which has the LCD controller enabled in
> the device tree, but a long-term, system-wide fix is needed for
> all davinci boards.
> 
> This patch has been modified for mainline linux. It comes from a
> downstream TI release for da850[1].
> 
> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
> 
> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---

FWIW, the quirks could be applied conditionnally depending on the lcdc
node presence in the DT, a bit like:
https://github.com/kbeldan/linux/commit/cf15572ffef8e8a0d8110b3f6b29bd401d0538be
https://github.com/kbeldan/linux/commit/07e4fff9958bc1625a96791dce284c163fbe9c43


Regards, 
Karl

>  arch/arm/mach-davinci/da8xx-dt.c           | 43 ++++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/da8xx.h |  4 +++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index f8ecc02..9d29670 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -44,9 +44,52 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>  
>  #ifdef CONFIG_ARCH_DAVINCI_DA850
>  
> +/*
> + * Adjust the default memory settings to cope with the LCDC
> + *
> + * REVISIT: This issue occurs on other davinci boards as well. Find
> + * a proper system-wide fix.
> + */
> +static void da850_lcdc_adjust_memory_bandwidth(void)
> +{
> +	void __iomem *cfg_mstpri1_base;
> +	void __iomem *cfg_mstpri2_base;
> +	void __iomem *emifb;
> +	u32 val;
> +
> +	/*
> +	 * Default master priorities in reg 0 are all lower by default than LCD
> +	 * which is set below to 0. Hence don't need to change here.
> +	 */
> +
> +	/* set EDMA30TC0 and TC1 to lower than LCDC (4 < 0) */
> +	cfg_mstpri1_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI1_REG);
> +	val = __raw_readl(cfg_mstpri1_base);
> +	val &= 0xFFFF00FF;
> +	val |= 4 << 8;             /* 0-high, 7-low priority*/
> +	val |= 4 << 12;            /* 0-high, 7-low priority*/
> +	__raw_writel(val, cfg_mstpri1_base);
> +
> +	/*
> +	 * Reconfigure the LCDC priority to the highest to ensure that
> +	 * the throughput/latency requirements for the LCDC are met.
> +	 */
> +	cfg_mstpri2_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI2_REG);
> +
> +	val = __raw_readl(cfg_mstpri2_base);
> +	val &= 0x0fffffff;
> +	__raw_writel(val, cfg_mstpri2_base);
> +
> +	/* set BPRIO */
> +	emifb = ioremap(DA8XX_DDR_CTL_BASE, SZ_4K);
> +	__raw_writel(0x20, emifb + DA8XX_PBBPR_REG);
> +	iounmap(emifb);
> +}
> +
>  static void __init da850_init_machine(void)
>  {
>  	of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> +	da850_lcdc_adjust_memory_bandwidth();
>  }
>  
>  static const char *const da850_boards_compat[] __initconst = {
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index f9f9713..5549eff 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -56,6 +56,8 @@ extern unsigned int da850_max_speed;
>  #define DA8XX_SYSCFG0_VIRT(x)	(da8xx_syscfg0_base + (x))
>  #define DA8XX_JTAG_ID_REG	0x18
>  #define DA8XX_HOST1CFG_REG	0x44
> +#define DA8XX_MSTPRI1_REG	0x114
> +#define DA8XX_MSTPRI2_REG	0x118
>  #define DA8XX_CHIPSIG_REG	0x174
>  #define DA8XX_CFGCHIP0_REG	0x17c
>  #define DA8XX_CFGCHIP1_REG	0x180
> @@ -79,6 +81,8 @@ extern unsigned int da850_max_speed;
>  #define DA8XX_AEMIF_CTL_BASE	0x68000000
>  #define DA8XX_SHARED_RAM_BASE	0x80000000
>  #define DA8XX_ARM_RAM_BASE	0xffff0000
> +#define DA8XX_DDR_CTL_BASE	0xB0000000
> +#define DA8XX_PBBPR_REG		0x00000020
>  
>  void da830_init(void);
>  void da850_init(void);
> -- 
> 2.7.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Bartosz Golaszewski]

2016-09-29 21:07 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
> Hi,
>
> On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
>> Default memory settings of da850 do not meet the throughput/latency
>> requirements of tilcdc. This results in the image displayed being
>> incorrect and the following warning being displayed by the LCDC
>> drm driver:
>>
>>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>
>> Reconfigure the LCDC priority to the highest. This is a workaround
>> for the da850-lcdk board which has the LCD controller enabled in
>> the device tree, but a long-term, system-wide fix is needed for
>> all davinci boards.
>>
>> This patch has been modified for mainline linux. It comes from a
>> downstream TI release for da850[1].
>>
>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>
>> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>
> FWIW, the quirks could be applied conditionnally depending on the lcdc
> node presence in the DT, a bit like:
> https://github.com/kbeldan/linux/commit/cf15572ffef8e8a0d8110b3f6b29bd401d0538be
> https://github.com/kbeldan/linux/commit/07e4fff9958bc1625a96791dce284c163fbe9c43
>
>
> Regards,
> Karl

Hi Karl,

I decided to post the simplest possible way of this to get the lcdc
working upstream. In parallel I'm working on a system-wide way of
applying such quirks not only limited to device tree nodes' presence.
Thanks for the info!

Best regards,
Bartosz Golaszewski

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Karl Beldan]

On Fri, Sep 30, 2016 at 9:31 AM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> 2016-09-29 21:07 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>:
>> Hi,
>>
>> On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
>>> Default memory settings of da850 do not meet the throughput/latency
>>> requirements of tilcdc. This results in the image displayed being
>>> incorrect and the following warning being displayed by the LCDC
>>> drm driver:
>>>
>>>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>>
>>> Reconfigure the LCDC priority to the highest. This is a workaround
>>> for the da850-lcdk board which has the LCD controller enabled in
>>> the device tree, but a long-term, system-wide fix is needed for
>>> all davinci boards.
>>>
>>> This patch has been modified for mainline linux. It comes from a
>>> downstream TI release for da850[1].
>>>
>>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>>
>>> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>> ---
>>
>> FWIW, the quirks could be applied conditionnally depending on the lcdc
>> node presence in the DT, a bit like:
>> https://github.com/kbeldan/linux/commit/cf15572ffef8e8a0d8110b3f6b29bd401d0538be
>> https://github.com/kbeldan/linux/commit/07e4fff9958bc1625a96791dce284c163fbe9c43
>>
>>
>> Regards,
>> Karl
>
> Hi Karl,
>
> I decided to post the simplest possible way of this to get the lcdc
> working upstream. In parallel I'm working on a system-wide way of
> applying such quirks not only limited to device tree nodes' presence.

Ok, that'd be a good thing, apparently people have been looking
to do such a thing for the am335x as well.

Regards,
Karl

> Thanks for the info!
>
> Best regards,
> Bartosz Golaszewski

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Peter Ujfalusi]

On 09/29/16 19:31, Bartosz Golaszewski wrote:
> Default memory settings of da850 do not meet the throughput/latency
> requirements of tilcdc. This results in the image displayed being
> incorrect and the following warning being displayed by the LCDC
> drm driver:
> 
>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
> 
> Reconfigure the LCDC priority to the highest. This is a workaround
> for the da850-lcdk board which has the LCD controller enabled in
> the device tree, but a long-term, system-wide fix is needed for
> all davinci boards.
> 
> This patch has been modified for mainline linux. It comes from a
> downstream TI release for da850[1].
> 
> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
> 
> [1] http://arago-project.org/git/projects/linux-davinci.git?p=projects/linux-davinci.git;a=commitdiff;h=b9bd39a34cc02c3ba2fc15539a2f0bc2b68d25da;hp=6f6c795faa6366a4ebc1037a0235edba6018a991
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>  arch/arm/mach-davinci/da8xx-dt.c           | 43 ++++++++++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/da8xx.h |  4 +++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index f8ecc02..9d29670 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -44,9 +44,52 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>  
>  #ifdef CONFIG_ARCH_DAVINCI_DA850
>  
> +/*
> + * Adjust the default memory settings to cope with the LCDC
> + *
> + * REVISIT: This issue occurs on other davinci boards as well. Find
> + * a proper system-wide fix.
> + */
> +static void da850_lcdc_adjust_memory_bandwidth(void)
> +{
> +	void __iomem *cfg_mstpri1_base;
> +	void __iomem *cfg_mstpri2_base;
> +	void __iomem *emifb;
> +	u32 val;
> +
> +	/*
> +	 * Default master priorities in reg 0 are all lower by default than LCD
> +	 * which is set below to 0. Hence don't need to change here.
> +	 */
> +
> +	/* set EDMA30TC0 and TC1 to lower than LCDC (4 < 0) */
> +	cfg_mstpri1_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI1_REG);
> +	val = __raw_readl(cfg_mstpri1_base);
> +	val &= 0xFFFF00FF;
> +	val |= 4 << 8;             /* 0-high, 7-low priority*/
> +	val |= 4 << 12;            /* 0-high, 7-low priority*/
> +	__raw_writel(val, cfg_mstpri1_base);
> +
> +	/*
> +	 * Reconfigure the LCDC priority to the highest to ensure that
> +	 * the throughput/latency requirements for the LCDC are met.
> +	 */
> +	cfg_mstpri2_base = DA8XX_SYSCFG0_VIRT(DA8XX_MSTPRI2_REG);
> +
> +	val = __raw_readl(cfg_mstpri2_base);
> +	val &= 0x0fffffff;
> +	__raw_writel(val, cfg_mstpri2_base);
> +
> +	/* set BPRIO */
> +	emifb = ioremap(DA8XX_DDR_CTL_BASE, SZ_4K);
> +	__raw_writel(0x20, emifb + DA8XX_PBBPR_REG);
> +	iounmap(emifb);

Is this safe to do for all da850 boards (to change PR_OLD_COUNT from 0xff to
0x20)? Most probably it is, but this setting has nothing to do with LCDC.

The whole priority configuration has nothing to do with the LCDC, it is a
system level priority.

Now you have lowered the eDMA3_0-TPTC0/1 priority. Audio is serviced by
eDMA3_0-TPTC1. So are we going to see issues in audio if LCDC is taking the
highest priority?

> +}
> +
>  static void __init da850_init_machine(void)
>  {
>  	of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> +	da850_lcdc_adjust_memory_bandwidth();
>  }
>  
>  static const char *const da850_boards_compat[] __initconst = {
> diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
> index f9f9713..5549eff 100644
> --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> @@ -56,6 +56,8 @@ extern unsigned int da850_max_speed;
>  #define DA8XX_SYSCFG0_VIRT(x)	(da8xx_syscfg0_base + (x))
>  #define DA8XX_JTAG_ID_REG	0x18
>  #define DA8XX_HOST1CFG_REG	0x44
> +#define DA8XX_MSTPRI1_REG	0x114
> +#define DA8XX_MSTPRI2_REG	0x118
>  #define DA8XX_CHIPSIG_REG	0x174
>  #define DA8XX_CFGCHIP0_REG	0x17c
>  #define DA8XX_CFGCHIP1_REG	0x180
> @@ -79,6 +81,8 @@ extern unsigned int da850_max_speed;
>  #define DA8XX_AEMIF_CTL_BASE	0x68000000
>  #define DA8XX_SHARED_RAM_BASE	0x80000000
>  #define DA8XX_ARM_RAM_BASE	0xffff0000
> +#define DA8XX_DDR_CTL_BASE	0xB0000000
> +#define DA8XX_PBBPR_REG		0x00000020
>  
>  void da830_init(void);
>  void da850_init(void);
> 


-- 
P?ter

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Bartosz Golaszewski]

2016-09-30 14:59 GMT+02:00 Peter Ujfalusi <peter.ujfalusi@ti.com>:
> On 09/29/16 19:31, Bartosz Golaszewski wrote:
>> Default memory settings of da850 do not meet the throughput/latency
>> requirements of tilcdc. This results in the image displayed being
>> incorrect and the following warning being displayed by the LCDC
>> drm driver:
>>
>>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>
>> Reconfigure the LCDC priority to the highest. This is a workaround
>> for the da850-lcdk board which has the LCD controller enabled in
>> the device tree, but a long-term, system-wide fix is needed for
>> all davinci boards.
>>
>> This patch has been modified for mainline linux. It comes from a
>> downstream TI release for da850[1].
>>
>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>

[snip]

>
> Is this safe to do for all da850 boards (to change PR_OLD_COUNT from 0xff to
> 0x20)? Most probably it is, but this setting has nothing to do with LCDC.
>
> The whole priority configuration has nothing to do with the LCDC, it is a
> system level priority.
>
> Now you have lowered the eDMA3_0-TPTC0/1 priority. Audio is serviced by
> eDMA3_0-TPTC1. So are we going to see issues in audio if LCDC is taking the
> highest priority?
>

Just ran a quick test with speaker-test -c2 -twav. Besides the fact
that the left and right channels are inverted (I'm looking into that),
I didn't notice any problems. Even at 1024x768 resolution, playing
audio at the same time seems to work fine.

Best regards,
Bartosz Golaszewski

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Peter Ujfalusi]

On 09/30/2016 06:06 PM, Bartosz Golaszewski wrote:
> 2016-09-30 14:59 GMT+02:00 Peter Ujfalusi <peter.ujfalusi@ti.com>:
>> On 09/29/16 19:31, Bartosz Golaszewski wrote:
>>> Default memory settings of da850 do not meet the throughput/latency
>>> requirements of tilcdc. This results in the image displayed being
>>> incorrect and the following warning being displayed by the LCDC
>>> drm driver:
>>>
>>>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>>
>>> Reconfigure the LCDC priority to the highest. This is a workaround
>>> for the da850-lcdk board which has the LCD controller enabled in
>>> the device tree, but a long-term, system-wide fix is needed for
>>> all davinci boards.
>>>
>>> This patch has been modified for mainline linux. It comes from a
>>> downstream TI release for da850[1].
>>>
>>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>>
> 
> [snip]
> 
>>
>> Is this safe to do for all da850 boards (to change PR_OLD_COUNT from 0xff to
>> 0x20)? Most probably it is, but this setting has nothing to do with LCDC.
>>
>> The whole priority configuration has nothing to do with the LCDC, it is a
>> system level priority.
>>
>> Now you have lowered the eDMA3_0-TPTC0/1 priority. Audio is serviced by
>> eDMA3_0-TPTC1. So are we going to see issues in audio if LCDC is taking the
>> highest priority?
>>
> 
> Just ran a quick test with speaker-test -c2 -twav. Besides the fact
> that the left and right channels are inverted (I'm looking into that),
> I didn't notice any problems. Even at 1024x768 resolution, playing
> audio at the same time seems to work fine.

That's good to hear, but I think the priorities should be set:
LCDC and EDMA30TC1 to highest priority
EDMA30TC0 to priority 2

The 0TC0 is used by MMC and if you want to play a video you might need the
servicing TC to be higher priority then other masters.

If audio playback would trigger sync losts in lcdc then we might need to move
0TC1 to priority 1.

I agree that LCDC priority needs to be higher, but I do wonder why the default
(5) is not working and if it is not working why it is 5...

My guess is that the change in the PBBPR register is the one actually helping
here.

-- 
P?ter

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Sekhar Nori]

On Saturday 01 October 2016 12:49 AM, Peter Ujfalusi wrote:
> On 09/30/2016 06:06 PM, Bartosz Golaszewski wrote:
>> 2016-09-30 14:59 GMT+02:00 Peter Ujfalusi <peter.ujfalusi@ti.com>:
>>> On 09/29/16 19:31, Bartosz Golaszewski wrote:
>>>> Default memory settings of da850 do not meet the throughput/latency
>>>> requirements of tilcdc. This results in the image displayed being
>>>> incorrect and the following warning being displayed by the LCDC
>>>> drm driver:
>>>>
>>>>   tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
>>>>
>>>> Reconfigure the LCDC priority to the highest. This is a workaround
>>>> for the da850-lcdk board which has the LCD controller enabled in
>>>> the device tree, but a long-term, system-wide fix is needed for
>>>> all davinci boards.
>>>>
>>>> This patch has been modified for mainline linux. It comes from a
>>>> downstream TI release for da850[1].
>>>>
>>>> Original author: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
>>>>
>>
>> [snip]
>>
>>>
>>> Is this safe to do for all da850 boards (to change PR_OLD_COUNT from 0xff to
>>> 0x20)? Most probably it is, but this setting has nothing to do with LCDC.
>>>
>>> The whole priority configuration has nothing to do with the LCDC, it is a
>>> system level priority.
>>>
>>> Now you have lowered the eDMA3_0-TPTC0/1 priority. Audio is serviced by
>>> eDMA3_0-TPTC1. So are we going to see issues in audio if LCDC is taking the
>>> highest priority?
>>>
>>
>> Just ran a quick test with speaker-test -c2 -twav. Besides the fact
>> that the left and right channels are inverted (I'm looking into that),
>> I didn't notice any problems. Even at 1024x768 resolution, playing
>> audio at the same time seems to work fine.
> 
> That's good to hear, but I think the priorities should be set:
> LCDC and EDMA30TC1 to highest priority
> EDMA30TC0 to priority 2
> 
> The 0TC0 is used by MMC and if you want to play a video you might need the
> servicing TC to be higher priority then other masters.
> 
> If audio playback would trigger sync losts in lcdc then we might need to move
> 0TC1 to priority 1.
> 
> I agree that LCDC priority needs to be higher, but I do wonder why the default
> (5) is not working and if it is not working why it is 5...
> 
> My guess is that the change in the PBBPR register is the one actually helping
> here.

Good point, Peter. If you are booting off NFS and not playing any audio,
then there is pretty much no EDMA generated traffic on the interconnect.

I would guess too that its the PBBPR setting that is making a
difference. The EDMA vs LCDC priority adjustment might be needed in
particular situations too, but specific experiments should be done to
narrow down on that being the cause.

In any case, to configure the PBBR, you will have to introduce a driver
for it in drivers/memory. Then you can set it up per board using a DT
parameter.

Thanks,
Sekhar

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Peter Ujfalusi]

On 10/01/16 12:24, Sekhar Nori wrote:
>> That's good to hear, but I think the priorities should be set:
>> LCDC and EDMA30TC1 to highest priority
>> EDMA30TC0 to priority 2
>>
>> The 0TC0 is used by MMC and if you want to play a video you might need the
>> servicing TC to be higher priority then other masters.
>>
>> If audio playback would trigger sync losts in lcdc then we might need to move
>> 0TC1 to priority 1.
>>
>> I agree that LCDC priority needs to be higher, but I do wonder why the default
>> (5) is not working and if it is not working why it is 5...
>>
>> My guess is that the change in the PBBPR register is the one actually helping
>> here.
> 
> Good point, Peter. If you are booting off NFS and not playing any audio,
> then there is pretty much no EDMA generated traffic on the interconnect.

Yes, this is my understanding as well.

> I would guess too that its the PBBPR setting that is making a
> difference. The EDMA vs LCDC priority adjustment might be needed in
> particular situations too, but specific experiments should be done to
> narrow down on that being the cause.

True, we can use some conservative values for the priority, but the PBBPR
register for sure needs to be updated.

> In any case, to configure the PBBR, you will have to introduce a driver
> for it in drivers/memory. Then you can set it up per board using a DT
> parameter.

and we can reuse the introduced bindings for am335x and OMAP1/2 as well. On
OMAP the legacy DMA API provided a call to raise the priority of the sDMA in
EMIF :o That needs to be removed and replaced.

-- 
P?ter

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Kevin Hilman]

Peter Ujfalusi <peter.ujfalusi@ti.com> writes:

> On 10/01/16 12:24, Sekhar Nori wrote:

[...]

>> In any case, to configure the PBBR, you will have to introduce a driver
>> for it in drivers/memory. Then you can set it up per board using a DT
>> parameter.
>
> and we can reuse the introduced bindings for am335x and OMAP1/2 as well. On
> OMAP the legacy DMA API provided a call to raise the priority of the sDMA in
> EMIF :o That needs to be removed and replaced.

Can you point us to the bindings you're referring to?

Also, a new driver in drivers/memory is fine for setting the PBBR, but
what about the SYSCFG0 registers.  Are you OK with leaving those in the
init code as proposed in $SUBJECT patch?

Kevin

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Peter Ujfalusi]

On 10/04/16 16:02, Kevin Hilman wrote:
> Peter Ujfalusi <peter.ujfalusi@ti.com> writes:
> 
>> On 10/01/16 12:24, Sekhar Nori wrote:
> 
> [...]
> 
>>> In any case, to configure the PBBR, you will have to introduce a driver
>>> for it in drivers/memory. Then you can set it up per board using a DT
>>> parameter.
>>
>> and we can reuse the introduced bindings for am335x and OMAP1/2 as well. On
>> OMAP the legacy DMA API provided a call to raise the priority of the sDMA in
>> EMIF :o That needs to be removed and replaced.
> 
> Can you point us to the bindings you're referring to?

We don't have one atm.

And the DMA priority hack in legacy sDMA code is for OMAP1:
omap_set_dma_priority(). Basically it can change the sDMA priority in
OCPT1_PRIOR, OCPT2_PRIOR, EMIFF_PRIOR and EMIFS_PRIOR registers.

> Also, a new driver in drivers/memory is fine for setting the PBBR, but
> what about the SYSCFG0 registers.  Are you OK with leaving those in the
> init code as proposed in $SUBJECT patch?

My problem is - as I described it in reply to Bartosz - is that for example I
don't want the LCDC to get high priority on OMAP-L138 EVM from Logic as it
does not have LCD/VGA by default. ifdef for LCDC is not good either since my
kernel have LCDC compiled in, but it is disabled.

The easiest way would be to have pdata quirk to handle the LCDK until we have
proper handling of the priority configuration.

-- 
P?ter

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Sekhar Nori]

On Wednesday 05 October 2016 01:52 PM, Peter Ujfalusi wrote:
> On 10/04/16 16:02, Kevin Hilman wrote:
>> Peter Ujfalusi <peter.ujfalusi@ti.com> writes:
>>
>>> On 10/01/16 12:24, Sekhar Nori wrote:
>>
>> [...]
>>
>>>> In any case, to configure the PBBR, you will have to introduce a driver
>>>> for it in drivers/memory. Then you can set it up per board using a DT
>>>> parameter.
>>>
>>> and we can reuse the introduced bindings for am335x and OMAP1/2 as well. On
>>> OMAP the legacy DMA API provided a call to raise the priority of the sDMA in
>>> EMIF :o That needs to be removed and replaced.
>>
>> Can you point us to the bindings you're referring to?
> 
> We don't have one atm.
> 
> And the DMA priority hack in legacy sDMA code is for OMAP1:
> omap_set_dma_priority(). Basically it can change the sDMA priority in
> OCPT1_PRIOR, OCPT2_PRIOR, EMIFF_PRIOR and EMIFS_PRIOR registers.
> 
>> Also, a new driver in drivers/memory is fine for setting the PBBR, but
>> what about the SYSCFG0 registers.  Are you OK with leaving those in the
>> init code as proposed in $SUBJECT patch?
> 
> My problem is - as I described it in reply to Bartosz - is that for example I
> don't want the LCDC to get high priority on OMAP-L138 EVM from Logic as it
> does not have LCD/VGA by default. ifdef for LCDC is not good either since my
> kernel have LCDC compiled in, but it is disabled.
> 
> The easiest way would be to have pdata quirk to handle the LCDK until we have
> proper handling of the priority configuration.

We don't have pdata quirks handling in mach-davinci. And I think instead
of investing time in adding pdata quirks which are anyway a short term
solution, it is better to work on a drivers/bus/ based driver which can
help adjust master priorities via DT.

Although as Peter asked, it is indeed intriguing as to why LCDC priority
has to be raised even in supposed absence of any competing traffic.

Thanks,
Sekhar

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Bartosz Golaszewski]

2016-09-30 21:19 GMT+02:00 Peter Ujfalusi <peter.ujfalusi@ti.com>:
> On 09/30/2016 06:06 PM, Bartosz Golaszewski wrote:
>>
>> Just ran a quick test with speaker-test -c2 -twav. Besides the fact
>> that the left and right channels are inverted (I'm looking into that),
>> I didn't notice any problems. Even at 1024x768 resolution, playing
>> audio at the same time seems to work fine.
>

Hi Peter

> That's good to hear, but I think the priorities should be set:
> LCDC and EDMA30TC1 to highest priority
> EDMA30TC0 to priority 2
>
> The 0TC0 is used by MMC and if you want to play a video you might need the
> servicing TC to be higher priority then other masters.
>
> If audio playback would trigger sync losts in lcdc then we might need to move
> 0TC1 to priority 1.
>

Did you mean "set EDMA31TC0 to priority 2"? EDMA30TC0 is already at
the highest priority. Or did you mean that we need to lower the
EDMA30TC0 priority? In that case: is 2 the correct value? EDMA31TC0 is
used by mmc1 and its priority is 4. Shouldn't we set both to be the
same?

> I agree that LCDC priority needs to be higher, but I do wonder why the default
> (5) is not working and if it is not working why it is 5...
>
> My guess is that the change in the PBBPR register is the one actually helping
> here.
>

While it seems that lowering the EDMA30TC0 priority is indeed
unnecessary, if I don't set the LCDC master to priority 0, I still get
FIFO underflows even with the change in PBBPR.

Thanks,
Bartosz

[PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

[Peter Ujfalusi]

On 10/04/16 12:20, Bartosz Golaszewski wrote:
> 2016-09-30 21:19 GMT+02:00 Peter Ujfalusi <peter.ujfalusi@ti.com>:
>> On 09/30/2016 06:06 PM, Bartosz Golaszewski wrote:
>>>
>>> Just ran a quick test with speaker-test -c2 -twav. Besides the fact
>>> that the left and right channels are inverted (I'm looking into that),
>>> I didn't notice any problems. Even at 1024x768 resolution, playing
>>> audio at the same time seems to work fine.
>>
> 
> Hi Peter
> 
>> That's good to hear, but I think the priorities should be set:
>> LCDC and EDMA30TC1 to highest priority
>> EDMA30TC0 to priority 2
>>
>> The 0TC0 is used by MMC and if you want to play a video you might need the
>> servicing TC to be higher priority then other masters.
>>
>> If audio playback would trigger sync losts in lcdc then we might need to move
>> 0TC1 to priority 1.
>>
> 
> Did you mean "set EDMA31TC0 to priority 2"? EDMA30TC0 is already at
> the highest priority. Or did you mean that we need to lower the
> EDMA30TC0 priority? In that case: is 2 the correct value? EDMA31TC0 is
> used by mmc1 and its priority is 4. Shouldn't we set both to be the
> same?

What I mean is:
EMDA30TC1 = LCDC = 0;
EDMA30TC0 = 2;

I don't know what the MMC1 is used on the LCDK, but it is only used by add-on
card on Logic's OMAP-L138 EVM (wifi if I recall right). I would leave
EDMA31TC0 as 4.

And while we are here: this is my problem, I don't want LCDC to be high
priority on OMAP-L138 EVM as it has no display by default, no point of
fiddling with the EMIF priority there.

This is the reason why we should have a way via DT to set these priorities. A
DT fragment for OMAP-L138 EVM's wifi module might want to increase the
EDMA31TC0 priority to get better throughput, but on a bare board we don't want
that. If I would have the display module for the EVM, I would like to rise the
LCDC priority also, but I don't have one. If I have the aduio add-on module I
would want to keep audio as the highest priority (and the MMC0 to be able to
record/play audio files). etc.

>> I agree that LCDC priority needs to be higher, but I do wonder why the default
>> (5) is not working and if it is not working why it is 5...
>>
>> My guess is that the change in the PBBPR register is the one actually helping
>> here.
>>
> 
> While it seems that lowering the EDMA30TC0 priority is indeed
> unnecessary, if I don't set the LCDC master to priority 0, I still get
> FIFO underflows even with the change in PBBPR.

I believe it is valid to raise the LCDC priority, but I wonder what blocks the
LCDC accesses when you don't really have anything going on in the background.

-- 
P?ter