Re: [PATCH v3 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.

[Balaji T K <balajitk@ti.com>]

On Tuesday 19 November 2013 09:19 PM, Tony Lindgren wrote:
> * Balaji T K <balajitk@ti.com> [131118 08:23]:
>> On Monday 18 November 2013 05:45 PM, Andreas Fenkart wrote:
>>> 2013/11/18 Michael Trimarchi <michael@amarulasolutions.com>:
>>>> On Mon, Nov 18, 2013 at 8:53 AM, Andreas Fenkart <afenkart@gmail.com> 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.

Agree that pdata usage needs to be fixed, but currently module
reprobe is working fine.

>
> 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?

Almost there, will post the patches soon.
Do you have a branch with updated board files, for me to base pbias patches on
else I can base the patches on rc1 too.

>
> 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
>