Trying to understand how to use new OMAP mux code

Trying to understand how to use new OMAP mux code

[Peter Barada]

1) Suppose I want to talk to a bluetooth chip through UART2.  UART2_TX
 gives me a choice of pins to hook up to, either to pin AA26 in Mode0,
or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
OMAP_PIN_OUTPUT), which pin will that map to?

2) How can I tell the muxing code that I want a specific pin for my
UART2_TX signal (that's not a GPIO since those can be directly
specified by GPIO number)?


Thanks in advance!

Re: Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Peter Barada <peter.barada@gmail.com> [100311 14:29]:
> 1) Suppose I want to talk to a bluetooth chip through UART2.  UART2_TX
>  gives me a choice of pins to hook up to, either to pin AA26 in Mode0,
> or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
> OMAP_PIN_OUTPUT), which pin will that map to?

You need to check the omap package type you're using to find
out the correct ball name. If you get lucky, that's already in
mux34xx.c and you don't need search through the TRMs :)
 
> 2) How can I tell the muxing code that I want a specific pin for my
> UART2_TX signal (that's not a GPIO since those can be directly
> specified by GPIO number)?

Then you want to use the full signal name:

omap_mux_init_signal("mode0_name.desired_mode", OMAP_PIN_FLAGS) 

But as the balls can be separate for each package type, you
need to figure that out first.

Regards,

Tony

Re: Trying to understand how to use new OMAP mux code

[Peter Barada]

On Thu, Mar 11, 2010 at 5:48 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Peter Barada <peter.barada@gmail.com> [100311 14:29]:
>> 1) Suppose I want to talk to a bluetooth chip through UART2.  UART2_TX
>>  gives me a choice of pins to hook up to, either to pin AA26 in Mode0,
>> or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
>> OMAP_PIN_OUTPUT), which pin will that map to?
>
> You need to check the omap package type you're using to find
> out the correct ball name. If you get lucky, that's already in
> mux34xx.c and you don't need search through the TRMs :)

The ball name helps me to identify it, but if I understand correctly,
none of the mux code allows the use of a ball name - I have to use the
mode0 name of the ball I want to use (and as you say later qualified
by the signal I want hooked up to that pi), right?

>> 2) How can I tell the muxing code that I want a specific pin for my
>> UART2_TX signal (that's not a GPIO since those can be directly
>> specified by GPIO number)?
>
> Then you want to use the full signal name:
>
> omap_mux_init_signal("mode0_name.desired_mode", OMAP_PIN_FLAGS)
>
> But as the balls can be separate for each package type, you
> need to figure that out first.

If my board sets up the balls packaging right (for a 3530 CBB
package), then "omap_mux_init_signal("mcbsp3_clkx.uart2_tx",
OMAP_PIN_OUTPUT);", will setup pin AF5 as mode2, output - thereby
muxing GPIO pin 142 to the UART2_TX signal?

Next question is for the AM3517 (491 pin), I see the setup for
board-am3517evm int he 2.6.33-rc3 kernel refers to the CBB package
which the comments indicate is a 515 pin package - is this the correct
package to use for the AM3517?  Since I have to traverse from my
schematic via ball name to signal name, it helps to know I'm looking
at the right package list.

Also, it looks like the references in arch/arm/mach-omap2/mux24xx.c to
TI forum URLs (e.g.  http://community.ti.com/forums/t/10982.aspx)
takes you to http://e2e.ti.com/support/default.aspx - do you need a
"myTI" login to see that forum message?.


> Regards,
>
> Tony
>

So if I use: omap
--
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: Trying to understand how to use new OMAP mux code

[Premi, Sanjeev]

 
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Peter Barada
> Sent: Friday, March 12, 2010 10:19 AM
> To: Tony Lindgren
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Trying to understand how to use new OMAP mux code
> 
> On Thu, Mar 11, 2010 at 5:48 PM, Tony Lindgren 
> <tony@atomide.com> wrote:
> > * Peter Barada <peter.barada@gmail.com> [100311 14:29]:
> >> 1) Suppose I want to talk to a bluetooth chip through 
> UART2.  UART2_TX
> >>  gives me a choice of pins to hook up to, either to pin 
> AA26 in Mode0,
> >> or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
> >> OMAP_PIN_OUTPUT), which pin will that map to?
> >
> > You need to check the omap package type you're using to find
> > out the correct ball name. If you get lucky, that's already in
> > mux34xx.c and you don't need search through the TRMs :)
> 
> The ball name helps me to identify it, but if I understand correctly,
> none of the mux code allows the use of a ball name - I have to use the
> mode0 name of the ball I want to use (and as you say later qualified
> by the signal I want hooked up to that pi), right?
> 
> >> 2) How can I tell the muxing code that I want a specific pin for my
> >> UART2_TX signal (that's not a GPIO since those can be directly
> >> specified by GPIO number)?
> >
> > Then you want to use the full signal name:
> >
> > omap_mux_init_signal("mode0_name.desired_mode", OMAP_PIN_FLAGS)
> >
> > But as the balls can be separate for each package type, you
> > need to figure that out first.
> 
> If my board sets up the balls packaging right (for a 3530 CBB
> package), then "omap_mux_init_signal("mcbsp3_clkx.uart2_tx",
> OMAP_PIN_OUTPUT);", will setup pin AF5 as mode2, output - thereby
> muxing GPIO pin 142 to the UART2_TX signal?
> 
> Next question is for the AM3517 (491 pin), I see the setup for
> board-am3517evm int he 2.6.33-rc3 kernel refers to the CBB package
> which the comments indicate is a 515 pin package - is this the correct
> package to use for the AM3517?  Since I have to traverse from my
> schematic via ball name to signal name, it helps to know I'm looking
> at the right package list.
> 
> Also, it looks like the references in arch/arm/mach-omap2/mux24xx.c to
> TI forum URLs (e.g.  http://community.ti.com/forums/t/10982.aspx)
> takes you to http://e2e.ti.com/support/default.aspx - do you need a
> "myTI" login to see that forum message?.

No login is required. It is just that the forum backend has changed and
the original link would be leading to a HTTP404 redirecting you to the
main page. If we know the original title, search should help in locating
the original post.

Best regards,
Sanjeev

> 
> 
> > Regards,
> >
> > Tony
> >
> 
> So if I use: omap
> --
> 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
> --
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: Trying to understand how to use new OMAP mux code

[Laurent Epinat]

Hello all


How can I call  omap_mux_init_signal()
from external driver compiled as module ?

cause the function is not in the standard path include files
and is not exported

regards,

Laurent

Le 11.03.2010 23:48, Tony Lindgren a écrit :
> * Peter Barada<peter.barada@gmail.com>  [100311 14:29]:
>> 1) Suppose I want to talk to a bluetooth chip through UART2.  UART2_TX
>>   gives me a choice of pins to hook up to, either to pin AA26 in Mode0,
>> or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
>> OMAP_PIN_OUTPUT), which pin will that map to?
>
> You need to check the omap package type you're using to find
> out the correct ball name. If you get lucky, that's already in
> mux34xx.c and you don't need search through the TRMs :)
>
>> 2) How can I tell the muxing code that I want a specific pin for my
>> UART2_TX signal (that's not a GPIO since those can be directly
>> specified by GPIO number)?
>
> Then you want to use the full signal name:
>
> omap_mux_init_signal("mode0_name.desired_mode", OMAP_PIN_FLAGS)
>
> But as the balls can be separate for each package type, you
> need to figure that out first.
>
> 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
>
>


-- 

Salutations
Laurent Epinat -> mailto:laurent.epinat@cioinfoindus.fr

CIO Informatique
Le millenium
1, rue de Presse - BP 710
42950 Saint-Etienne Cedex 9

Tel    33 (0) 477 93 34 32
Tcopie 33 (0) 477 79 75 55
WWW : http://www.cioinfoindus.fr/
--
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: Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Laurent Epinat <laurent.epinat@cioinfoindus.fr> [100602 13:03]:
> Hello all
> 
> 
> How can I call  omap_mux_init_signal()
> from external driver compiled as module ?
> 
> cause the function is not in the standard path include files
> and is not exported

You can't that's the whole idea :)

Instead, please do the muxing in the board-*.c file for all the
pins, or for the device when you initialize the platform data.

The muxing of pins is board specific, and doing it in the board-*.c
files allows us to free the memory for the unused pin data. Note
that you can also mux using the kernel cmdline if you have something
non-standard connected to your board pins.

Regards,

Tony

Re: Trying to understand how to use new OMAP mux code

[Jarkko Nikula]

On Wed, 2 Jun 2010 14:21:30 +0300
Tony Lindgren <tony@atomide.com> wrote:

> > How can I call  omap_mux_init_signal()
> > from external driver compiled as module ?
> > 
> > cause the function is not in the standard path include files
> > and is not exported
> 
> You can't that's the whole idea :)
> 
> Instead, please do the muxing in the board-*.c file for all the
> pins, or for the device when you initialize the platform data.
> 
> The muxing of pins is board specific, and doing it in the board-*.c
> files allows us to free the memory for the unused pin data. Note
> that you can also mux using the kernel cmdline if you have something
> non-standard connected to your board pins.
> 
Side note.

How about add-on cards for e.g. BeagleBoard? It would be nice feature
if a kernel module for that particular add-on card can do the muxing
without needing to specify them on cmdline. I.e. if you are switching
between cards there is no need to figure out new cmdline for each of
them. For me even "rootwait" is sometimes too difficult to remember :-)


-- 
Jarkko

beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Koen Kooi]

Op 2 jun 2010, om 13:46 heeft Jarkko Nikula het volgende geschreven:

> On Wed, 2 Jun 2010 14:21:30 +0300
> Tony Lindgren <tony@atomide.com> wrote:
> 
>>> How can I call  omap_mux_init_signal()
>>> from external driver compiled as module ?
>>> 
>>> cause the function is not in the standard path include files
>>> and is not exported
>> 
>> You can't that's the whole idea :)
>> 
>> Instead, please do the muxing in the board-*.c file for all the
>> pins, or for the device when you initialize the platform data.
>> 
>> The muxing of pins is board specific, and doing it in the board-*.c
>> files allows us to free the memory for the unused pin data. Note
>> that you can also mux using the kernel cmdline if you have something
>> non-standard connected to your board pins.
>> 
> Side note.
> 
> How about add-on cards for e.g. BeagleBoard? It would be nice feature
> if a kernel module for that particular add-on card can do the muxing
> without needing to specify them on cmdline. I.e. if you are switching
> between cards there is no need to figure out new cmdline for each of
> them. For me even "rootwait" is sometimes too difficult to remember :-)

What we (as in beagleboard.org) are currently doing is this:

u-boot:

http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a
http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224

kernel:

http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90

It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM.

regards,

Koen

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Jarkko Nikula]

On Wed, 2 Jun 2010 14:56:30 +0200
Koen Kooi <koen@dominion.thruhere.net> wrote:

> > How about add-on cards for e.g. BeagleBoard? It would be nice feature
> > if a kernel module for that particular add-on card can do the muxing
> > without needing to specify them on cmdline. I.e. if you are switching
> > between cards there is no need to figure out new cmdline for each of
> > them. For me even "rootwait" is sometimes too difficult to remember :-)
> 
> What we (as in beagleboard.org) are currently doing is this:
> 
> u-boot:
> 
> http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a
> http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224
> 
> kernel:
> 
> http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90
> 
> It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM.
> 
Problem is that amount of expansion boards is practically unlimited so
patching bootloader and board file could come quite maintenance effort.

Of course there are some lets say generic boards but bunch of in-house,
DIY, etc. boards and there is no point to patch common bootloader and
kernel board files because of them.


-- 
Jarkko

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Jarkko Nikula <jhnikula@gmail.com> [100602 16:06]:
> On Wed, 2 Jun 2010 14:56:30 +0200
> Koen Kooi <koen@dominion.thruhere.net> wrote:
> 
> > > How about add-on cards for e.g. BeagleBoard? It would be nice feature
> > > if a kernel module for that particular add-on card can do the muxing
> > > without needing to specify them on cmdline. I.e. if you are switching
> > > between cards there is no need to figure out new cmdline for each of
> > > them. For me even "rootwait" is sometimes too difficult to remember :-)
> > 
> > What we (as in beagleboard.org) are currently doing is this:
> > 
> > u-boot:
> > 
> > http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a
> > http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224
> > 
> > kernel:
> > 
> > http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90
> > 
> > It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM.
> > 
> Problem is that amount of expansion boards is practically unlimited so
> patching bootloader and board file could come quite maintenance effort.
> 
> Of course there are some lets say generic boards but bunch of in-house,
> DIY, etc. boards and there is no point to patch common bootloader and
> kernel board files because of them.

Just saveenv the kernel cmdline options in u-boot?

Tony

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Koen Kooi]

Op 2 jun 2010, om 15:57 heeft Tony Lindgren het volgende geschreven:

> * Jarkko Nikula <jhnikula@gmail.com> [100602 16:06]:
>> On Wed, 2 Jun 2010 14:56:30 +0200
>> Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>>>> How about add-on cards for e.g. BeagleBoard? It would be nice feature
>>>> if a kernel module for that particular add-on card can do the muxing
>>>> without needing to specify them on cmdline. I.e. if you are switching
>>>> between cards there is no need to figure out new cmdline for each of
>>>> them. For me even "rootwait" is sometimes too difficult to remember :-)
>>> 
>>> What we (as in beagleboard.org) are currently doing is this:
>>> 
>>> u-boot:
>>> 
>>> http://gitorious.org/beagleboard-validation/u-boot/commit/70ed67cacbb1b7158e059b9b5d10308cce2d917a
>>> http://gitorious.org/beagleboard-validation/u-boot/commit/74f700341c656e1636221a53347caccbfc07c224
>>> 
>>> kernel:
>>> 
>>> http://gitorious.org/beagleboard-validation/linux/commit/32fb278553a4cd6126c1791d70aa33df12f73d90
>>> 
>>> It's very ugly and needs a rethink before it can get posted to here, but it works great! The plan is to do this as part of the patchset to add support for the 37xx based beagleboardXM.
>>> 
>> Problem is that amount of expansion boards is practically unlimited so
>> patching bootloader and board file could come quite maintenance effort.
>> 
>> Of course there are some lets say generic boards but bunch of in-house,
>> DIY, etc. boards and there is no point to patch common bootloader and
>> kernel board files because of them.
> 
> Just saveenv the kernel cmdline options in u-boot?

People typing 'saveenv' without checking account for like half of the RMAs for beagleboards.... 
Also, the beagleboard xM has no NAND, so I'm using a boot.scr uboot script on SD to set params. But the problem we are trying to solve is this:

"Support all beagle expansion boards mentioned in http://elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDs out of the box"

That means that a user can plug in an expansion board, apply power and it will "just work". That's the case now for the zippy, zippy2, trainer and beaglefpga boards with the current u-boot and kernel setup. I agree it doesn't scale, but I haven't seen any actual effort by the beagleboard/omap3 community to make the muxing and initializing the board (i2c, spi, gpio, rtc) work completely in the kernel :(

regards,

Koen

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Jarkko Nikula]

On Wed, 2 Jun 2010 16:57:10 +0300
Tony Lindgren <tony@atomide.com> wrote:

> > Problem is that amount of expansion boards is practically unlimited so
> > patching bootloader and board file could come quite maintenance effort.
> > 
> > Of course there are some lets say generic boards but bunch of in-house,
> > DIY, etc. boards and there is no point to patch common bootloader and
> > kernel board files because of them.
> 
> Just saveenv the kernel cmdline options in u-boot?
> 
I meant that if kernel module could do muxing then there is no need the
user to change muxings for different add-on boards.

Works fine if you have one board but how about when amount of expansion
boards grow?


-- 
Jarkko

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Koen Kooi <koen@dominion.thruhere.net> [100602 17:01]:
> 
> "Support all beagle expansion boards mentioned in http://elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDs out of the box"
> 
> That means that a user can plug in an expansion board, apply power and it will "just work". That's the case now for the zippy, zippy2, trainer and beaglefpga boards with the current u-boot and kernel setup. I agree it doesn't scale, but I haven't seen any actual effort by the beagleboard/omap3 community to make the muxing and initializing the board (i2c, spi, gpio, rtc) work completely in the kernel :(

Well how about patch u-boot to allow saveenv the revision
and then pass it to kernel as ATAG_REVISION? That's available
as system_rev in the kernel. Then you can initialize the platform
devices in the board-*.c files.

The other option would be to somehow to detect the hardware
during the boot, but that may not work for all the devices.

Regards,

Tony

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Jarkko Nikula <jhnikula@gmail.com> [100602 17:06]:
> On Wed, 2 Jun 2010 16:57:10 +0300
> Tony Lindgren <tony@atomide.com> wrote:
> 
> > > Problem is that amount of expansion boards is practically unlimited so
> > > patching bootloader and board file could come quite maintenance effort.
> > > 
> > > Of course there are some lets say generic boards but bunch of in-house,
> > > DIY, etc. boards and there is no point to patch common bootloader and
> > > kernel board files because of them.
> > 
> > Just saveenv the kernel cmdline options in u-boot?
> > 
> I meant that if kernel module could do muxing then there is no need the
> user to change muxings for different add-on boards.
> 
> Works fine if you have one board but how about when amount of expansion
> boards grow?

Yeah having the modules do the platform device init and registration will
lead into nasty conflicts. The platform device registration really needs
to happen in the board-*.c files, not in the drivers.

Tony

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Felipe Balbi]

On Wed, Jun 02, 2010 at 04:45:48PM +0200, ext Tony Lindgren wrote:
>Yeah having the modules do the platform device init and registration will
>lead into nasty conflicts. The platform device registration really needs
>to happen in the board-*.c files, not in the drivers.

yeah, unless you had a way to register a particular platform_device 
conditionaly based on the attached daughter card, but then again, if you 
can detect the daughter card, you might as well use that information to 
do the muxing correctly on the board-*.c file.

I have to agree modules are not supposed to change platform stuff. On 
the other hand, that could be used by EHCI/OHCI to implement port 
handoff on runtime:

  mux all usb ports to ehci, if enumeration fails, remux ports to ohci 
  and try again.

-- 
balbi

DefectiveByDesign.org

Re: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Felipe Balbi <felipe.balbi@nokia.com> [100602 17:50]:
> 
> I have to agree modules are not supposed to change platform stuff.
> On the other hand, that could be used by EHCI/OHCI to implement port
> handoff on runtime:
> 
>  mux all usb ports to ehci, if enumeration fails, remux ports to
> ohci  and try again.

To do that all we have to do is to do is have the pin remux function
in mach-omap2/*hci.c, then pass a pointer to that function to the
*hci glue driver.

Regards,

Tony

RE: beagleboard expansion boards, was Trying to understand how to use new OMAP mux code

[Gadiyar, Anand]

Felipe Balbi wrote:
> On Wed, Jun 02, 2010 at 04:45:48PM +0200, ext Tony Lindgren wrote:
> >Yeah having the modules do the platform device init and registration will
> >lead into nasty conflicts. The platform device registration really needs
> >to happen in the board-*.c files, not in the drivers.
> 
> yeah, unless you had a way to register a particular platform_device 
> conditionaly based on the attached daughter card, but then again, if you 
> can detect the daughter card, you might as well use that information to 
> do the muxing correctly on the board-*.c file.
> 
> I have to agree modules are not supposed to change platform stuff. On 
> the other hand, that could be used by EHCI/OHCI to implement port 
> handoff on runtime:
> 
>   mux all usb ports to ehci, if enumeration fails, remux ports to ohci 
>   and try again.
> 

FWIW, this specific configuration is not supported on OMAP3s today.
You cannot dynamically hand off from EHCI to OHCI - the issue being that
we don't have a single PHY that can talk both interface languages on the
exact same pads as the OMAP.

One other case I can think of where you might want to change mux modes
dynamically is as a workaround for an errata. For instance, you might
want to mux a particular pad to safe-mode when entering off-mode and
mux it back to a functional mode after exiting off-mode.

- Anand

Re: Trying to understand how to use new OMAP mux code

[Laurent Epinat]

Le 02.06.2010 13:46, Jarkko Nikula a écrit :
> On Wed, 2 Jun 2010 14:21:30 +0300
> Tony Lindgren<tony@atomide.com>  wrote:
>
>>> How can I call  omap_mux_init_signal()
>>> from external driver compiled as module ?
>>>
>>> cause the function is not in the standard path include files
>>> and is not exported
>>
>> You can't that's the whole idea :)
>>
>> Instead, please do the muxing in the board-*.c file for all the
>> pins, or for the device when you initialize the platform data.
>>
>> The muxing of pins is board specific, and doing it in the board-*.c
>> files allows us to free the memory for the unused pin data. Note
>> that you can also mux using the kernel cmdline if you have something
>> non-standard connected to your board pins.
>>
> Side note.
>
> How about add-on cards for e.g. BeagleBoard? It would be nice feature
> if a kernel module for that particular add-on card can do the muxing
> without needing to specify them on cmdline. I.e. if you are switching
> between cards there is no need to figure out new cmdline for each of
> them. For me even "rootwait" is sometimes too difficult to remember :-)
>
>

The thing is

We make Computer-On-Modules

http://www.cioinfoindus.fr/fr/produits/computer-on-module-maia.html


and we make the support board for them according to the extra functionalites required
eg: for some boards we need i2c2 and for others we need gpio (168,183)


I would like one basic configuration for the modules with (twl,net,flash,.. all on the COM's)
and for the rest, external driver for extra functionalities on the support board.

This is why I need to change the mux pins dynamically by the driver module.




-- 

Salutations
Laurent Epinat -> mailto:laurent.epinat@cioinfoindus.fr

CIO Informatique
Le millenium
1, rue de Presse - BP 710
42950 Saint-Etienne Cedex 9

Tel    33 (0) 477 93 34 32
Tcopie 33 (0) 477 79 75 55
WWW : http://www.cioinfoindus.fr/
--
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: Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Laurent Epinat <laurent.epinat@cioinfoindus.fr> [100603 16:36]:
> 
> I would like one basic configuration for the modules with (twl,net,flash,.. all on the COM's)
> and for the rest, external driver for extra functionalities on the support board.
> 
> This is why I need to change the mux pins dynamically by the driver module.

If you really want to do it after the system has booted instead of passing
the desired muxing in the kernel cmdline, you could just do some
shell scripts to echo 0xXXXX > /sys/kernel/debug/omap_mux/whateverpin..

Tony

Re: Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [100603 17:03]:
> * Laurent Epinat <laurent.epinat@cioinfoindus.fr> [100603 16:36]:
> > 
> > I would like one basic configuration for the modules with (twl,net,flash,.. all on the COM's)
> > and for the rest, external driver for extra functionalities on the support board.
> > 
> > This is why I need to change the mux pins dynamically by the driver module.
> 
> If you really want to do it after the system has booted instead of passing
> the desired muxing in the kernel cmdline, you could just do some
> shell scripts to echo 0xXXXX > /sys/kernel/debug/omap_mux/whateverpin..

Or you could have the remux function in your board-*.c file, then pass
the pointer to it to your custom remux module in the platform data.
Then your custom remux module could change the mode via sysfs or
something.

Regards,

Tony