XM Pin Muxing in Kernel

Hi All -

Can anyone answer some questions about the current state of Pin
Muxing?

I'm using an xM rev B board with a basic Angstrom console image -
kernel 2.6.32 - and rebuilding the kernel using:

bitbake virtual/kernel -c compile -f
bitbake virtual/kernel -c deploy

1. Does this even work? I've seen board posts about pin muxing being
broken in "recent kernels".

2. The xM uses package CBP, correct? Does this need to be changed in
the kernel config (CONFIG_OMAP_PACKAGE_CBB), in the call to
omap3_mux_init(), etc? (Note: when I try to change
CONFIG_OMAP_PACKAGE_CBB to _CBP in the .config file, something appears
to change it back.)

3. I would like to use some expansion header GPIOs and one or two of
the McBSPs from the DSP side. Do I need to verify that nothing on the
ARM side is using these pins? Is there an easy way to do this?

Thanks much,

Joe.

Another one:

4. Is there any reason why this can't be done outside of the kernel -
i.e. in a GPP or DSP app?

Joe.

What does the bitbake command working or not have to do with pinmuxing?

The first question is regarding whether pin muxing in the kernel
works, not the bitbake commands.

Pinmuxing in the kernel should work but your commands will only
compile the current kernel without any changes. You need to first
change the pin muxing in the source code before you compile it. (See
OPTION 2). Now regarding in recent versions where kernel pinmuxing
maybe broken, I don't know about this but at least things would work
on the Beagleboard C4 revision. Unless something is significantly
different between the two models, I wouldn't think there is anything
different between Beagleboard XM procedures.

Secondly, doing it in Openembedded is possible, however my PHD Teacher
Assistant from a robotics class always suggested that one use u-boot
to do it rather than the kernel image. This might be a better
alternative since it only takes half an hour to compile, but figuring
out what files in openembedded to change to do it is entirely
something you need to figure out. Try checking out gumstix forums
regarding what the procedure might be. Gumstix is another board that
uses the same TI OMAP (well actually the Beagleboard C4) but should
still be similar for XM procedures. They have good support and
documentation regarding this thing. My TA has had success getting
this to work, I have not since I haven't the need anymore. The
hardest part I found about pin muxing is that you need to create
patches to source code so that bitbake will apply it and then compile
it to the architecture and board you want. Since I was new to it I
just decided to do it in my Angstrom user-space.

OPTION 1:
Check out this link for user-space pin muxing it. It uses devmem2 to
configure registers and this example shows how to configure GPIO to
configure `PWM signals, by modifying the OMAP3530 registers. I would
use the same example but check out the Technical Reference Manual(TRM)
of your OMAP because register addresses maybe different.

http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=56&Itemid=63

OPTION 2:
If you want to use openembedded, check out how to apply patches to
source code here:
http://bec-systems.com/site/456/capture-oe-source-changes
http://www.xora.org.uk/2009/12/10/openembeddedangstrom-kernel-workflow/

Option 2 is the legit way to do things, option 1 worked for me cause
it was simpler and I didn't need to learn openembedded. For your
case, since you are trying to see it to work, try OPTION 1 then doing
OPTION 2.

Good luck.

Hope this information is helpful.

Hi All -

Can anyone answer some questions about the current state of Pin
Muxing?

I'm using an xM rev B board with a basic Angstrom console image -
kernel 2.6.32 - and rebuilding the kernel using:

bitbake virtual/kernel -c compile -f
bitbake virtual/kernel -c deploy

1. Does this even work? I've seen board posts about pin muxing being
broken in "recent kernels".

2.6.32 is hardly recent.

2. The xM uses package CBP, correct? Does this need to be changed in
the kernel config (CONFIG_OMAP_PACKAGE_CBB), in the call to
omap3_mux_init(), etc? (Note: when I try to change
CONFIG_OMAP_PACKAGE_CBB to _CBP in the .config file, something appears
to change it back.)

Do you have any idea if the package CBP is different from CBB? In
order to permanently change this for the kernel build system you have
to modify the MACH_OMAP3_BEAGLE setting in arch/arm/mach-omap2/Kconfig
and change it to select OMAP_PACKAGE_CBP

3. I would like to use some expansion header GPIOs and one or two of
the McBSPs from the DSP side. Do I need to verify that nothing on the
ARM side is using these pins? Is there an easy way to do this?

I am trying to get mcbsp1 to work on the expansion connector to talk
to an external codec. Some basic stuff is really hard to determine.
For example omap-mcbsp-dai.0 does that run on mcbsp1?

If you have any success please post your discoveries here.

Regards, Steve

You need to make sure you have the Muxing setup correctly in the
board-omap3beagle.c file.

Here I mux the pins on the expansion header to get McBSP3

/* CS42L73 <-> McBSP3 on the expansion header */
/*K26*/ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLDOWN),
/* McBSP3_FSX */
/*W21*/ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLDOWN),
/* McBSP3_CLKX */
/*U21*/ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLDOWN),
/* McBSP3_DR */
/*V21*/ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT),
/* McBSP3_DX */
        
You add this stuff in omap_board_mux board_mux[] __initdata = {
You get the values for the OMAP3_MUX from the beagleboard usersguide.

**Note** I had to mux the McSPI port in u-boot as I couldn¹t get it to
work in the kernel, so yes, some don¹t seem to work in 2.6.32

The codec side you need to make sure you use the correct bsp port in the
init of the codec machine driver.

snd_soc_dai_link omap3cdb42l73_dai[] = {
{
        .name = "CS42L73_XSP",
        .stream_name = "CS42L73_XSP",
        .cpu_dai = &omap_mcbsp_dai[0],
        .codec_dai = &cs42l73_dai[CS42L73_XSP],
        .ops = &omap3cdb42l73_ops,
        .init = beagle_cs42l73_init,

The omap_mcbsp_dai is selected as the first interface to the bsp dai.

You need to associate that dai to the correct bsp.

*(unsigned int *)omap3cdb42l73_dai[0].cpu_dai->private_data = 2; /* McBSP3
*/

You call that in the init of the machine driver.

--Sorry for the top post---

Brian

Hi Brian, thanks for the tips -- see below.

You need to make sure you have the Muxing setup correctly in the
board-omap3beagle.c file.

Here I mux the pins on the expansion header to get McBSP3

/* CS42L73 <-> McBSP3 on the expansion header */
/*K26*/ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLDOWN),
/* McBSP3_FSX */
/*W21*/ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLDOWN),
/* McBSP3_CLKX */
/*U21*/ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLDOWN),
/* McBSP3_DR */
/*V21*/ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT),
/* McBSP3_DX */

I have tried similar stuff. I have a question, is this setting the
beagleboard up as a slave? clks are inputs here?

You add this stuff in omap_board_mux board_mux[] __initdata = {
You get the values for the OMAP3_MUX from the beagleboard usersguide.

In recent kernel there is a mux setup that sets pretty reasonable
defaults, unless I don't understand stuff like in/output direction
correctly.

**Note** I had to mux the McSPI port in u-boot as I couldn¹t get it to
work in the kernel, so yes, some don¹t seem to work in 2.6.32

The codec side you need to make sure you use the correct bsp port in the
init of the codec machine driver.

snd_soc_dai_link omap3cdb42l73_dai[] = {
{
.name = "CS42L73_XSP",
.stream_name = "CS42L73_XSP",
.cpu_dai = &omap_mcbsp_dai[0],
.codec_dai = &cs42l73_dai[CS42L73_XSP],
.ops = &omap3cdb42l73_ops,
.init = beagle_cs42l73_init,

The omap_mcbsp_dai is selected as the first interface to the bsp dai.

You need to associate that dai to the correct bsp.

*(unsigned int *)omap3cdb42l73_dai[0].cpu_dai->private_data = 2; /* McBSP3
*/

All this is radically changed in recent alsa and kernels.

Regards, Steve

Hi I am curious is the above a typo? Isn't this setting mcbsp1 muxes?

Regards, Steve