> > > > > Since currently nobody uses TWL603x platform data and all new
> > > >
> > > > Hmm... when you say nobody, how did you come to this conclusion?
> > > >
> > > > Without digging into it and probably not that relevant, it
> > > > appears there is some references to it in platform data still:
> > > >
> > > > $ git grep twl603 -- arch/ | grep -v dts
> > > > arch/arm/mach-omap2/common.h:extern int omap4_twl6030_hsmmc_init(struct
> > > > omap2_hsmmc_info *controllers);
> > > > arch/arm/mach-omap2/omap4-common.c:static int
> > > > omap4_twl6030_hsmmc_late_init(struct device *dev)
> > > > arch/arm/mach-omap2/omap4-common.c: irq =
> > > > twl6030_mmc_card_detect_config();
> > > > arch/arm/mach-omap2/omap4-common.c:
> > > > pdata->slots[0].card_detect = twl6030_mmc_card_detect;
> > > > arch/arm/mach-omap2/omap4-common.c:static __init void
> > > > omap4_twl6030_hsmmc_set_late_init(struct device *dev)
> > > > arch/arm/mach-omap2/omap4-common.c: pdata->init =
> > > > omap4_twl6030_hsmmc_late_init;
> > > > arch/arm/mach-omap2/omap4-common.c:int __init
> > > > omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
> > > > arch/arm/mach-omap2/omap4-common.c:
> > > > omap4_twl6030_hsmmc_set_late_init(&c->pdev->dev);
> > > > arch/arm/mach-omap2/omap4-common.c:int __init
> > > > omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
> > > > arch/arm/mach-omap2/omap_twl.c:static unsigned long
> > > > twl6030_vsel_to_uv(const u8 vsel)
> > > > arch/arm/mach-omap2/omap_twl.c:static u8 twl6030_uv_to_vsel(unsigned long
> > > > uv)
> > > > arch/arm/mach-omap2/omap_twl.c: if (uv > twl6030_vsel_to_uv(0x39)) {
> > > > arch/arm/mach-omap2/omap_twl.c: __func__, uv,
> > > > twl6030_vsel_to_uv(0x39));
> > > > arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
> > > > twl6030_vsel_to_uv,
> > > > arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
> > > > twl6030_uv_to_vsel,
> > > > arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
> > > > twl6030_vsel_to_uv,
> > > > arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
> > > > twl6030_uv_to_vsel,
> > > > arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
> > > > twl6030_vsel_to_uv,
> > > > arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
> > > > twl6030_uv_to_vsel,
> > > >
> > > Looks like some misunderstanding is here. This patch *only* removes
> > > platform data for TWL603x
> > > which were used to create TWL sub-devices like regulators, adc's,
> > > watchdogs, etc.
> > > Previously it was set up in twl_common.c by omap4_pmic_init(), which was
> > > called from board files
> > > with specific pmic config.
> > > Since now in Linux kernel 3.13 OMAP4 non-DT boot is not supported and all
> > > OMAP4 board files
> > > have been removed omap4_pmic_init() is never called and all TWL603x
> > > sub-devices are created
> > > from device tree data.
> >
> > I'm not overly familiar with this driver (it looks like a big
> > historical mess to me), or the current state of the OMAP4 platform, so
> > I would like a second opinion on this.
> >
> > Tony would you be kind enough to oblige?
>
> We've moved omap4 to boot based on device tree only, so that legacy
> platform data is no longer being used. It might be worth checking if
> we do have bindings in place for all of that, or if some of it may
> still be needed to be passed as auxdata while we wait for the bindings.
Ruslan, do you know the answer to these concerns?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
