[PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx

[PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx

[Cory Maccarrone]

There are three mux pins needed for omap7xx that differ
from the other omap configurations.  This change adds the
declarations into mux.c and mux.h.

Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
---
 arch/arm/mach-omap1/mux.c             |    5 +++++
 arch/arm/plat-omap/include/mach/mux.h |    5 +++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index d59899d..feb6d8c 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -51,6 +51,11 @@ MUX_CFG_7XX("E3_7XX_KBC4",        13,   25,    0,
24,   1, 0)
 MUX_CFG_7XX("AA17_7XX_USB_DM",     2,   21,    0,   20,   0, 0)
 MUX_CFG_7XX("W16_7XX_USB_PU_EN",   2,   25,    0,   24,   0, 0)
 MUX_CFG_7XX("W17_7XX_USB_VBUSI",   2,   29,    0,   28,   0, 0)
+
+/* MMC Pins */
+MUX_CFG_7XX("MMC_7XX_CMD",         2,    9,    0,    8,   1, 0)
+MUX_CFG_7XX("MMC_7XX_CLK",         2,   13,    0,   12,   1, 0)
+MUX_CFG_7XX("MMC_7XX_DAT0",        2,   17,    0,   16,   1, 0)
 };
 #define OMAP7XX_PINS_SZ		ARRAY_SIZE(omap7xx_pins)
 #else
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index f3c1d8a..56e357e 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -219,6 +219,11 @@ enum omap7xx_index {
 	AA17_7XX_USB_DM,
 	W16_7XX_USB_PU_EN,
 	W17_7XX_USB_VBUSI,
+
+	/* MMC */
+	MMC_7XX_CMD,
+	MMC_7XX_CLK,
+	MMC_7XX_DAT0,
 };

 enum omap1xxx_index {
-- 
1.5.6.3

Re: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx

[Nishanth Menon]

Cory Maccarrone had written, on 10/06/2009 08:53 AM, the following:
> There are three mux pins needed for omap7xx that differ
> from the other omap configurations.  This change adds the
> declarations into mux.c and mux.h.
> 
> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
> ---
>  arch/arm/mach-omap1/mux.c             |    5 +++++
>  arch/arm/plat-omap/include/mach/mux.h |    5 +++++
>  2 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
> index d59899d..feb6d8c 100644
> --- a/arch/arm/mach-omap1/mux.c
> +++ b/arch/arm/mach-omap1/mux.c
> @@ -51,6 +51,11 @@ MUX_CFG_7XX("E3_7XX_KBC4",        13,   25,    0,
> 24,   1, 0)
>  MUX_CFG_7XX("AA17_7XX_USB_DM",     2,   21,    0,   20,   0, 0)
>  MUX_CFG_7XX("W16_7XX_USB_PU_EN",   2,   25,    0,   24,   0, 0)
>  MUX_CFG_7XX("W17_7XX_USB_VBUSI",   2,   29,    0,   28,   0, 0)
> +
> +/* MMC Pins */
> +MUX_CFG_7XX("MMC_7XX_CMD",         2,    9,    0,    8,   1, 0)
> +MUX_CFG_7XX("MMC_7XX_CLK",         2,   13,    0,   12,   1, 0)
> +MUX_CFG_7XX("MMC_7XX_DAT0",        2,   17,    0,   16,   1, 0)
>  };
>  #define OMAP7XX_PINS_SZ		ARRAY_SIZE(omap7xx_pins)
>  #else
> diff --git a/arch/arm/plat-omap/include/mach/mux.h
> b/arch/arm/plat-omap/include/mach/mux.h
> index f3c1d8a..56e357e 100644
> --- a/arch/arm/plat-omap/include/mach/mux.h
> +++ b/arch/arm/plat-omap/include/mach/mux.h
> @@ -219,6 +219,11 @@ enum omap7xx_index {
>  	AA17_7XX_USB_DM,
>  	W16_7XX_USB_PU_EN,
>  	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?

-- 
Regards,
Nishanth Menon

Re: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx

[Cory Maccarrone]

On Tue, Oct 6, 2009 at 10:30 AM, Nishanth Menon <nm@ti.com> wrote:
> Cory Maccarrone had written, on 10/06/2009 08:53 AM, the following:
>>
>> There are three mux pins needed for omap7xx that differ
>> from the other omap configurations.  This change adds the
>> declarations into mux.c and mux.h.
>>
>> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
>> ---
>>  arch/arm/mach-omap1/mux.c             |    5 +++++
>>  arch/arm/plat-omap/include/mach/mux.h |    5 +++++
>>  2 files changed, 10 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
>> index d59899d..feb6d8c 100644
>> --- a/arch/arm/mach-omap1/mux.c
>> +++ b/arch/arm/mach-omap1/mux.c
>> @@ -51,6 +51,11 @@ MUX_CFG_7XX("E3_7XX_KBC4",        13,   25,    0,
>> 24,   1, 0)
>>  MUX_CFG_7XX("AA17_7XX_USB_DM",     2,   21,    0,   20,   0, 0)
>>  MUX_CFG_7XX("W16_7XX_USB_PU_EN",   2,   25,    0,   24,   0, 0)
>>  MUX_CFG_7XX("W17_7XX_USB_VBUSI",   2,   29,    0,   28,   0, 0)
>> +
>> +/* MMC Pins */
>> +MUX_CFG_7XX("MMC_7XX_CMD",         2,    9,    0,    8,   1, 0)
>> +MUX_CFG_7XX("MMC_7XX_CLK",         2,   13,    0,   12,   1, 0)
>> +MUX_CFG_7XX("MMC_7XX_DAT0",        2,   17,    0,   16,   1, 0)
>>  };
>>  #define OMAP7XX_PINS_SZ                ARRAY_SIZE(omap7xx_pins)
>>  #else
>> diff --git a/arch/arm/plat-omap/include/mach/mux.h
>> b/arch/arm/plat-omap/include/mach/mux.h
>> index f3c1d8a..56e357e 100644
>> --- a/arch/arm/plat-omap/include/mach/mux.h
>> +++ b/arch/arm/plat-omap/include/mach/mux.h
>> @@ -219,6 +219,11 @@ enum omap7xx_index {
>>        AA17_7XX_USB_DM,
>>        W16_7XX_USB_PU_EN,
>>        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?
>
> --
> Regards,
> Nishanth Menon
>

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.

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

Re: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx

[Kevin Hilman]

Cory Maccarrone <darkstar6262@gmail.com> writes:

> On Tue, Oct 6, 2009 at 10:30 AM, Nishanth Menon <nm@ti.com> wrote:
>> Cory Maccarrone had written, on 10/06/2009 08:53 AM, the following:
>>>
>>> There are three mux pins needed for omap7xx that differ
>>> from the other omap configurations.  This change adds the
>>> declarations into mux.c and mux.h.
>>>
>>> Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
>>> ---
>>>  arch/arm/mach-omap1/mux.c             |    5 +++++
>>>  arch/arm/plat-omap/include/mach/mux.h |    5 +++++
>>>  2 files changed, 10 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
>>> index d59899d..feb6d8c 100644
>>> --- a/arch/arm/mach-omap1/mux.c
>>> +++ b/arch/arm/mach-omap1/mux.c
>>> @@ -51,6 +51,11 @@ MUX_CFG_7XX("E3_7XX_KBC4",        13,   25,    0,
>>> 24,   1, 0)
>>>  MUX_CFG_7XX("AA17_7XX_USB_DM",     2,   21,    0,   20,   0, 0)
>>>  MUX_CFG_7XX("W16_7XX_USB_PU_EN",   2,   25,    0,   24,   0, 0)
>>>  MUX_CFG_7XX("W17_7XX_USB_VBUSI",   2,   29,    0,   28,   0, 0)
>>> +
>>> +/* MMC Pins */
>>> +MUX_CFG_7XX("MMC_7XX_CMD",         2,    9,    0,    8,   1, 0)
>>> +MUX_CFG_7XX("MMC_7XX_CLK",         2,   13,    0,   12,   1, 0)
>>> +MUX_CFG_7XX("MMC_7XX_DAT0",        2,   17,    0,   16,   1, 0)
>>>  };
>>>  #define OMAP7XX_PINS_SZ                ARRAY_SIZE(omap7xx_pins)
>>>  #else
>>> diff --git a/arch/arm/plat-omap/include/mach/mux.h
>>> b/arch/arm/plat-omap/include/mach/mux.h
>>> index f3c1d8a..56e357e 100644
>>> --- a/arch/arm/plat-omap/include/mach/mux.h
>>> +++ b/arch/arm/plat-omap/include/mach/mux.h
>>> @@ -219,6 +219,11 @@ enum omap7xx_index {
>>>        AA17_7XX_USB_DM,
>>>        W16_7XX_USB_PU_EN,
>>>        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?
>>
>> --
>> Regards,
>> Nishanth Menon
>>
>
> 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.

Kevin

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

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

[Menon, Nishanth]

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

Regards,
Nishanth Menon
--
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

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

[Kevin Hilman]

"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.

Kevin

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

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

[Tony Lindgren]

* 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

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

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

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * 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
>
> 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 majordomo@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)

[Cory Maccarrone]

On Wed, Oct 7, 2009 at 11:33 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Tony Lindgren <tony@atomide.com> writes:
>
>> * 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
>>
>> 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 majordomo@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]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

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?

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
>


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3316 bytes --]

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

[Tony Lindgren]

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

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

[Mike Rapoport]

Tony Lindgren wrote:
> * Kevin Hilman <khilman@deeprootsystems.com> [091006 15:18]:
>> "Menon, Nishanth" <nm@ti.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Sincerely yours,
Mike.

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

[Kevin Hilman]

On Wed, Oct 7, 2009 at 10:47 AM, Tony Lindgren <tony@atomide.com> 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
>
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html