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

[Kevin Hilman <khilman@deeprootsystems.com>]

"Hemanth V" <hemanthv@ti.com> writes:

>
>> "Gadiyar, Anand" <gadiyar@ti.com> writes:
>>
>>>> -----Original Message-----
>>>> From: linux-omap-owner@vger.kernel.org
>>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hemanth V
>>>> Sent: Wednesday, May 20, 2009 11:27 AM
>>>> To: linux-omap@vger.kernel.org
>>>> Subject: [PATCH 2/2] McSPI Slave and DMA,FIFO support
>>>>
>>>> This patch adds MUX changes for SPI2 and also adds an
>>>> option for test driver
>>>>
[...]
>>>>  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.
>>
>> Kevin
>
> Might be the easiest option right now is to remove omap_cfg_reg
> calls and allow users to add it when required.

Those calls are required for a functioning SPI driver, no?  If we
leave them out, isn't the first question going to be "why doesn't SPI2
work on my board."

That being said, I guess I'm ok with waiting a little for adding he
muxing. Not sure what others think

My "partial fix" suggestion for today was for the driver to mux them at
runtime when the module loads.  However, I don't really like that
solution either since that puts board/chip specific code into the
driver.

The real solution is to have the muxing done as part of a
device_enable call which will come as part of the forthcoming omapdev.
Then the muxing can be done as part of a generic device enable, along
clocks etc.

However, this still doesn't solve the problem of conflicting users.
If you're using McSPI2 and you enable USBHOST, then your McSPI2 will
just stop working.  At some point, we'll need some sort of
request/free mechanism for pins.

Kevin