Re: Problem specifying which gpio_126 to use on omap353x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Peter Barada <peter.barada@xxxxxxxxx> [100218 08:36]:
> On my board I have an isp1760 hooked up using gpio_126 (pin P27 -
> MMC1_DAT4/SIM_IO/GPIO_126).  From the schematics (and TRM), there is a
> 2nd gpio_126 on pin D25 (CAM_STROBE/GPIO_126).
> 
> I tried to use:
> 
> #define ISP1760_IRQ 126
> 
> omap_mux_init_gpio(ISP1760_IRQ, OMAP_PIN_INPUT_PULLUP);
> if (gpio_request(ISP1760_IRQ, "isp1760 IRQ") < 0) {
>     printk(KERN_ERR "Failed to request GPIO%d for isp1760IRQ\n", ISP1760_IRQ);
>     return;
> }
> 
> And in the log I see:
> 
> mux: Multiple gpio paths for gpio126
> mux: Multiple gpio paths for gpio126
> Failed to request GPIO126 for isp1760 IRQ
> 
> How do I tell gpio_request()and friends that I want to use GPIO_126 on
> pin P27, not GPIO_126 on pin D25?

For omap_mux_init_signal you need to use the full signal name.
So something like "sdmmc1_dat4.gpio_126" should work with
omap_mux_init_signal.

I guess at some point we could patch to omap_mux_init_gpio to call
omap_mux_init_signal if the full path is specified.

I guess you already know this, but you also need to check the packaging
you're using as the pin numbering is package specific. If you have the
system booting, it's easiest to look under omap_mux under debugfs. Or 
search in mux34xx.c.

Also, the data is generated from TRMs, and there may be some errors in
the data too.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux