* oleg.matcovs...@ti.com <oleg.matcovs...@ti.com> [121115 13:42]:
> From: Oleg Matcovschi <oleg.matcovs...@ti.com>
>
> OMAP_MODE_GPIO() macro verified only OMAP_MUX_MODE4.
Indeed, that needs to be fixed.
> It is not correct for following platforms:
> 2430 - gpio mux mode 3
> 44xx - gpio mux mode 3
Looks like these are set properly to GPIO_IN_MODE3 with
omap_mux_init().
> 54xx - gpio mux mode 6
This will be only using pinctrl-single.c, so we don't
really have to worrry about this one. But I guess we might
as well fix that too while at it if somebody backports omap5
support to some older kernel..
> Patch reserves first 3 bits in partition flags for storing gpio mux
> mode in same format as stored in control pad register.
> Modified OMAP_MODE_GPIO() macro handles all possible cases of gpio mux mode.
> Modified omap_mux_init() flags of omap34xx to include OMAP_MUX_GPIO_IN_MODE4.
Why don't you just add int gpio to struct omap_mux_partition?
You're not saving many bytes as at most we have two partitions
so far per SoC.
> --- a/arch/arm/mach-omap2/mux34xx.c
> +++ b/arch/arm/mach-omap2/mux34xx.c
> @@ -2053,7 +2053,7 @@ int __init omap3_mux_init(struct omap_board_mux
> *board_subset, int flags)
> return -EINVAL;
> }
>
> - return omap_mux_init("core", 0,
> + return omap_mux_init("core", OMAP_MUX_GPIO_IN_MODE4,
> OMAP3_CONTROL_PADCONF_MUX_PBASE,
> OMAP3_CONTROL_PADCONF_MUX_SIZE,
> omap3_muxmodes, package_subset, board_subset,
The default is GPIO_IN_MODE4, but that seems to be a bad
default choice as only omap3 uses it. So yeah, might as well
initialize that too and not assume any defaults GPIO mode.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
