Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
On Wed, Oct 7, 2009 at 10:47 AM, Tony Lindgren wrote: > * Kevin Hilman [091006 15:18]: >> "Menon, Nishanth" writes: >> >> >> -Original Message- >> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> >> ow...@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 > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
* Philip Balister [091007 19:32]: > On 10/07/2009 10:47 AM, Tony Lindgren wrote: >> * Kevin Hilman [091006 15:18]: >>> "Menon, Nishanth" writes: >>> > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@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 majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
Tony Lindgren wrote: > * Kevin Hilman [091006 15:18]: >> "Menon, Nishanth" writes: >> > > 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 IMHO, we should also change omap_cfg_reg to omap_cfg_mux or something alike. > 3. Remove the enumeration for the mux and require all the boards to >register the pins they'll use +1 > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
On 10/07/2009 10:47 AM, Tony Lindgren wrote: * Kevin Hilman [091006 15:18]: "Menon, Nishanth" writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@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? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html smime.p7s Description: S/MIME Cryptographic Signature
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
On Wed, Oct 7, 2009 at 11:33 AM, Kevin Hilman wrote: > Tony Lindgren writes: > >> * Kevin Hilman [091006 15:18]: >>> "Menon, Nishanth" writes: >>> >>> >> -Original Message- >>> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >>> >> ow...@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 >> >> 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. > > Sounds like a good start on a mux rework to me. :) > > Kevin > I agree, this sounds like a good approach. Should make a lot of drivers much cleaner and easier to maintain, and we can do away with the 7xx versus all of the rest of omap1 mux nonsense we have right now. Cory -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
Tony Lindgren writes: > * Kevin Hilman [091006 15:18]: >> "Menon, Nishanth" writes: >> >> >> -Original Message- >> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> >> ow...@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 > > 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. Sounds like a good start on a mux rework to me. :) Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
* Kevin Hilman [091006 15:18]: > "Menon, Nishanth" writes: > > >> -Original Message- > >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >> ow...@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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
"Menon, Nishanth" writes: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@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. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@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? Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
