* Gadiyar, Anand <gadiyar@xxxxxx> [080128 05:13]:
>
> <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.
Great!
> > > 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.
OK
> > 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.
Oops, sorry about that. I guess this bug still served it's purpose to
test the error handling ;)
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
