* Balaji T K <balajitk@xxxxxx> [131118 08:23]:
> On Monday 18 November 2013 05:45 PM, Andreas Fenkart wrote:
> >2013/11/18 Michael Trimarchi <michael@xxxxxxxxxxxxxxxxxxxx>:
> >>On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart <afenkart@xxxxxxxxx> wrote:
> >>> static int omap_hsmmc_card_detect(struct device *dev, int slot)
> >>> {
> >>> struct omap_hsmmc_host *host = dev_get_drvdata(dev);
> >>>@@ -452,10 +474,25 @@ static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
> >>> } else
> >>> pdata->slots[0].gpio_wp = -EINVAL;
> >>>
> >>>+ if (gpio_is_valid(pdata->slots[0].gpio_cirq)) {
> >>>+ pdata->slots[0].sdio_irq =
> >>>+ gpio_to_irq(pdata->slots[0].gpio_cirq);
> >>
> >>What is this? re-assign the platform data?
> >
> >Seems like, I didn't pay attention to this.
> >Simply kept in line how the write protection/read only pins are managed.
> >I'd rather not change this part, or not changing it as part of adding
> >sdio IRQ support it.
> >
> >Maybe somebody else on the list can explain why the platform data
> >contains elements
> >that are modified during runtime.
> >
> >- set_power / get_ro function callbacks
> >- ocr_mask.
> >
> Hi,
>
> few params were passed via platform data in non-DT case and never cached
> in internal data structure, with non-dt support going away soon, I am
> planning to cleanup pdata usage in the driver when it gets to DT only support.
The issue of pdata tinkering needs to be fixed first as it will cause nasty
issues when the module is reprobed.
Note that it's still possible to pass platform data in the device tree case
as auxdata. And we probably need to do that for the pbias register handling
until we have a driver for that.
Talking of the pbias driver, any news on it?
To recap, we basically we need a minimal separate driver that exposes the
control module pbias register as a regulator to the hsmmc driver. I don't see
that we can remove the platform data from the driver before that's done.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
