iomux-mx25.h slew rate adjusted for LCD __LD pins

From: Mehnert <tmehnert@eckelmann.de>
Date: Mon, 13 Mar 2012 12:13:51 +0100
Subject: [PATCH] iomux-mx25.h slew rate adjusted for LCD __LD pins

For some reason (sadly i don't identifying the patch right now)
two LCD data lines configured PAD_CTL_SRE_SLOW (wrong slew rate)
since Kernel 3.1. MX25_PAD_GPIO_E__LD16 and MX25_PAD_GPIO_F__LD17
This results in an fauly behaviour and strange color effects.

To ensure that all LCD data pins configured with the proper slew rate,
this patch changes to IOMUX define of all LCD __LDxx pins to PAD_CTL_SRE_FAST.

This problem may affect other mx25 platforms like mx25pdk. Sadly i can't test
it. Of course this problem shouldn't occur when you done your LCD muxing 
correctly in the bootloader.

Best regards,
Torsten

---
---
Torsten Mehnert
Kälte- und Gebäudeleittechnik (KGL)
 
ECKELMANN AG
Berliner Straße 161
D - 65205 Wiesbaden
 
Phone:	+49 (0) 611 / 7103 - 370
Fax:	+49 (0) 611 / 7103 - 133

e-Mail:	mailto:t.mehnert@eckelmann.de
Web:	http://www.eckelmann.de

Hi

What a coincidence, we have been fighting with the LCD color issue on 
an i.MX258 about two weeks ago and came up with almost the same patch.

> For some reason (sadly i don't identifying the patch right now)
> two LCD data lines configured PAD_CTL_SRE_SLOW (wrong slew rate)
> since Kernel 3.1. MX25_PAD_GPIO_E__LD16 and MX25_PAD_GPIO_F__LD17
> This results in an fauly behaviour and strange color effects.
>
> To ensure that all LCD data pins configured with the proper slew 
> rate,
> this patch changes to IOMUX define of all LCD __LDxx pins to
> PAD_CTL_SRE_FAST.

For us it was enough to change the MX25_PAD_GPIO_E__LD16 and 
MX25_PAD_GPIO_F__LD17 pins to PAD_CTL_SRE_FAST. Why do you need to 
change the others too? Could this introduce undesired signal noise on 
the board? We actually experience a weird effect on the ADC lines. It's 
all been discussed here:



> This problem may affect other mx25 platforms like mx25pdk. Sadly i 
> can't test
> it. Of course this problem shouldn't occur when you done your LCD 
> muxing
> correctly in the bootloader.

Would you care to explain how to perform the "LCD muxing correctly" in 
the bootloader and why it should influence what the kernel does?

I will test your patch (adding PAD_CTL_SRE_FAST to all __LDxx pins 
instead of just LD16 and LD17) and report back. In any case, I can 
confirm that without this patch the LCD has weird colors. Juergen 
Beisert has more iomux-mx25.h changes, especially with regard to PWM, so 
I reckon he'll send them upstream soon enough.

> @@ -468,11 +468,11 @@
>  #define MX25_PAD_GPIO_C__CAN2_TX	IOMUX_PAD(0x3f8, 0x1fc, 0x16, 0, 0,
> PAD_CTL_PUS_22K_UP)
>
>  #define MX25_PAD_GPIO_D__GPIO_D		IOMUX_PAD(0x3fc, 0x200, 0x10, 0, 0,
> NO_PAD_CTRL)
> -#define MX25_PAD_GPIO_E__LD16		IOMUX_PAD(0x400, 0x204, 0x02, 0, 0,
> NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_E__LD16		IOMUX_PAD(0x400, 0x204, 0x02, 0, 0,
> PAD_CTL_SRE_FAST)
>  #define MX25_PAD_GPIO_D__CAN2_RX	IOMUX_PAD(0x3fc, 0x200, 0x16,
> 0x484, 1, PAD_CTL_PUS_22K_UP)
>
>  #define MX25_PAD_GPIO_E__GPIO_E		IOMUX_PAD(0x400, 0x204, 0x10, 0, 0,
> NO_PAD_CTRL)
> -#define MX25_PAD_GPIO_F__LD17		IOMUX_PAD(0x404, 0x208, 0x02, 0, 0,
> NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_F__LD17		IOMUX_PAD(0x404, 0x208, 0x02, 0, 0,
> PAD_CTL_SRE_FAST)
>  #define MX25_PAD_GPIO_E__AUD7_TXD	IOMUX_PAD(0x400, 0x204, 0x14, 0,
> 0, NO_PAD_CTRL)
>
>  #define MX25_PAD_GPIO_F__GPIO_F		IOMUX_PAD(0x404, 0x208, 0x10, 0, 0,
> NO_PAD_CTRL)

As mentioned above, this is the only part we needed from the patch to 
address the wrong slew rate for the LCD color wash-out. But I am curious 
as to hear your explanation with regard to changing the slew rate of the 
other __LDxx pins.

Best regards

> Hi

Hi again

> What a coincidence, we have been fighting with the LCD color issue on an i.MX258 about two weeks ago and came up with almost the same patch.
Sounds like we hit the problem in the right way. Super! :)

> > For some reason (sadly i don't identifying the patch right now) two 
> > LCD data lines configured PAD_CTL_SRE_SLOW (wrong slew rate) since 
> > Kernel 3.1. MX25_PAD_GPIO_E__LD16 and MX25_PAD_GPIO_F__LD17 This 
> > results in an fauly behaviour and strange color effects.
> >
> > To ensure that all LCD data pins configured with the proper slew rate, 
> > this patch changes to IOMUX define of all LCD __LDxx pins to 
> > PAD_CTL_SRE_FAST.

> For us it was enough to change the MX25_PAD_GPIO_E__LD16 and
> MX25_PAD_GPIO_F__LD17 pins to PAD_CTL_SRE_FAST. Why do you need to change the others too? Could this introduce undesired signal noise on the board? We actually experience a weird effect on the ADC lines. It's all 
> been discussed here:
For our display problem it's also enough to set MX25_PAD_GPIO_E__LD16 and MX25_PAD_GPIO_F__LD17 to fast slew rate. So far i can confirm that your patch solves the problem.

The reason I decided to change the other line muxings too is the tought, that when these two lines need to set to fast slew rate, all other line need to set to fast slew rate too.
For some reason (I actually don't know) the other lines seems to be set >implicit< correctly to fast slew rate. In order to avoid future problems I set them explicit to fast slew rate.

Seeing the aspect that all LD lines implicit set to fast slew rate, there would no electrical change if you set them explicit. For all the other lines (not LD16 and LD17)
The code effectivly changes nothing, but ensures the fast slew rate in future. 
That's the idea, but I can't confirm my assumption by measurement.
What's your opinion? 

I checked my ADC right now. We use it to read out touchscreen. I can't find any problems, all seems to be okay.
What's your use of it?

>  It's all been discussed here
shame on me, I missed the post.^^ But I will read it now.

> > This problem may affect other mx25 platforms like mx25pdk. Sadly i 
> > can't test it. Of course this problem shouldn't occur when you done 
> > your LCD muxing correctly in the bootloader.

> Would you care to explain how to perform the "LCD muxing correctly" in the bootloader and why it should influence what the kernel does?

We have moved our Kernel from 3.0 to 3.2 the LCD problem occurs.
When booting the 3.0 kernel and the reboot and "warm starting" the 3.2 kernel the display running fine.
When "cold starting" the 3.2 kernel the display problem occurs.

So that lead to the knowledge that there must be an initialization problem. What happened?
The 3.0 kernel starts and init the pins correctly. These pin settings kept by "warm starting" the 3.2
Kernel, so it can drive the display correctly. So the 3.2 seems not touching these settings.

So far I've come to the idea, that the problem shouldn't occur on boards where the muxing of the LCD
completely done by bootloader. Which is not in my case, but I think this theory could explain it
when some mx25 board dons't have the problem with the lcd.


> I will test your patch (adding PAD_CTL_SRE_FAST to all __LDxx pins instead of just LD16 and LD17) and report back. In any case, I can confirm that without this patch the LCD has weird colors. Juergen Beisert has more iomux
> mx25.h changes, especially with regard to PWM, so I reckon he'll send them upstream soon enough.
Thanks

> @@ -468,11 +468,11 @@
>  #define MX25_PAD_GPIO_C__CAN2_TX	IOMUX_PAD(0x3f8, 0x1fc, 0x16, 0, 0,
> PAD_CTL_PUS_22K_UP)
>
>  #define MX25_PAD_GPIO_D__GPIO_D		IOMUX_PAD(0x3fc, 0x200, 0x10, 0, 0,
> NO_PAD_CTRL)
> -#define MX25_PAD_GPIO_E__LD16		IOMUX_PAD(0x400, 0x204, 0x02, 0, 0,
> NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_E__LD16		IOMUX_PAD(0x400, 0x204, 0x02, 0, 0,
> PAD_CTL_SRE_FAST)
>  #define MX25_PAD_GPIO_D__CAN2_RX	IOMUX_PAD(0x3fc, 0x200, 0x16,
> 0x484, 1, PAD_CTL_PUS_22K_UP)
>
>  #define MX25_PAD_GPIO_E__GPIO_E		IOMUX_PAD(0x400, 0x204, 0x10, 0, 0,
> NO_PAD_CTRL)
> -#define MX25_PAD_GPIO_F__LD17		IOMUX_PAD(0x404, 0x208, 0x02, 0, 0,
> NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_F__LD17		IOMUX_PAD(0x404, 0x208, 0x02, 0, 0,
> PAD_CTL_SRE_FAST)
>  #define MX25_PAD_GPIO_E__AUD7_TXD	IOMUX_PAD(0x400, 0x204, 0x14, 0,
> 0, NO_PAD_CTRL)
>
>  #define MX25_PAD_GPIO_F__GPIO_F		IOMUX_PAD(0x404, 0x208, 0x10, 0, 0,
> NO_PAD_CTRL)

> As mentioned above, this is the only part we needed from the patch to address the wrong slew rate for the LCD color wash-out. But I am curious as to hear your explanation with regard to changing the slew rate of the other > __LDxx pins.

I must admit that I'm not the most experienced kernel developer, so far it would be possible that the idea of setting all LDxx pins explicit fast is not the best idea.
So I hoping for a divine inspiration :)

Thanks for your answer
Torsten

Best regards
--
Joan C. Abelaira

On Tue, Mar 13, 2012 at 11:35:22AM +0000, Mehnert, Torsten wrote:
> From: Mehnert <tmehnert@eckelmann.de>
> Date: Mon, 13 Mar 2012 12:13:51 +0100
> Subject: [PATCH] iomux-mx25.h slew rate adjusted for LCD __LD pins
> 
> For some reason (sadly i don't identifying the patch right now)
> two LCD data lines configured PAD_CTL_SRE_SLOW (wrong slew rate)
> since Kernel 3.1. MX25_PAD_GPIO_E__LD16 and MX25_PAD_GPIO_F__LD17
> This results in an fauly behaviour and strange color effects.
> 
> To ensure that all LCD data pins configured with the proper slew rate,
> this patch changes to IOMUX define of all LCD __LDxx pins to PAD_CTL_SRE_FAST.
> 
> This problem may affect other mx25 platforms like mx25pdk. Sadly i can't test
> it. Of course this problem shouldn't occur when you done your LCD muxing 
> correctly in the bootloader.

Applied, thanks

Sascha

> 
> Best regards,
> Torsten
> 
> ---
> --- a/arch/arm/plat-mxc/include/mach/iomux-mx25.h	2012-02-28 00:43:05.000000000 +0100
> +++ b/arch/arm/plat-mxc/include/mach/iomux-mx25.h	2012-03-13 12:08:39.920736789 +0100
> @@ -139,15 +139,15 @@
>  #define MX25_PAD_NFRB__GPIO_3_31	IOMUX_PAD(0x27c, 0x084, 0x15, 0, 0, NO_PAD_CTRL)
>  
>  #define MX25_PAD_D15__D15		IOMUX_PAD(0x280, 0x088, 0x00, 0, 0, NO_PAD_CTRL)
> -#define MX25_PAD_D15__LD16		IOMUX_PAD(0x280, 0x088, 0x01, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_D15__LD16		IOMUX_PAD(0x280, 0x088, 0x01, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_D15__GPIO_4_5		IOMUX_PAD(0x280, 0x088, 0x05, 0, 0, NO_PAD_CTRL)
>  
>  #define MX25_PAD_D14__D14		IOMUX_PAD(0x284, 0x08c, 0x00, 0, 0, NO_PAD_CTRL)
> -#define MX25_PAD_D14__LD17		IOMUX_PAD(0x284, 0x08c, 0x01, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_D14__LD17		IOMUX_PAD(0x284, 0x08c, 0x01, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_D14__GPIO_4_6		IOMUX_PAD(0x284, 0x08c, 0x05, 0, 0, NO_PAD_CTRL)
>  
>  #define MX25_PAD_D13__D13		IOMUX_PAD(0x288, 0x090, 0x00, 0, 0, NO_PAD_CTRL)
> -#define MX25_PAD_D13__LD18		IOMUX_PAD(0x288, 0x090, 0x01, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_D13__LD18		IOMUX_PAD(0x288, 0x090, 0x01, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_D13__GPIO_4_7		IOMUX_PAD(0x288, 0x090, 0x05, 0, 0, NO_PAD_CTRL)
>  
>  #define MX25_PAD_D12__D12		IOMUX_PAD(0x28c, 0x094, 0x00, 0, 0, NO_PAD_CTRL)
> @@ -192,54 +192,54 @@
>  #define MX25_PAD_D0__D0			IOMUX_PAD(0x2bc, 0x0c4, 0x00, 0, 0, NO_PAD_CTRL)
>  #define MX25_PAD_D0__GPIO_4_20		IOMUX_PAD(0x2bc, 0x0c4, 0x05, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD0__LD0		IOMUX_PAD(0x2c0, 0x0c8, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD0__LD0		IOMUX_PAD(0x2c0, 0x0c8, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD0__CSI_D0		IOMUX_PAD(0x2c0, 0x0c8, 0x12, 0x488, 0, NO_PAD_CTRL)
>  #define MX25_PAD_LD0__GPIO_2_15		IOMUX_PAD(0x2c0, 0x0c8, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD1__LD1		IOMUX_PAD(0x2c4, 0x0cc, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD1__LD1		IOMUX_PAD(0x2c4, 0x0cc, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD1__CSI_D1		IOMUX_PAD(0x2c4, 0x0cc, 0x12, 0x48c, 0, NO_PAD_CTRL)
>  #define MX25_PAD_LD1__GPIO_2_16		IOMUX_PAD(0x2c4, 0x0cc, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD2__LD2		IOMUX_PAD(0x2c8, 0x0d0, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD2__LD2		IOMUX_PAD(0x2c8, 0x0d0, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD2__GPIO_2_17		IOMUX_PAD(0x2c8, 0x0d0, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD3__LD3		IOMUX_PAD(0x2cc, 0x0d4, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD3__LD3		IOMUX_PAD(0x2cc, 0x0d4, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD3__GPIO_2_18		IOMUX_PAD(0x2cc, 0x0d4, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD4__LD4		IOMUX_PAD(0x2d0, 0x0d8, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD4__LD4		IOMUX_PAD(0x2d0, 0x0d8, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD4__GPIO_2_19		IOMUX_PAD(0x2d0, 0x0d8, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD5__LD5		IOMUX_PAD(0x2d4, 0x0dc, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD5__LD5		IOMUX_PAD(0x2d4, 0x0dc, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD5__GPIO_1_19		IOMUX_PAD(0x2d4, 0x0dc, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD6__LD6		IOMUX_PAD(0x2d8, 0x0e0, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD6__LD6		IOMUX_PAD(0x2d8, 0x0e0, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD6__GPIO_1_20		IOMUX_PAD(0x2d8, 0x0e0, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD7__LD7		IOMUX_PAD(0x2dc, 0x0e4, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD7__LD7		IOMUX_PAD(0x2dc, 0x0e4, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD7__GPIO_1_21		IOMUX_PAD(0x2dc, 0x0e4, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD8__LD8		IOMUX_PAD(0x2e0, 0x0e8, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD8__LD8		IOMUX_PAD(0x2e0, 0x0e8, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD8__FEC_TX_ERR	IOMUX_PAD(0x2e0, 0x0e8, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD9__LD9		IOMUX_PAD(0x2e4, 0x0ec, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD9__LD9		IOMUX_PAD(0x2e4, 0x0ec, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD9__FEC_COL		IOMUX_PAD(0x2e4, 0x0ec, 0x15, 0x504, 1, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD10__LD10		IOMUX_PAD(0x2e8, 0x0f0, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD10__LD10		IOMUX_PAD(0x2e8, 0x0f0, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD10__FEC_RX_ER	IOMUX_PAD(0x2e8, 0x0f0, 0x15, 0x518, 1, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD11__LD11		IOMUX_PAD(0x2ec, 0x0f4, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD11__LD11		IOMUX_PAD(0x2ec, 0x0f4, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD11__FEC_RDATA2	IOMUX_PAD(0x2ec, 0x0f4, 0x15, 0x50c, 1, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD12__LD12		IOMUX_PAD(0x2f0, 0x0f8, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD12__LD12		IOMUX_PAD(0x2f0, 0x0f8, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD12__FEC_RDATA3	IOMUX_PAD(0x2f0, 0x0f8, 0x15, 0x510, 1, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD13__LD13		IOMUX_PAD(0x2f4, 0x0fc, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD13__LD13		IOMUX_PAD(0x2f4, 0x0fc, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD13__FEC_TDATA2	IOMUX_PAD(0x2f4, 0x0fc, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD14__LD14		IOMUX_PAD(0x2f8, 0x100, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD14__LD14		IOMUX_PAD(0x2f8, 0x100, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD14__FEC_TDATA3	IOMUX_PAD(0x2f8, 0x100, 0x15, 0, 0, NO_PAD_CTRL)
>  
> -#define MX25_PAD_LD15__LD15		IOMUX_PAD(0x2fc, 0x104, 0x10, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_LD15__LD15		IOMUX_PAD(0x2fc, 0x104, 0x10, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_LD15__FEC_RX_CLK	IOMUX_PAD(0x2fc, 0x104, 0x15, 0x514, 1, NO_PAD_CTRL)
>  
>  #define MX25_PAD_HSYNC__HSYNC		IOMUX_PAD(0x300, 0x108, 0x10, 0, 0, NO_PAD_CTRL)
> @@ -468,11 +468,11 @@
>  #define MX25_PAD_GPIO_C__CAN2_TX	IOMUX_PAD(0x3f8, 0x1fc, 0x16, 0, 0, PAD_CTL_PUS_22K_UP)
>  
>  #define MX25_PAD_GPIO_D__GPIO_D		IOMUX_PAD(0x3fc, 0x200, 0x10, 0, 0, NO_PAD_CTRL)
> -#define MX25_PAD_GPIO_E__LD16		IOMUX_PAD(0x400, 0x204, 0x02, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_E__LD16		IOMUX_PAD(0x400, 0x204, 0x02, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_GPIO_D__CAN2_RX	IOMUX_PAD(0x3fc, 0x200, 0x16, 0x484, 1, PAD_CTL_PUS_22K_UP)
>  
>  #define MX25_PAD_GPIO_E__GPIO_E		IOMUX_PAD(0x400, 0x204, 0x10, 0, 0, NO_PAD_CTRL)
> -#define MX25_PAD_GPIO_F__LD17		IOMUX_PAD(0x404, 0x208, 0x02, 0, 0, NO_PAD_CTRL)
> +#define MX25_PAD_GPIO_F__LD17		IOMUX_PAD(0x404, 0x208, 0x02, 0, 0, PAD_CTL_SRE_FAST)
>  #define MX25_PAD_GPIO_E__AUD7_TXD	IOMUX_PAD(0x400, 0x204, 0x14, 0, 0, NO_PAD_CTRL)
>  
>  #define MX25_PAD_GPIO_F__GPIO_F		IOMUX_PAD(0x404, 0x208, 0x10, 0, 0, NO_PAD_CTRL)
> ---
> Torsten Mehnert
> Kälte- und Gebäudeleittechnik (KGL)
>  
> ECKELMANN AG
> Berliner Straße 161
> D - 65205 Wiesbaden
>  
> Phone:	+49 (0) 611 / 7103 - 370
> Fax:	+49 (0) 611 / 7103 - 133
> 
> e-Mail:	mailto:t.mehnert@eckelmann.de
> Web:	http://www.eckelmann.de
> 
>

Hi

>> What a coincidence, we have been fighting with the LCD color issue 
>> on an i.MX258 about two weeks ago and came up with almost the same 
>> patch.
> Sounds like we hit the problem in the right way. Super! :)

I am glad there's someone else with the same issue and solution ;).

>> For us it was enough to change the MX25_PAD_GPIO_E__LD16 and
>> MX25_PAD_GPIO_F__LD17 pins to PAD_CTL_SRE_FAST. Why do you need to 
>> change the others too? Could this introduce undesired signal noise on 
>> the board? We actually experience a weird effect on the ADC lines. 
>> It's all
>> been discussed here:
> For our display problem it's also enough to set MX25_PAD_GPIO_E__LD16
> and MX25_PAD_GPIO_F__LD17 to fast slew rate. So far i can confirm 
> that
> your patch solves the problem.

Good to know.

> The reason I decided to change the other line muxings too is the
> tought, that when these two lines need to set to fast slew rate, all
> other line need to set to fast slew rate too.
> For some reason (I actually don't know) the other lines seems to be
> set >implicit< correctly to fast slew rate. In order to avoid future
> problems I set them explicit to fast slew rate.

I see. Well, we shouldn't be taping possible future failures of 
hardware configuration, since the original change wasn't provoked in any 
way by a change of the slew rate of the before mentioned pins. I reckon 
it has more to do with the different ways the mx25 is initialized these 
days compared to, let's say 2.6.39.x (which was the last kernel our LCD 
screen worked without wash-out and no changes to the slew rate of said 
pins).

> Seeing the aspect that all LD lines implicit set to fast slew rate,

How do you see that?

> there would no electrical change if you set them explicit. For all 
> the
> other lines (not LD16 and LD17)
> The code effectivly changes nothing, but ensures the fast slew rate
> in future.
> That's the idea, but I can't confirm my assumption by measurement.
> What's your opinion?

I could give it a go on the oscilloscope, however the changes in the 
signal tangent might be really tiny.

> I checked my ADC right now. We use it to read out touchscreen. I
> can't find any problems, all seems to be okay.
> What's your use of it?

Touchscreen only, however we've been having our share of fun with it. 
It's still not stable, but that's largely off-topic here at the moment. 
Juergen Beisert (our local hero) has written a ADC/TS driver from 
scratch for the i.MX25 platforms, which is very nicely engineered and 
seems to work just fine. He's posted it to this list a couple of days 
ago for initial comment. After some changes with regard to 
HSYNC/Polarity settings to his driver and some capacitors to the lines 
between the LCD and the ADC, we have a more or less stable reading, with 
a jitter of +-8px.

>>  It's all been discussed here
> shame on me, I missed the post.^^ But I will read it now.

No, shame on me, I forgot to post the link to the discussion, which has 
not at all happened on this mailing list. Here it is:

http://news.gmane.org/gmane.comp.embedded.ptxdist.oselas.community

Search for the "Kernel 3.3 custom mx25 device touchscreen issues" 
thread to find the whole development of two issues: the touchscreen not 
working because of other hardware failures and an initially flaky TS/ADC 
driver, and this issue with regard to the LCD washout effects.

>> Would you care to explain how to perform the "LCD muxing correctly" 
>> in the bootloader and why it should influence what the kernel does?
>
> We have moved our Kernel from 3.0 to 3.2 the LCD problem occurs.
> When booting the 3.0 kernel and the reboot and "warm starting" the
> 3.2 kernel the display running fine.
> When "cold starting" the 3.2 kernel the display problem occurs.

Interesting! What's your device? A custom mx25 board?

> So that lead to the knowledge that there must be an initialization
> problem. What happened?
> The 3.0 kernel starts and init the pins correctly. These pin settings
> kept by "warm starting" the 3.2
> Kernel, so it can drive the display correctly. So the 3.2 seems not
> touching these settings.

For us this did not happen. Booting a 2.6.39.3 kernel worked correctly 
and subsequently "warm starting" or rebooting  with an unpatched 3.3 
kernel created these wash-out effects on our LCD.

> So far I've come to the idea, that the problem shouldn't occur on
> boards where the muxing of the LCD
> completely done by bootloader. Which is not in my case, but I think
> this theory could explain it
> when some mx25 board dons't have the problem with the lcd.

I haven't had a look at the bootloader yet, we're using an old version 
(2010) of u-boot. The issue there is that we boot from NOR and made a 
lot of patches to support our device. Forward porting to a newer release 
of u-boot right now seems like a daunting task, as too many things have 
changed since.

> I must admit that I'm not the most experienced kernel developer, so
> far it would be possible that the idea of setting all LDxx pins
> explicit fast is not the best idea.

 From many years ago, working on the Intel side of kernel hacking, I 
remember that in the community there was always some resistance in 
accepting patches where the origins of the failure of a component wasn't 
really 100% clear. It's clear here, but your patch seems to change 
additional default values for no apparent reason, other than preventing 
another debugging session in the future, should this incidence occur 
again with regard to the other __LDxx pins.

> So I hoping for a divine inspiration :)

That's two of us now ;).

Thanks for your time and insightful discussion.

Cheers

On Tue, Mar 13, 2012 at 11:35:22AM +0000, Mehnert, Torsten wrote:
> From: Mehnert <tmehnert@eckelmann.de>
> Date: Mon, 13 Mar 2012 12:13:51 +0100
> Subject: [PATCH] iomux-mx25.h slew rate adjusted for LCD __LD pins
> 
> For some reason (sadly i don't identifying the patch right now)
> two LCD data lines configured PAD_CTL_SRE_SLOW (wrong slew rate)
> since Kernel 3.1. MX25_PAD_GPIO_E__LD16 and MX25_PAD_GPIO_F__LD17
> This results in an fauly behaviour and strange color effects.
> 
> To ensure that all LCD data pins configured with the proper slew rate,
> this patch changes to IOMUX define of all LCD __LDxx pins to PAD_CTL_SRE_FAST.
> 
> This problem may affect other mx25 platforms like mx25pdk. Sadly i can't test
> it. Of course this problem shouldn't occur when you done your LCD muxing 
> correctly in the bootloader.

Your patch lacks a signed-off-by Tag. Please remember adding it next
time. For now it should be enough to answer your original mail with
a

Signed-off-by: Torsten Mehnert <T.Mehnert@eckelmann.de>

Sascha