Le 02.06.2010 13:46, Jarkko Nikula a écrit :
On Wed, 2 Jun 2010 14:21:30 +0300
Tony Lindgrent...@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
* Laurent Epinat laurent.epi...@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
* Tony Lindgren t...@atomide.com [100603 17:03]:
* Laurent Epinat laurent.epi...@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
* Laurent Epinat laurent.epi...@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,
On Wed, 2 Jun 2010 14:21:30 +0300
Tony Lindgren t...@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,
Op 2 jun 2010, om 13:46 heeft Jarkko Nikula het volgende geschreven:
On Wed, 2 Jun 2010 14:21:30 +0300
Tony Lindgren t...@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
On Wed, 2 Jun 2010 14:56:30 +0200
Koen Kooi k...@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
* Jarkko Nikula jhnik...@gmail.com [100602 16:06]:
On Wed, 2 Jun 2010 14:56:30 +0200
Koen Kooi k...@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
Op 2 jun 2010, om 15:57 heeft Tony Lindgren het volgende geschreven:
* Jarkko Nikula jhnik...@gmail.com [100602 16:06]:
On Wed, 2 Jun 2010 14:56:30 +0200
Koen Kooi k...@dominion.thruhere.net wrote:
How about add-on cards for e.g. BeagleBoard? It would be nice feature
if a kernel module
On Wed, 2 Jun 2010 16:57:10 +0300
Tony Lindgren t...@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,
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 Baradapeter.bar...@gmail.com [100311 14:29]:
* Jarkko Nikula jhnik...@gmail.com [100602 17:06]:
On Wed, 2 Jun 2010 16:57:10 +0300
Tony Lindgren t...@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
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
* Felipe Balbi felipe.ba...@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
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.
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
* Peter Barada peter.bar...@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
On Thu, Mar 11, 2010 at 5:48 PM, Tony Lindgren t...@atomide.com wrote:
* Peter Barada peter.bar...@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
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@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
19 matches
Mail list logo
