Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)

[Tony Lindgren <tony@atomide.com>]

* Philip Balister <philip@balister.org> [091007 19:32]:
> On 10/07/2009 10:47 AM, Tony Lindgren wrote:
>> * Kevin Hilman<khilman@deeprootsystems.com>  [091006 15:18]:
>>> "Menon, Nishanth"<nm@ti.com>  writes:
>>>
>>>>> -----Original Message-----
>>>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>>>>> owner@vger.kernel.org] On Behalf Of Kevin Hilman
>>>>>
>>>>>>>>         W17_7XX_USB_VBUSI,
>>>>>>>> +
>>>>>>>> +       /* MMC */
>>>>>>>> +       MMC_7XX_CMD,
>>>>>>>> +       MMC_7XX_CLK,
>>>>>>>> +       MMC_7XX_DAT0,
>>>>>>>
>>>>>>> probably a dumb question ->  but should'nt these go off to bootloader
>>>>>>> perhaps?
>>>>>>>
>>>>>>
>>>>>> Perhaps, although we use either EOL (for HTC Wizard) or Haret to boot,
>>>>>> and they don't set up the right mux configuration for our board.
>>>>>>
>>>>>> This way though, we don't have to worry about the boot loader -- we
>>>>>> can set it up right regardless of who boots us.
>>>>>
>>>>> I agree with Cory.
>>>>>
>>>>> I prefer that mux settings go into the kernel, even if they are setup
>>>>> in the bootloader already.  It's better to have redundancy than wonder
>>>>> what to do if changing boot loaders.
>>>>>
>>>> Probably opening up a can of worms.. Are the rules different for OMAP3?
>>>> Should'nt we have all mux done at kernel so that kernel is loader
>>>> independent?
>>>
>>> Yes, we should.  My preference is to always have muxing in the kernel.
>>
>> Agreed. We still should support bootloader only muxing too.
>>
>> BTW, I've been thinking about the following sets of patches for the next
>> merge window:
>>
>> 1. Do the include directories for mach-omap1 and mach-omap2 as suggested
>>     by Russell earlier
>
> Does anyone have a reference to Russell's suggestion?

Here's a link to the thread discussing the earlier header changes:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15087.html

Regards,

Tony


> Philip
>
>
>>
>> 2. Move all mux code to only live under arch/arm/*omap*/ and make sure
>>     drivers don't call omap_cfg_reg() any longer
>>
>> 3. Remove the enumeration for the mux and require all the boards to
>>     register the pins they'll use
>>
>> After these it should be trivial to improve the mux code further. The
>> steps 2&  3 above will be most likely breaking things for some boards,
>> so help will be needed with testing.
>>
>> Regards,
>>
>> Tony
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>