<snip>
> >> Can anybody see cases where Klaus' grouping would not work?
> >>
> > Dunno if I missed some mail in this thread, but the obvious occured: Have
> > we considered having more readable macros? I mean modes are only 1-7
> > (3bits- and give one more for safe), then add the others
> > #define MODE(x) ((x)&0xF)
> > #define PULL_EN (0x1<<5)
> > #define PULL_DIS (0x0<<5)
> > #define PULL_UP (0x1<<6)
> > #define PULL_DOWN (0x0<<6)
> > #define OUTPUT (0x1<<7)
> > #define INPUT (0x0<<7)
> > etc.. 1 bit per field. use 16 bit to store the vals (just like the regs)
> > and Thus,
> >
> > MUX_CFG_34XX("Y9_3430_USB1HS_PHY_STP", 0x5d8, 3, 1, 1, 0,
> > 0, 0, 0, 1, 1, 0)
> > becomes:
> > MUX_CFG_34XX("Y9_3430_USB1HS_PHY_STP", 0x5d8, 3,
> OUTPUT, OFF_INPUT_PULL_H)
> > becomes:
> > MUX_CFG_34XX("Y9_3430_USB1HS_PHY_STP", 0x5d8,
> MODE(3)|OUTPUT|PULL_DIS|WAKEUP_EN)
> >
> > All platforms can live with that rt? the pin_config
> structure gets simpler(and less of a nightmare) and portable :D
>
> Well originally the format was intended to be easy to compare against
> the 1510 TRM tables. If we can group the sensible options, things will
> simpler.
Working on the grouping Klaus mentioned. Will try to simplify this structure.
> > And one more thing (maybe I am wrong): I think i still see
> > that we are driving mux common for all platforms on the same
> > silicon. as we get more boards using and "misusing" the mux
> > concept, I think at some point we'd need to refactor mux
> > driver to allow omap_mux_register be called platform
> > specific. shrug.. just an old opinion..
>
> Passing the configuration option to omap_cfg_reg() would help
> with board specific configurations or what do you think? Then the
> muxing just becomes selecting the pinout from the mux table, and
> configuring it as desired, something like:
>
> omap_cfg_reg(AB11_3430_USB2HS_PHY_NXT, MUX_INPUT | OFF_NONE);
>
> and to avoid messing with omap1 mux tables, we can let them be
> as they are for now, and just pass them
>
> omap_cfg_reg(XY_15XX_SOMPIN, MUX_DEFAULT);
Yup. Good idea.
> BTW, I've refreshed the mux clean-up and omap_ctrl_reg patches,
> and pushed them. So that only leaves Anand's 3430 mux patch unapplied.
> I've refreshed that one too for reference, see below.
>
Small problem in this patch.
@@ -278,6 +395,12 @@
arch_mux_cfg.cfg_reg = omap24xx_cfg_reg;
}
+ if (cpu_is_omap34xx()) {
+ arch_mux_cfg.pins = omap34xx_pins;
+ arch_mux_cfg.size = OMAP24XX_PINS_SZ;
+ arch_mux_cfg.cfg_reg = omap34xx_cfg_reg;
+ }
+
return omap_mux_register(&arch_mux_cfg);
}
Should have been
+ if (cpu_is_omap34xx()) {
+ arch_mux_cfg.pins = omap34xx_pins;
+ arch_mux_cfg.size = OMAP34XX_PINS_SZ;
+ arch_mux_cfg.cfg_reg = omap34xx_cfg_reg;
+ }
+
I've refreshed the patch if someone wants it.
Regards,
Anand
Attachment:
mux-3430-take4.patch
Description: mux-3430-take4.patch
