Re: [PATCH 2/2] McSPI Slave and DMA,FIFO support

[Tony Lindgren <tony@atomide.com>]

* Hemanth V <hemanthv@ti.com> [090522 06:37]:
> Tony, would you be able merge the two patches if I removed omap_cfg_reg  
> calls

Please provide just the mux.[ch] patch separately, that way we can
patch it where needed.

<snip snip>

>>>>> @@ -666,6 +685,13 @@
>>>>>
>>>>>  static void __init omap_3430sdp_init(void)
>>>>>  {
>>>>> +
>>>>> + /* SPI2 Pin MUX */
>>>>> + omap_cfg_reg(AA3_3430_McSPI2_CLK);
>>>>> + omap_cfg_reg(Y2_3430_McSPI2_SIMO);
>>>>> + omap_cfg_reg(Y3_3430_McSPI2_SOMI);
>>>>> + omap_cfg_reg(Y4_3430_McSPI2_CS0);
>>>>> +
>>>>
>>>> This will still change the padconf for this port unconditionally.
>>>>
>>>> How do we handle the case where the same platform (SDP in this case)
>>>> could have different configurations McSPI2 vs USBHOST2, etc? Is there
>>>> a clean way, or do we have no option but to use a CONFIG option?
>>>
>>> What about building both as modules and doing the muxing on module
>>> load with a warning if it's taking the pins away from antother
>>> feature.
>>>
>>> Longer term, we need a more dynamic way to request pins when there are
>>> conflicts like this.

Yeah.

>>> Kevin
>>
>> Might be the easiest option right now is to remove omap_cfg_reg calls 
>> and allow
>> users to add it when required.

We could just have a pointer for set_pins() in the platform data,
then the driver could just do if (pdev->set_pins()) pdev->set_pins();

Just like we have set_power() for some devices.

Regards,

Tony