Message ID | 3F263ABB4EDE344D974E1983B56807739E868EAB@EX-DAG01.eckelmann.group |
---|---|
State | New |
Headers | show |
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
--- 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)
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