colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

[pieterg]

In colibri-pxa300.c, line 132, gpio config GPIO62_LCD_CS_N is overriding the 
GPIO62_LCD_LDD_8 configuration, earlier in the pin config table.

As a result, one pixel data line is missing, obviously causing wrong pixel 
data on passive lcd panels.

Not sure what the best workaround should be.
LDD_CS is not available on the colibri evalboard as far as I can see, so we 
might just define GPIO127_LCD_CS_N instead? (till the soc/carrier board 
configs have been split)

Or for now just put GPIO62_LCD_CS_N between
#ifdef CONFIG_FB_PXA_SMARTPANEL?

Rgds, Pieter

colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

[Eric Miao]

On Mon, Sep 6, 2010 at 9:12 PM, pieterg <pieterg@gmx.com> wrote:
> In colibri-pxa300.c, line 132, gpio config GPIO62_LCD_CS_N is overriding the
> GPIO62_LCD_LDD_8 configuration, earlier in the pin config table.
>
> As a result, one pixel data line is missing, obviously causing wrong pixel
> data on passive lcd panels.
>
> Not sure what the best workaround should be.
> LDD_CS is not available on the colibri evalboard as far as I can see, so we
> might just define GPIO127_LCD_CS_N instead? (till the soc/carrier board
> configs have been split)
>
> Or for now just put GPIO62_LCD_CS_N between
> #ifdef CONFIG_FB_PXA_SMARTPANEL?
>

Possibly define two groups of LCD pin configurations and select them
when the appropriate LCD expansion card is plugged. If it can be
detected at run-time, that will be perfect, otherwise have to come
up with ugly #ifdef .. #else then.

> Rgds, Pieter
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

[pieterg]

On Tuesday 07 September 2010 04:43:31 Eric Miao wrote:
> On Mon, Sep 6, 2010 at 9:12 PM, pieterg <pieterg@gmx.com> wrote:
> > In colibri-pxa300.c, line 132, gpio config GPIO62_LCD_CS_N is
> > overriding the GPIO62_LCD_LDD_8 configuration, earlier in the pin
> > config table.
> >
> > As a result, one pixel data line is missing, obviously causing wrong
> > pixel data on passive lcd panels.
> >
> > Not sure what the best workaround should be.
> > LDD_CS is not available on the colibri evalboard as far as I can see,
> > so we might just define GPIO127_LCD_CS_N instead? (till the soc/carrier
> > board configs have been split)
> >
> > Or for now just put GPIO62_LCD_CS_N between
> > #ifdef ?
>
> Possibly define two groups of LCD pin configurations and select them
> when the appropriate LCD expansion card is plugged. If it can be
> detected at run-time, that will be perfect, otherwise have to come
> up with ugly #ifdef .. #else then.

I don't think you can detect whether an active or passive lcd panel is used.
And since the LCD_CS_N is only used for active panels, we can be sure that 
we only need it when CONFIG_FB_PXA_SMARTPANEL is defined.
So though it's ugly, it is already there, and we can use it.

Rgds, Pieter

colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

[Eric Miao]

On Tue, Sep 7, 2010 at 3:20 PM, pieterg <pieterg@gmx.com> wrote:
> On Tuesday 07 September 2010 04:43:31 Eric Miao wrote:
>> On Mon, Sep 6, 2010 at 9:12 PM, pieterg <pieterg@gmx.com> wrote:
>> > In colibri-pxa300.c, line 132, gpio config GPIO62_LCD_CS_N is
>> > overriding the GPIO62_LCD_LDD_8 configuration, earlier in the pin
>> > config table.
>> >
>> > As a result, one pixel data line is missing, obviously causing wrong
>> > pixel data on passive lcd panels.
>> >
>> > Not sure what the best workaround should be.
>> > LDD_CS is not available on the colibri evalboard as far as I can see,
>> > so we might just define GPIO127_LCD_CS_N instead? (till the soc/carrier
>> > board configs have been split)
>> >
>> > Or for now just put GPIO62_LCD_CS_N between
>> > #ifdef ?
>>
>> Possibly define two groups of LCD pin configurations and select them
>> when the appropriate LCD expansion card is plugged. If it can be
>> detected at run-time, that will be perfect, otherwise have to come
>> up with ugly #ifdef .. #else then.
>
> I don't think you can detect whether an active or passive lcd panel is used.
> And since the LCD_CS_N is only used for active panels, we can be sure that
> we only need it when CONFIG_FB_PXA_SMARTPANEL is defined.
> So though it's ugly, it is already there, and we can use it.
>

CONFIG_FB_PXA_SMARTPANEL is an inclusive config option not
a mutual exclusive, so it's enabling a capability. Even if it's selected
the board code can still select parallel/smartpanel protocol in the
pxafb_mach_info.lcd_conn field. It just cannot be used safely here.

If it's not run-time detectable, the ugliest way is to add a board
specific kernel command line option, though I'd shrug.

> Rgds, Pieter
>

colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

[pieterg]

On Tuesday 07 September 2010 09:29:59 Eric Miao wrote:
> On Tue, Sep 7, 2010 at 3:20 PM, pieterg <pieterg@gmx.com> wrote:
> > On Tuesday 07 September 2010 04:43:31 Eric Miao wrote:
> >> On Mon, Sep 6, 2010 at 9:12 PM, pieterg <pieterg@gmx.com> wrote:
> >> > In colibri-pxa300.c, line 132, gpio config GPIO62_LCD_CS_N is
> >> > overriding the GPIO62_LCD_LDD_8 configuration, earlier in the pin
> >> > config table.
> >> >
> >> > As a result, one pixel data line is missing, obviously causing wrong
> >> > pixel data on passive lcd panels.
> >> >
> >> > Not sure what the best workaround should be.
> >> > LDD_CS is not available on the colibri evalboard as far as I can
> >> > see, so we might just define GPIO127_LCD_CS_N instead? (till the
> >> > soc/carrier board configs have been split)
> >> >
> >> > Or for now just put GPIO62_LCD_CS_N between
> >> > #ifdef ?
> >>
> >> Possibly define two groups of LCD pin configurations and select them
> >> when the appropriate LCD expansion card is plugged. If it can be
> >> detected at run-time, that will be perfect, otherwise have to come
> >> up with ugly #ifdef .. #else then.
> >
> > I don't think you can detect whether an active or passive lcd panel is
> > used. And since the LCD_CS_N is only used for active panels, we can be
> > sure that we only need it when CONFIG_FB_PXA_SMARTPANEL is defined.
> > So though it's ugly, it is already there, and we can use it.
>
> CONFIG_FB_PXA_SMARTPANEL is an inclusive config option not
> a mutual exclusive, so it's enabling a capability. Even if it's selected
> the board code can still select parallel/smartpanel protocol in the
> pxafb_mach_info.lcd_conn field. It just cannot be used safely here.

OK, I didn't realise that. In that case we cannot use it.

> If it's not run-time detectable, the ugliest way is to add a board
> specific kernel command line option, though I'd shrug.

I think a command line option is almost as ugly as a CONFIG define ;)
How about using GPIO127_LCD_CS_N instead? Then at least we won't have a 
conflict with the LDD pins.
I don't know why the conflicting GPIO62_LCD_CS_N was chosen in the first 
place?

Rgds, Pieter

colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

[Eric Miao]

On Tue, Sep 7, 2010 at 5:15 PM, pieterg <pieterg@gmx.com> wrote:
> On Tuesday 07 September 2010 09:29:59 Eric Miao wrote:
>> On Tue, Sep 7, 2010 at 3:20 PM, pieterg <pieterg@gmx.com> wrote:
>> > On Tuesday 07 September 2010 04:43:31 Eric Miao wrote:
>> >> On Mon, Sep 6, 2010 at 9:12 PM, pieterg <pieterg@gmx.com> wrote:
>> >> > In colibri-pxa300.c, line 132, gpio config GPIO62_LCD_CS_N is
>> >> > overriding the GPIO62_LCD_LDD_8 configuration, earlier in the pin
>> >> > config table.
>> >> >
>> >> > As a result, one pixel data line is missing, obviously causing wrong
>> >> > pixel data on passive lcd panels.
>> >> >
>> >> > Not sure what the best workaround should be.
>> >> > LDD_CS is not available on the colibri evalboard as far as I can
>> >> > see, so we might just define GPIO127_LCD_CS_N instead? (till the
>> >> > soc/carrier board configs have been split)
>> >> >
>> >> > Or for now just put GPIO62_LCD_CS_N between
>> >> > #ifdef ?
>> >>
>> >> Possibly define two groups of LCD pin configurations and select them
>> >> when the appropriate LCD expansion card is plugged. If it can be
>> >> detected at run-time, that will be perfect, otherwise have to come
>> >> up with ugly #ifdef .. #else then.
>> >
>> > I don't think you can detect whether an active or passive lcd panel is
>> > used. And since the LCD_CS_N is only used for active panels, we can be
>> > sure that we only need it when CONFIG_FB_PXA_SMARTPANEL is defined.
>> > So though it's ugly, it is already there, and we can use it.
>>
>> CONFIG_FB_PXA_SMARTPANEL is an inclusive config option not
>> a mutual exclusive, so it's enabling a capability. Even if it's selected
>> the board code can still select parallel/smartpanel protocol in the
>> pxafb_mach_info.lcd_conn field. It just cannot be used safely here.
>
> OK, I didn't realise that. In that case we cannot use it.
>
>> If it's not run-time detectable, the ugliest way is to add a board
>> specific kernel command line option, though I'd shrug.
>
> I think a command line option is almost as ugly as a CONFIG define ;)
> How about using GPIO127_LCD_CS_N instead? Then at least we won't have a
> conflict with the LDD pins.
> I don't know why the conflicting GPIO62_LCD_CS_N was chosen in the first
> place?

That depends on hardware, it's not like whichever pin with functionality of
LCD_CS_N can be used. Need to check with schematics if the LCD_CS_N
signal is routed to GPIO62 or GPIO127.

>
> Rgds, Pieter
>

colibri-pxa300: LCD_LDD / LCD_CS gpio conflict

[pieterg]

On Tuesday 07 September 2010 11:50:08 Eric Miao wrote:
> On Tue, Sep 7, 2010 at 5:15 PM, pieterg <pieterg@gmx.com> wrote:
> > How about using GPIO127_LCD_CS_N instead? Then at least we won't have a
> > conflict with the LDD pins.
> > I don't know why the conflicting GPIO62_LCD_CS_N was chosen in the
> > first place?
>
> That depends on hardware, it's not like whichever pin with functionality
> of LCD_CS_N can be used. Need to check with schematics if the LCD_CS_N
> signal is routed to GPIO62 or GPIO127.

GPIO127 is available on the colibri connector (as well as 62 of course), but 
on the evalboard, there is no LCD_CS_N support (neither GPIO62 nor 
GPIO127).

Rgds, Pieter