[PATCH] iomux-mx25.h slew rate adjusted for LCD __LD pins
joancarles
joancarles at fqingenieria.es
Tue Mar 13 07:59:12 EDT 2012
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
--
Joan C. Abelaira
More information about the linux-arm-kernel
mailing list