Message ID | 20131217210403.GA1196@katana (mailing list archive) |
---|---|
State | Awaiting Upstream |
Delegated to: | Paul Mundt |
Headers | show |
Hi Wolfram, On Wed, Dec 18, 2013 at 6:04 AM, Wolfram Sang <wsa@the-dreams.de> wrote: > Hi, > >> +#define _P_DATA(bank, pin, name, sfx) \ >> + PINMUX_DATA(name##_DATA, name##_PMC_0, name##_PIPC_0, \ >> + name##_PIBC_1, name##_PBDC_1) >> + >> +#define _P_FN(n, fn, pfcae, pfce, pfc) \ >> + PINMUX_DATA(n##_MARK_FN##fn, n##_PMC_1, n##_PIPC_1, \ >> + n##_PFCAE_##pfcae, n##_PFCE_##pfce, n##_PFC_##pfc) > > I need to apply this patch, otherwise my i2c pinmuxing fails? Thanks. It looks to me like the _P_FN() bits would be mainly needed. Can you try to omit the _P_DATA() portion and check if it is still behaving as expected? Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> +#define _P_DATA(bank, pin, name, sfx) \ > >> + PINMUX_DATA(name##_DATA, name##_PMC_0, name##_PIPC_0, \ > >> + name##_PIBC_1, name##_PBDC_1) > >> + > >> +#define _P_FN(n, fn, pfcae, pfce, pfc) \ > >> + PINMUX_DATA(n##_MARK_FN##fn, n##_PMC_1, n##_PIPC_1, \ > >> + n##_PFCAE_##pfcae, n##_PFCE_##pfce, n##_PFC_##pfc) > > > > I need to apply this patch, otherwise my i2c pinmuxing fails? > > Thanks. It looks to me like the _P_FN() bits would be mainly needed. > Can you try to omit the _P_DATA() portion and check if it is still > behaving as expected? Nope, doesn't work.
On Wed, Dec 18, 2013 at 7:05 PM, Wolfram Sang <wsa@the-dreams.de> wrote: > >> >> +#define _P_DATA(bank, pin, name, sfx) \ >> >> + PINMUX_DATA(name##_DATA, name##_PMC_0, name##_PIPC_0, \ >> >> + name##_PIBC_1, name##_PBDC_1) >> >> + >> >> +#define _P_FN(n, fn, pfcae, pfce, pfc) \ >> >> + PINMUX_DATA(n##_MARK_FN##fn, n##_PMC_1, n##_PIPC_1, \ >> >> + n##_PFCAE_##pfcae, n##_PFCE_##pfce, n##_PFC_##pfc) >> > >> > I need to apply this patch, otherwise my i2c pinmuxing fails? >> >> Thanks. It looks to me like the _P_FN() bits would be mainly needed. >> Can you try to omit the _P_DATA() portion and check if it is still >> behaving as expected? > > Nope, doesn't work. Ok, thanks for checking! / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/pinctrl/sh-pfc/pfc-r7s72100.c b/drivers/pinctrl/sh-pfc/pfc-r7s72100.c index 4acdaae..2b716d1 100644 --- a/drivers/pinctrl/sh-pfc/pfc-r7s72100.c +++ b/drivers/pinctrl/sh-pfc/pfc-r7s72100.c @@ -68,11 +68,11 @@ enum { #define _P_GPIO(bank, _pin, _name, sfx) _GP_GPIO(16, bank, _pin, _name, sfx) #define _P_DATA(bank, pin, name, sfx) \ - PINMUX_DATA(name##_DATA, name##_PMC_0, name##_PIPC_0, \ + PINMUX_DATA(name##_DATA, name##_PMC_0, \ name##_PIBC_1, name##_PBDC_1) #define _P_FN(n, fn, pfcae, pfce, pfc) \ - PINMUX_DATA(n##_MARK_FN##fn, n##_PMC_1, n##_PIPC_1, \ + PINMUX_DATA(n##_MARK_FN##fn, n##_PMC_1, \ n##_PFCAE_##pfcae, n##_PFCE_##pfce, n##_PFC_##pfc) #define _P_MARK_FN1(bank, pin, name, sfx) _P_FN(name, 1, 0, 0, 0)