* Hemanth V <hemanthv@xxxxxx> [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
--
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
