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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 7, 2009 at 10:47 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> [091006 15:18]:
>> "Menon, Nishanth" <nm@xxxxxx> writes:
>>
>> >> -----Original Message-----
>> >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
>> >> owner@xxxxxxxxxxxxxxx] 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
>
> 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.
>

FYI... I've updated the pinmux section of the OMAP wishlist wiki with
this rough plan from Tony.

   http://elinux.org/OMAP_wishlist

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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux