multipath mux question

multipath mux question

[Grazvydas Ignotas]

Hi,

on OMAP3 CBB package GPIO126 can be muxed on 2 pins: mmc1_dat4 and
cam_strobe. On pandora mmc1_dat4 is connected to mmc1 write protect,
this makes omap2_mmc_mux() call omap_mux_init_gpio() on GPIO126, which
muxes both pins and warns:
mux: Multiple gpio paths for gpio126

This results in unusable GPIO. I wonder how should I handle this,
perhaps overriding mux by calling omap_mux_init_signal() after
omap2_hsmmc_init() call? Or maybe omap_mux_init_gpio() should be
patched not to set up GPIOs if it encounters multiple paths?

Re: multipath mux question

[Tony Lindgren]

* Grazvydas Ignotas <notasas@gmail.com> [100703 00:21]:
> Hi,
> 
> on OMAP3 CBB package GPIO126 can be muxed on 2 pins: mmc1_dat4 and
> cam_strobe. On pandora mmc1_dat4 is connected to mmc1 write protect,
> this makes omap2_mmc_mux() call omap_mux_init_gpio() on GPIO126, which
> muxes both pins and warns:
> mux: Multiple gpio paths for gpio126

OK.
 
> This results in unusable GPIO. I wonder how should I handle this,
> perhaps overriding mux by calling omap_mux_init_signal() after
> omap2_hsmmc_init() call? Or maybe omap_mux_init_gpio() should be
> patched not to set up GPIOs if it encounters multiple paths?

To me the safest route is the second option you suggest where
we refuse to mux GPIO pins that have multiple outputs. 

We should just print a warning and return an error. Then we should
also start checking the return values for omap_mux_init_gpio
now that the code is converted over to use the new mux code.

If you do a patch, please do it against omap for-next branch
as omap_mux_init_gpio has a pending patch for MUXABLE_GPIO_MODE3.

Regards,

Tony 

Re: multipath mux question

[Grazvydas Ignotas]

On Mon, Jul 5, 2010 at 10:36 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Grazvydas Ignotas <notasas@gmail.com> [100703 00:21]:
>> Hi,
>>
>> on OMAP3 CBB package GPIO126 can be muxed on 2 pins: mmc1_dat4 and
>> cam_strobe. On pandora mmc1_dat4 is connected to mmc1 write protect,
>> this makes omap2_mmc_mux() call omap_mux_init_gpio() on GPIO126, which
>> muxes both pins and warns:
>> mux: Multiple gpio paths for gpio126
>
> OK.
>
>> This results in unusable GPIO. I wonder how should I handle this,
>> perhaps overriding mux by calling omap_mux_init_signal() after
>> omap2_hsmmc_init() call? Or maybe omap_mux_init_gpio() should be
>> patched not to set up GPIOs if it encounters multiple paths?
>
> To me the safest route is the second option you suggest where
> we refuse to mux GPIO pins that have multiple outputs.
>
> We should just print a warning and return an error. Then we should
> also start checking the return values for omap_mux_init_gpio
> now that the code is converted over to use the new mux code.

Hm, not sure about return checking, what omap2_mmc_mux() can do when
it sees omap_mux_init_gpio failing because of that inevitable gpio126
multipath error?

> If you do a patch, please do it against omap for-next branch
> as omap_mux_init_gpio has a pending patch for MUXABLE_GPIO_MODE3.

ok

Re: multipath mux question

[Tony Lindgren]

* Grazvydas Ignotas <notasas@gmail.com> [100705 14:43]:
> On Mon, Jul 5, 2010 at 10:36 AM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > We should just print a warning and return an error. Then we should
> > also start checking the return values for omap_mux_init_gpio
> > now that the code is converted over to use the new mux code.
> 
> Hm, not sure about return checking, what omap2_mmc_mux() can do when
> it sees omap_mux_init_gpio failing because of that inevitable gpio126
> multipath error?

Heh, right :) I guess in that case omap2_mmc_mux should not do anything
and assume the board-*.c file has set up the muxing.
 
Regards,

Tony