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 10/07/2009 10:47 AM, Tony Lindgren 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

Does anyone have a reference to Russell's suggestion?

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[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