beagleboard xm alsa in mcbsp3. 2.6.39-rc4

2011-06-09 Thread Steve Calfee 
Hi,

I have mcbsp1 working on an external codec. I moved the wires to the
mcbsp3 pins. The codec is master, using tdm mode. I use the same codec
i2s bus, and it gets the same setup (I change the dai-link stuff in my
alsa machine driver to use the other omap i2s bus for my tests). If I
pull the clk wire off the beagleboard pin, the clock from the codec
looks good. With the wire attached to the pin, I don't see the pin
wiggling. So it looks like maybe the pin is an output or something. The
frame clock looks ok while connected.

In the board-omap3beagle.c I configure all 3 mcbsp the same way:


#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
#if 1
/* McBSP 1 slave */
OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#else
/* McBSP 1 master */
OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#endif
#if 1
/* McBSP 2 slave */
OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#else
/* McBSP 2 master */
OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#endif
#if 1
/* McBSP 3 slave */
OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP3_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP3_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#else
/* McBSP 3 master */
OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP3_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP3_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif

So far I have not been able to get the codec mastered bit clock to work
on either mcbsp2 or msbsp3.

I have been trying to follow the logic in mcbsp.c and in omap-mcbsp.c in
how things get inited. I suspect there is something I have not done?

Any ideas.

Thanks, Steve
--
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: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

2011-05-29 Thread Steve Calfee 
On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman khil...@ti.com wrote:
 Cousson, Benoit b-cous...@ti.com writes:

 [...]

 In general we do not want to reset nor idle an IP that was potentially
 already properly configured by bootloader or early Linux boot code.

 Actually, the opposite is true.

 The kernel should not make any assumptions about what the bootloader has
 or has not done.  We need to have a kernel that can boot from any
 bootloader (or none, like using kexec) and be able to start from a known
 hardware state.

YES. Bootloaders should only do what is necessary (set clocks, enable
memories etc) to load the next stage. Pushing stuff that should be in
the kernel into the bootloader (like iniiting gpios and other things)
bloats it and makes a developer deal with two entirely different
source trees (kernel and booterx) to enable a new feature or to fix
bugs.

Uboot tends to lag the kernel in capabilities too, probably because
fewer developers or something. For instance Beagleboard xm uboot
cannot access the ethernet because it is usb based, and uboot cannot
access its own environment in flash - because it is running from a new
microsd based flash system. U-boot will eventually catch up with
these, but by then other new hardware will be available.

Does anyone know if 2.6.39 has kexec working again for the kernel? NFS
boot is a dream development environment but with both u-boot and kexec
not working with nfs, it is slightly more work and less automated.

Regards, Steve
--
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: [PATCH 1/2] OMAP4: HDMI: Add OMAP device for HDMI audio CPU DAI

2011-05-24 Thread Steve Calfee 
On 05/23/11 20:39, Ricardo Neri wrote:
 Hi Steve,
 
 Le mercredi 18 mai 2011 à 12:07 -0500, Steve Calfee a écrit :
 On 05/17/11 22:41, Peter Ujfalusi wrote:
 On Tuesday 17 May 2011 22:35:09 Steve Calfee wrote:
 I think the generally accepted method of doing stuff like this is to
 have the ifdeffery in a header file where a inline code segment is
 defined if it applies to the processor being built. If the code does not
 apply to the model being built, a null #define is used, which does not
 take any space.

SNIP

 The preferred header contained ifdeffery does not exclude the
 possibility of having multiple options selected, even at run time. It
 also can prevent multi cpu code bloat if it is not wanted.
 Alternatively, X86 distributions such as Ubuntu already deal with
 multiple arches (within the base arch intel/amd), using initrd type
 startups.

 Also the current cpu_is stuff is not very scalable, when TI gets to
 Omap42, or even slightly smaller such as Omap5, the untidiness of the
 current technique will become even more of a problem.

 
 Thanks for your comments. Even though the use of cpu_is_ may not be the
 best approach, it is used extensively in OMAP code. Do you think that
 this situation needs to be fixed before accepting the patches for these
 two devices?


Hi Ricardo,

I am not the omap maintainer, I am not blocking anything.

I have lately been surfing the Omap code on a project. The cpu_is_*
stuff is common and growing. People are fixing it, see the patch for
gpio that was in today's mail.

I know you just want to get your stuff into the tree, not fix the entire
tree from problems you did not cause. However, someday, someone will
have to fix it up.

For instance as an example of how to remove #ifdefs --
arch/arm/mach-omap2/clock.h uses ifdeffery in the header to remove it
from the c code. It checks a config option and adds or removes code with
no source changes.

It is possible to add a config_all_options so run time checks could be
made for the cases when a single executable is desired for multiple
archs. In this case the macro or static inline could wrap the option
selected code with a runtime cpu_is check, all without modifying the .c
source code.

The optimizing compiler is really friendly to conditionally doing stuff,
if/else clauses that are never used (constants in conditionals) just
disappears.

Sample header file definitions (not even compile tested, in fact
intentionaly incomplete but based on your patch):

static inline  void __omap_init_hdmi_audio(struct your args) {
oh_hdmi = omap_hwmod_lookup(oh_hdmi_name);
WARN(!oh_hdmi, %s: could not find omap_hwmod for %s\n,
__func__, oh_hdmi_name);

od_hdmi = omap_device_build(dev_hdmi_name, -1, oh_hdmi, NULL, 0,
NULL, 0, false);
WARN(IS_ERR(od_hdmi), %s: could not build omap_device for %s\n,
__func__, dev_hdmi_name);
}

#ifdef CONFIG_ALL_OPTIONS
static inline  void omap_init_hdmi_audio(struct your args)
{
if (cpu_is_omap44xx())
__omap_init_hdmi_audio(struct your args);
}
#else
#ifdef CONFIG_CPU_OMAP44XX
static inline  void omap_init_hdmi_audio(struct your args)
{
__omap_init_hdmi_audio(struct your args);
}
#else
static inline  void omap_init_hdmi_audio(struct your args) {}
#endif

And then the .c code would just contain:
omap_init_hdmi_audio(struct your args);

 Also, in the case of OMAP, runtime CPU identification is needed, for the
 reason Peter mentions. It is hard for me to see how it can be
 implemented using #ifdef only. Do you think that runtime CPU
 identification should be moved to the header containing the ifdeferry?

Yes, based on configuration options. An alternative to ifdefs and cpu_is
is like today's omap gpio changes, where data is stuck in some structure
at init time and then used at run time to conditionally init stuff. This
can be fairly obscure, but so are macros, and it is caused by the
fundamentally difficult problems of a maze of arches similar, but not
identical.

 Individual functions for different domains (audio, video, etc.) would
 still need to check at runtime if their devices are required. Perhaps
 having a single omap2plus_defconfig for all OMAP2/3/4/x/y/... devices is
 no longer convenient as more and more OMAP families arrive. What do you
 think?

Such choices that are realistic runtime detected requirements are fine.
In most cases I have seen they are arch specific and board specific, so
really the capabilities should be platform specific and only actually
used on systems that need the capabilities.

 
 Regarding using a initrd, that applies only for loadable modules, but
 not for built-in modules, correct?
 

Yes, although I think it is possible for an initrd to select another
kernel to load. In any case that is distribution specific and should not
really be required for most omap kernel use. I merely suggested it was a
possible alternative to an all-in one kernel build for your

Re: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-20 Thread Steve Calfee 
On 05/19/11 23:29, Jarkko Nikula wrote:
 On Thu, 19 May 2011 17:58:56 -0700
 Steve Calfee stevecal...@gmail.com wrote:
 
...

 This very likely sounds that in master mode the master clock to McBSP is
 missing if there is no DMA running. Did you try to use internal 96 MHz
 from my example or did you try to use external CLKS what Pandora is
 using? That CLKS setup in Pandora requires that there is a clock coming
 to McBSP CLKS pin.
 
 But as you got codec slave mode working it seems that pin multiplexing
 is ok so there is no need to try with master mode. In problematic cases
 the master mode is a good start since then only McBSP clock setup and
 pin multiplexing can affect if there are no clock and data signals
 visible.
 

OK, you called this correctly. Apparently the beagle does not by default
have a clock on the clks pin. When I correctly followed your suggestion
and changed to the internal 96,000,000 clock I do get transitions on the
mcbsp1 clk and fsx pins.

The problem is 96M is pretty big. the only divisor I see is 8 bits, your
suggested division (else where of 62) only brings the bit clock rate to
about 15Mhz. the frame clock did get set very near the 8Khz for the
sample playback. So about 1900 bit clocks are sent per frame.

This would be ok, but since the mcbsp does not respect the l/r clock
(FSX) for shifting out data, I am back to getting audio on only one ear.
I was hoping that in master mode I could configure the mcbsp to only
send 16 bit clocks per frame. It looks like the clocks are not that
configurable.

The external clks pin is supposed to be connect to an external TPS65950
chip which divides down the source 26Mhz clock by 256. I'll have to
investigate why I was not seeing that clock.

Regards, Steve
--
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: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-19 Thread Steve Calfee 
On 05/19/11 04:28, Peter Ujfalusi wrote:
...
 
 My codec cannot be set to use only 16 bits per phase. Is there a way to
 setup the omap so that data is sent to both channels? As you can see
 above the xphase bit is one saying dual channels. Is this a dma setup
 problem?
 
 I can not find datasheet for the max98095...
 So you can not configure the codec to use 2x16 number of bit clocks. when it 
 is configured to receive/send 16bit stereo samples?
Correct, I can set bit clock to 64*lrclk, 48*lrclk, 128*lrclk, 17*lrclk,
and 18*lrclk. The audio folks here think that it is normal to send more
than required bit clocks, data is sent first so just ignore the rest.

It would appear that the mcbsp doesn't really use the lrclk (I think
called FSX), it just uses a positive transition to start the bit
shifting for all the requested bits. The falling edge does not start the
right channel, the shifter keeps going until all requested l/r counts
have been sent.

Or maybe something in the mcbsp has not been set up correctly?

 Is this the case (that the codec all the time have 32 clock cycles per 
 channel)? 
 
 If this is the case, than it is kind of tricky to get around this, but you 
 can 
 try the following (warning: hack):
 
 In the codec driver:
 create/add a startup callback function for the dais (snd_soc_dai_ops):
 
 static int max98095_startup(struct snd_pcm_substream *substream,
  struct snd_soc_dai *dai)
 {
   snd_pcm_hw_constraint_msbits(substream-runtime, 0, 32, 16);
 
   return 0;
 }
 
 Modify the MAX98095_FORMATS to only support S32_LE (remove the other formats 
 for now)
 
 In the hw_params calls handle the S32_LE in a same way as you handle the 
 S16_LE.
 
 To explain what we are doing:
 Configure the codec to support only S32_LE format, but tell ALSA, that out of 
 the 32 bit only the first 16bit is valid.
 So the driver will be opened with S32_LE mode, but only the first 16 bits 
 will 
 have audio data:
 0-15: Left audio
 16-31: zero (padding on left channel)
 32-47: Right audio
 48-63: zero (padding on right channel)
 
 Use aplay -Dplughw:0,0 -v some sample to play audio, and see, if the HW has 
 been opened with S32_LE.
 
 You should have full stereo sound now.

I do, thanks. I am truly amazed that I was able to follow your
instructions and get it to work first time. You must really know your
alsa machine implementation.


The problem is that now I cannot run 44.1Khz audio, I get underruns. I
am guessing that software is expanding the samples from 16 bits to 32?
Without your hack 44.1Khz audio works fine (but only audible in the
first channel).


 I have CC-d the author of the wm98095 codec driver, hi might be able to help 
 you with the codec setup...
 

I talk to Peter every day. He brought up the codec, I am trying to use
the Beagleboardxm as a generic Linux platform for new codec bringups and
for following kernel and alsa cutting edge software.

Regards, Steve
--
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: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-19 Thread Steve Calfee 
On 05/18/11 18:06, Steve Calfee wrote:
 On 05/16/11 23:37, Jarkko Nikula wrote:

 Did you try to run OMAP as an I2S master like what omap3pandora.c is
 doing?

 Missing clock in codec master configuration suggests that reason
 is in codec side and reversed roles during development makes easier to
 hunt it further as then OMAP can play data out independently of is the
 codec correctly configured or not.

 You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS
 as a DAI format for both codec and OMAP and by setting McBSP to use
 internal 96 MHz clock as a master clock. Something like below might work
 for testing purposes:

 snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK,
 9600, SND_SOC_CLOCK_IN);

 snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV,
 62); /* 96M / 48k*32 */

 Hi,
 
 The hunt for clock continues. I redid my board-omap3beaglexm.c to as
 closely match what board-omap3pandora.c is doing as I can. Like pandora,
 I don't explicitly set the mux pin directions, I guess mcbsp master is
 the default.
 
 I also tried to get as close as I could to the soc/omap/omap3pandora.c
 machine driver with my omap3beaglexm.c machine driver. Specifically in
 the *_hw_params init routines.
 
 But when I start things up (even with the codec disconnected from the
 bclk line), I don't get any movement on the CLK and fsx. And of course
 the dma doesn't send anything.
 

I have gotten mcbsp1 to work as a slave (sort-of) with Peter's help. I
havent been able to get it to clock as a master. So now I try with
mcbsp3, still no luck.

More missing mcbsp bit clock. I am trying on mcbsp3. I am trying to get
master mode working. Here is the register dump from the console (I have
some debug printouts on).

[   30.039978] snd_pcm_do_start: state 3
[   30.043823] omap_pcm_trigger: cmd 1
[   30.047760] omap_start_dma: lch 0
[   30.051696] omap-mcbsp omap-mcbsp.3:  McBSP3 regs 
[   30.057464] omap-mcbsp omap-mcbsp.3: DRR2:  0x2820d81
[   30.062774] omap-mcbsp omap-mcbsp.3: DRR1:  0x
[   30.067779] omap-mcbsp omap-mcbsp.3: DXR2:  0x
[   30.072814] omap-mcbsp omap-mcbsp.3: DXR1:  0x
[   30.077850] omap-mcbsp omap-mcbsp.3: SPCR2: 0x02f5
[   30.082885] omap-mcbsp omap-mcbsp.3: SPCR1: 0x0030
[   30.087890] omap-mcbsp omap-mcbsp.3: RCR2:  0x80a1
[   30.092926] omap-mcbsp omap-mcbsp.3: RCR1:  0x00a0
[   30.097961] omap-mcbsp omap-mcbsp.3: XCR2:  0x80a1
[   30.102966] omap-mcbsp omap-mcbsp.3: XCR1:  0x00a0
[   30.108001] omap-mcbsp omap-mcbsp.3: SRGR2: 0x10c0
[   30.113037] omap-mcbsp omap-mcbsp.3: SRGR1: 0x5f3d
[   30.118041] omap-mcbsp omap-mcbsp.3: PCR0:  0x0f0f
[   30.123077] omap-mcbsp omap-mcbsp.3: ***




My BSP sets up the mux for mcbsp3:

#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
#if 1
/* McBSP 1 slave */
OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#else
/* McBSP 1 master */
OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#endif
/* McBSP 3 master */
OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(MCBSP3_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP3_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif

And with the mcbsp 4 pins not connected to anything but the scope, I
don't see any bitclock movement. I think others used u-boot to setup the
mcbspx, but has anyone successfully used linux to set up the pins?

Thanks, Steve
--
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: [PATCH 1/2] OMAP4: HDMI: Add OMAP device for HDMI audio CPU DAI

2011-05-18 Thread Steve Calfee 
On 05/17/11 22:41, Peter Ujfalusi wrote:
 On Tuesday 17 May 2011 22:35:09 Steve Calfee wrote:
 I think the generally accepted method of doing stuff like this is to
 have the ifdeffery in a header file where a inline code segment is
 defined if it applies to the processor being built. If the code does not
 apply to the model being built, a null #define is used, which does not
 take any space.
 
 We have for example omap2plus_defconfig, which include support for wide range 
 of OMAP based devices, with different CPUs (OMAP2/3/4).
 So we need to have runtime distinction of the CPU we are running (since we 
 run 
 the same kernel binary on OMAP2/3/4).
 

Hi Peter,

I am not trying to start a flame war here, especially not with you
really helpful people.

The preferred header contained ifdeffery does not exclude the
possibility of having multiple options selected, even at run time. It
also can prevent multi cpu code bloat if it is not wanted.
Alternatively, X86 distributions such as Ubuntu already deal with
multiple arches (within the base arch intel/amd), using initrd type
startups.

Also the current cpu_is stuff is not very scalable, when TI gets to
Omap42, or even slightly smaller such as Omap5, the untidiness of the
current technique will become even more of a problem.

Regards, Steve
--
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: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-18 Thread Steve Calfee 
On 05/17/11 03:42, Peter Ujfalusi wrote:
 Hi,
 
 On Monday 16 May 2011 21:07:40 Steve Calfee wrote:
 No, they get called. I just don't get the clock on the bclk pin.
 
 OK.
 Could you try to disconnect the CLKX, and FSX lines from OMAP, and see that 
 you have the clocks on the codec side?
 If in this way you still can not see the clocks, than your codec (max98095 ?) 
 is not generating the clocks.
 Could you also post from your machine driver how you configure the formats 
 for 
 cpu/codec DAI (snd_soc_dai_set_fmt call)?
 
 While the clock lines are not physically connected, you can try to configure 
 either side to generate the correct clocks on the lines. When you see that, 
 you can connect them together, and see (hear) if it works.
 
Hi,

Good suggestion. After switching to my codec as master, I could see the
clocks. But one problem was the beagleboardxm trainer has level
shifters, but they are one directional, and not correct for my use. So I
reconnected to the expansion port pins (and re-did the voltage
requirement of the codec to 1.8 volts). Now I get some sound.

One problem remains and is a mystery to me. My omap setup with the
max98095 codec is identical to the on board twl4030 device. The twl4030
works find, but my codec only plays one channel.

I hooked up a logic analyzer and discovered that my codec sends 32 bit
clocks per fsx or what we call lrclk. The twl4030 sends 16 bit clocks
per lrclk. I think that more than 16 bits is supposed to be ok and
someone here said some of the high end audio test equipment only sends
64 bitclock per lrclock and that seems to be within the standard. I
think the I2S protocol says data bits are aligned with the lrclk, so
what should be happening is the omap slave should send 16 bits of audio
followed by 16 bits of null, then the lrclk switches and it should send
the other channel of audio followed by null.

The data being sent by the omap is actually 32 bits in the first lrclk
phase, comprising the left 16 bits and the right 16 bits. The second
lrclk phase gets null sent for all 32 bits. My 32 bits has the same data
(from the same .wav file) that was sent to the twl4030 as two 16 bit
channels.

Here is the mcbsp register dump (the same from both twl4030 and max98095
runs).

[   54.391174] omap_pcm_trigger: cmd 1
[   54.395111] omap_start_dma: lch 0
[   54.399047] omap-mcbsp omap-mcbsp.1:  McBSP1 regs 
[   54.404815] omap-mcbsp omap-mcbsp.1: DRR2:  0x2000100
[   54.410125] omap-mcbsp omap-mcbsp.1: DRR1:  0x
[   54.415130] omap-mcbsp omap-mcbsp.1: DXR2:  0x
[   54.420166] omap-mcbsp omap-mcbsp.1: DXR1:  0x
[   54.425201] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0235
[   54.430206] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
[   54.435241] omap-mcbsp omap-mcbsp.1: RCR2:  0x8041
[   54.440277] omap-mcbsp omap-mcbsp.1: RCR1:  0x0040
[   54.445281] omap-mcbsp omap-mcbsp.1: XCR2:  0x8041
[   54.450317] omap-mcbsp omap-mcbsp.1: XCR1:  0x0040
[   54.455352] omap-mcbsp omap-mcbsp.1: SRGR2: 0x001f
[   54.460388] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f00
[   54.465393] omap-mcbsp omap-mcbsp.1: PCR0:  0x000f
[   54.470428] omap-mcbsp omap-mcbsp.1: ***
[   54.476379] snd_pcm_post_start: state 3

My codec cannot be set to use only 16 bits per phase. Is there a way to
setup the omap so that data is sent to both channels? As you can see
above the xphase bit is one saying dual channels. Is this a dma setup
problem?

Thanks for your help.

Regards, Steve
--
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: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-18 Thread Steve Calfee 
On 05/16/11 23:37, Jarkko Nikula wrote:
 Hi
 
 On Mon, 16 May 2011 11:07:40 -0700
 Steve Calfee stevecal...@gmail.com wrote:
 
 On 05/16/11 01:54, Peter Ujfalusi wrote:
 On Saturday 14 May 2011 05:47:33 Steve Calfee wrote:
 I put in a few debug statements. It appears that my DMA never gets
 started. I know it can work with a different machine and codec driver,
 but not mine. I don't see any explicit DMA init, but that must be the
 problem.  Any more ideas?

 You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called?
 Could you post the output of dmesg related to ASoC? Does the connection 
 between the CPU and codec DAI correct?
 Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, 
 omap_mcbsp_dai_trigger got called)?

 No, they get called. I just don't get the clock on the bclk pin.

 I think I have the mcbsp1 set up correctly - I explictly set the MUX:

 static struct omap_board_mux board_mux[] __initdata = {
 #if 1
  /* McBSP 1 */
  OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
  OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
  OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
  OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
 #endif
  { .reg_offset = OMAP_MUX_TERMINATOR },
 };

 Did you try to run OMAP as an I2S master like what omap3pandora.c is
 doing?
 
 Missing clock in codec master configuration suggests that reason
 is in codec side and reversed roles during development makes easier to
 hunt it further as then OMAP can play data out independently of is the
 codec correctly configured or not.
 
 You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS
 as a DAI format for both codec and OMAP and by setting McBSP to use
 internal 96 MHz clock as a master clock. Something like below might work
 for testing purposes:
 
 snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK,
  9600, SND_SOC_CLOCK_IN);
 
 snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV,
  62); /* 96M / 48k*32 */
 
Hi,

The hunt for clock continues. I redid my board-omap3beaglexm.c to as
closely match what board-omap3pandora.c is doing as I can. Like pandora,
I don't explicitly set the mux pin directions, I guess mcbsp master is
the default.

I also tried to get as close as I could to the soc/omap/omap3pandora.c
machine driver with my omap3beaglexm.c machine driver. Specifically in
the *_hw_params init routines.

But when I start things up (even with the codec disconnected from the
bclk line), I don't get any movement on the CLK and fsx. And of course
the dma doesn't send anything.

Thanks for the suggestion.

Regards, Steve

--
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: [PATCH 1/2] OMAP4: HDMI: Add OMAP device for HDMI audio CPU DAI

2011-05-17 Thread Steve Calfee 
On 05/16/11 20:14, Ricardo Neri wrote:

 +++ b/arch/arm/mach-omap2/devices.c
 @@ -313,6 +313,22 @@ OMAP_MCBSP_PLATFORM_DEVICE(5);
  
  static void omap_init_audio(void)
  {
 + struct omap_hwmod *oh_hdmi;
 + struct omap_device *od_hdmi;
 + char *oh_hdmi_name = dss_hdmi;
 + char *dev_hdmi_name = hdmi-audio-dai;
 +
 + if (cpu_is_omap44xx()) {
 + oh_hdmi = omap_hwmod_lookup(oh_hdmi_name);
 + WARN(!oh_hdmi, %s: could not find omap_hwmod for %s\n,
 + __func__, oh_hdmi_name);
 +
 + od_hdmi = omap_device_build(dev_hdmi_name, -1, oh_hdmi, NULL, 0,
 + NULL, 0, false);
 + WARN(IS_ERR(od_hdmi), %s: could not build omap_device for 
 %s\n,
 + __func__, dev_hdmi_name);
 + }
 +
   platform_device_register(omap_mcbsp1);
   platform_device_register(omap_mcbsp2);
   if (cpu_is_omap243x() || cpu_is_omap34xx() || cpu_is_omap44xx()) {

I know you did not start this, but this cpu_is stuff is cheating. There
is a rule (maybe a guideline, or desire) in the kernel where they try to
minimize #ifdef in c code. So here we have a runtime ifdef. The code
will never be executed on other omap versions, but it takes up space and
obscures the code flow.

I think the generally accepted method of doing stuff like this is to
have the ifdeffery in a header file where a inline code segment is
defined if it applies to the processor being built. If the code does not
apply to the model being built, a null #define is used, which does not
take any space.

Using a conditional inline enables the only source code change for this
file (device.c) being a line where the inline code is called.

Regards, Steve
--
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: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-16 Thread Steve Calfee 
On 05/16/11 01:54, Peter Ujfalusi wrote:
 On Saturday 14 May 2011 05:47:33 Steve Calfee wrote:
 I put in a few debug statements. It appears that my DMA never gets
 started. I know it can work with a different machine and codec driver,
 but not mine. I don't see any explicit DMA init, but that must be the
 problem.  Any more ideas?
 
 You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called?
 Could you post the output of dmesg related to ASoC? Does the connection 
 between the CPU and codec DAI correct?
 Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, 
 omap_mcbsp_dai_trigger got called)?
 
No, they get called. I just don't get the clock on the bclk pin.

I think I have the mcbsp1 set up correctly - I explictly set the MUX:

static struct omap_board_mux board_mux[] __initdata = {
#if 1
/* McBSP 1 */
OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};

And elsewhere I set the mcbsp to use a 4 pin interface:
/* configure mcbsp1 to just use 4 pins */
ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0,
SND_SOC_CLOCK_IN);
if (ret  0) {
printk(KERN_ERR can't set CPU system clock 
OMAP_MCBSP_CLKR_SRC_CLKX\n);
//return ret;
}

ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0,
SND_SOC_CLOCK_IN);
if (ret  0) {
printk(KERN_ERR can't set CPU system clock 
OMAP_MCBSP_FSR_SRC_FSX\n);
//return ret;
}


Here is some hopefully relevant console output. Note that where I added
debug printk's I also printed the __func__.

# cat /proc/asound/cards
 0 [bbxm   ]:  - bbxm
  bbxm
# lsmod
Module  Size  Used byNot tainted
snd_soc_max98095   26314  1
snd_soc_omap3beaglexm 4818  0
snd_soc_omap_mcbsp  7148  1
gpio_i2cmux 1699  0
i2c_mux 1408  1 gpio_i2cmux
# aplay /newmail2.wav
[  262.129882] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0
[  262.137847] omap-mcbsp omap-mcbsp.1: omap_mcbsp_request:
tx_irq_completion t=59 r=60
[  262.146972] omap_mcbsp_dai_startup: rules omap-mcbsp-dai.0 bus_id=0
active 0
[  262.155090] omap_pcm_open: ret 1
[  262.158752] asoc: HiFi - omap-mcbsp-dai.0 info:
[  262.163757] asoc: rate mask 0x7fe
[  262.167327] asoc: min ch 1 max ch 2
[  262.170989] asoc: min rate 8000 max rate 96000
Playing WAVE '/newmail2.wav' : Signed 16 bit Little Endian, Rate 8000
Hz, Stereo
[  262.188537] bbxm_hw_params: codec_dai=dfbb9ac0 clk 12288000
[  262.194519] bbxm_hw_params 2: codec_dai=dfbb9ac0 clk 12288000
[  262.200683] omap_mcbsp_dai_set_dai_fmt: configured 0
[  262.205932] bbxm_hw_params 3: codec_dai=dfbb9ac0 clk 12288000
[  262.212036] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5f8 in_freq 0
[  262.219116] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5f8 in_freq 0
[  262.227752] max98095 4-0010: read 2a = 90
[  262.234832] max98095 4-0010: read 27 = 1
[  262.240875] max98095 4-0010: read 2a = 90
[  262.245300] max98095 4-0010: write 28 = 7
[  262.252044] max98095 4-0010: write 29 = 8f
[  262.261779] max98095 4-0010: read 2e = 0
[  262.266265] omap_mcbsp_dai_hw_params: format 1
[  262.270996] omap_mcbsp_dai_hw_params: stream Audio Playback
[  262.276977] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base:
0x48074000
[  262.284606] omap_pcm_hw_params: ret 0
[  262.290008] omap_pcm_prepare: dma_data bf00d4e0
[  262.298980] max98095 4-0010: read 91 = 0
[  262.303558] max98095 4-0010: write 91 = 3
[  262.311798] max98095 4-0010: read 91 = 3
[  262.316345] max98095 4-0010: write 91 = c3
[  262.326690] snd_pcm_lib_write1: state 2 size 1000
[  262.332031] snd_pcm_lib_write1: offset 0
[  262.336181] snd_pcm_update_state: stream=0 avail=3000
buffer_size=4000 twake=0 tsleep=1
[  262.345825] snd_pcm_lib_write1: state 2 size 1000
[  262.351165] snd_pcm_lib_write1: offset 0
[  262.355346] snd_pcm_update_state: stream=0 avail=2000
buffer_size=4000 twake=0 tsleep=1
[  262.364929] snd_pcm_lib_write1: state 2 size 1000
[  262.370269] snd_pcm_lib_write1: offset 0
[  262.374420] snd_pcm_update_state: stream=0 avail=1000
buffer_size=4000 twake=0 tsleep=1
[  262.383972] snd_pcm_lib_write1: state 2 size 1000
[  262.389312] snd_pcm_lib_write1: offset 0
[  262.393463] snd_pcm_pre_start: state 3
[  262.397399] snd_pcm_do_start: state 3
[  262.401245] omap_pcm_trigger: cmd 1
[  262.404907] omap_start_dma: lch 0
[  262.408843] omap-mcbsp omap-mcbsp.1:  McBSP1 regs 
[  262.414581] omap-mcbsp omap-mcbsp.1: DRR2:  0x
[  262.419616] omap-mcbsp omap-mcbsp.1: DRR1:  0x
[  262.424652] omap-mcbsp omap-mcbsp.1: DXR2

Re: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-13 Thread Steve Calfee 
On Thu, May 12, 2011 at 10:59 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 On Thursday 12 May 2011 21:43:20 Steve Calfee wrote:
 Since it is set to 0xF0F, doesn't this set it as master?

 Sorry, that is correct, McBSP is configured as msater.

 Also, spelunking the kernel sources, I cannot seem to find the source
 for mcbsp_data-regs -- do you know where it gets set initially?

 They configured within sound/soc/omap/omap-pcm.c

 Have you configured the clk source, and divider correctly for McBSP port from
 the machine driver (with snd_soc_dai_set_sysclk)?


Hi, Thanks for the suggestions.

I think I have it correct. I was able to load the original
sound/soc/beagleboard.c and the codec/twl4030 and play a wav file. I
have been copying that to try and get my new codec driver to work. One
immediate difference is that the system sets up the twl4030 as the
master i2s device on the bus. So I changed my codec over to do that
too. Now the mcbsp register dump matches the working setup.

I put in a few debug statements. It appears that my DMA never gets
started. I know it can work with a different machine and codec driver,
but not mine. I don't see any explicit DMA init, but that must be the
problem.  Any more ideas?

Thanks, Steve
--
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: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-12 Thread Steve Calfee 
On 05/12/11 04:01, Peter Ujfalusi wrote:
 On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote:
 Of course for this you need to use omap as a master and codec as a
 slave. One example for this is sound/soc/omap/omap3pandora.c.

  static struct omap_board_mux board_mux[] __initdata = {
 +OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
 +OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
 +OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 +OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
 +
 
 I think the CLKX, FSX need to be input, since the config suggests,t that 
 McBSP1 is the slave port:
 
 [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f
 

Hi, thanks for trying to help.

I already tried that, but it still did not xmit. Now I wonder about
master/slave. I thought that the omap is set up as a master. I looked at
PCR0 docs in the tech ref manual and I get:

11 FSXM Transmit Frame-Synchronization Mode RW 0x0
0x0: Frame-synchronization signal derived from an
external source
0x1: Frame synchronization is determined by the SRG
frame-synchronization mode bit FSGM in SRGR2.
10 FSRM Receive Frame-Synchronization Mode RW 0x0
0x0: Frame-Synchronization pulses generated by an
external device. FSR is an input pin.
0x1: Frame synchronization generated internally by SRG.
FSR is an output pin except when GSYNC=1 in SRGR.
Etc.

Since it is set to 0xF0F, doesn't this set it as master?

Also, spelunking the kernel sources, I cannot seem to find the source
for mcbsp_data-regs -- do you know where it gets set initially?


--
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: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type

2011-05-11 Thread Steve Calfee 
On 05/11/11 06:55, Sanjeev Premi wrote:
 Current checks for cpu type were too restrictive leading
 to failures for other silicons in same family.
 
 The problem was found while testing audio playback on
 AM37x and AM35x processors. But should exist on OMAP36xx
 as well.
 
 Signed-off-by: Sanjeev Premi pr...@ti.com
 cc: Mark Brown broo...@opensource.wolfsonmicro.com
 cc: Liam Girdwood l...@ti.com
 cc: Jarkko Nikula jhnik...@gmail.com
 ---
 
  Changes in v4:
Reposting after validating that patch still applies cleanly on
linux-omap master [46966f1]
 
Changed the subject as suggested by Jarkko. Since the subject
has changed, i have omitted v4.
 
  Changes in v3::
None. Reposting[1] after subscribing to alsa-devel list
 
  Changes in v2:
1) Added one more check to the changes.
2) Updated commit message to use plurals.
 
 

Hi,

I removed all but the linux-omap list for my question.

I am trying to get the beagleboardxm to work with an external codec. I
am trying to use a mcbsp1 via the trainer board where it level shifts to
5 volts. I have applied this patch (I am on 2.6.39rc4), but still no
joy. I have a small analyzer attached to the I/O pins and important
things like the bit clock does not wiggle.

First a side question. In the arch/arm/mach-omap2/Kconfig when I select
BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference
manual says The BeagleBoard-xM processor is the DM3730CBP 1GHz version
which to me implies the proper package selection should be
OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for
them, but I cant quickly tell the difference. Does this matter for mcbspx?

Here is a console dump where I try to aplay a file:
[ 1565.773712] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0
[ 1565.781829] omap_pcm_open: ret 1
[ 1565.785491] asoc: HiFi - omap-mcbsp-dai.0 info:
[ 1565.790527] asoc: rate mask 0x7fe
[ 1565.794006] asoc: min ch 1 max ch 2
[ 1565.797760] asoc: min rate 8000 max rate 96000
[ 1565.826721] bbxm_hw_params: codec_dai=dfbbb9c0 clk 12288000
[ 1565.832702] bbxm_hw_params 2: codec_dai=dfbbb9c0 clk 12288000
[ 1565.838867] omap_mcbsp_dai_set_dai_fmt: configured 0
[ 1565.844146] bbxm_hw_params 3: codec_dai=dfbbb9c0 clk 12288000
[ 1565.850219] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0
[ 1565.857299] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0
[ 1565.864379] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8
in_freq 2048000
[ 1565.877319] max98095 4-0010: read 2a = 10
[ 1565.884277] max98095 4-0010: read 27 = 1
[ 1565.891143] max98095 4-0010: read 2a = 10
[ 1565.898956] max98095 4-0010: read 2e = 0
[ 1565.903198] omap_mcbsp_dai_hw_params: format 1
[ 1565.907958] omap_mcbsp_dai_hw_params: stream Audio Playback
[ 1565.913909] omap_mcbsp_dai_hw_params: framesize 32 in_freq=2048000
div=8 rate=8000
[ 1565.921936] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base:
0x48074000
[ 1565.929565] omap_pcm_hw_params: ret 0
[ 1565.934722] omap_pcm_prepare: dma_data bf00d4a0
[ 1565.945831] max98095 4-0010: read 91 = 0
[ 1565.950347] max98095 4-0010: write 91 = 3
[ 1565.958618] max98095 4-0010: read 91 = 3
[ 1565.963195] max98095 4-0010: write 91 = c3
[ 1565.972351] snd_pcm_lib_write1: state 2 size 1000
[ 1565.977691] snd_pcm_lib_write1: offset 0
[ 1565.981842] snd_pcm_update_state: stream=0 avail=3000
buffer_size=4000 twake=0 tsleep=1
[ 1565.992706] snd_pcm_lib_write1: state 2 size 1000
[ 1565.997985] snd_pcm_lib_write1: offset 0
[ 1566.002227] snd_pcm_update_state: stream=0 avail=2000
buffer_size=4000 twake=0 tsleep=1
[ 1566.011810] snd_pcm_lib_write1: state 2 size 1000
[ 1566.017120] snd_pcm_lib_write1: offset 0
[ 1566.021270] snd_pcm_update_state: stream=0 avail=1000
buffer_size=4000 twake=0 tsleep=1
[ 1566.033050] snd_pcm_lib_write1: state 2 size 1000
[ 1566.038360] snd_pcm_lib_write1: offset 0
[ 1566.042510] snd_pcm_pre_start: state 3
[ 1566.046447] snd_pcm_do_start: state 3
[ 1566.050292] omap_pcm_trigger: cmd 1
[ 1566.053955] omap_start_dma: lch 0
[ 1566.057891] omap-mcbsp omap-mcbsp.1:  McBSP1 regs 
[ 1566.063629] omap-mcbsp omap-mcbsp.1: DRR2:  0x
[ 1566.068664] omap-mcbsp omap-mcbsp.1: DRR1:  0x
[ 1566.073699] omap-mcbsp omap-mcbsp.1: DXR2:  0x
[ 1566.078735] omap-mcbsp omap-mcbsp.1: DXR1:  0x
[ 1566.083740] omap-mcbsp omap-mcbsp.1: SPCR2: 0x02f5
[ 1566.088775] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
[ 1566.093811] omap-mcbsp omap-mcbsp.1: RCR2:  0x8041
[ 1566.098846] omap-mcbsp omap-mcbsp.1: RCR1:  0x0040
[ 1566.103851] omap-mcbsp omap-mcbsp.1: XCR2:  0x8041
[ 1566.108886] omap-mcbsp omap-mcbsp.1: XCR1:  0x0040
[ 1566.113922] omap-mcbsp omap-mcbsp.1: SRGR2: 0x101f
[ 1566.118927] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f07
[ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f
[ 1566.128997] omap-mcbsp omap-mcbsp.1: ***
[ 1566.134918] snd_pcm_post_start: state 3
[ 1566.138977] snd_pcm_update_state: stream=0 avail=0 buffer_size=4000
twake=0 tsleep=1
[

Re: [PATCH] mfd: Fix usbhs_enable error handling

2011-04-26 Thread Steve Calfee 
On Tue, Apr 26, 2011 at 2:04 AM, Felipe Balbi ba...@ti.com wrote:
 On Tue, Apr 26, 2011 at 02:32:04PM +0530, Keshava Munegowda wrote:
  -Original Message-
  From: Felipe Balbi [mailto:ba...@ti.com]
  Sent: Tuesday, April 26, 2011 2:29 PM
  To: Keshava Munegowda
  Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com;
 gadi...@ti.com; p-
  bas...@ti.com; axel@gmail.com; johns...@us.ibm.com;
 mpfj-l...@mimc.co.uk
  Subject: Re: [PATCH] mfd: Fix usbhs_enable error handling
 
  Hi,
 
  On Thu, Apr 21, 2011 at 07:52:41PM +0530, Keshava Munegowda wrote:
   From: Axel Lin axel@gmail.com
  
   In the case of missing platform_data we do not hold a spin_lock,
   thus we should not call spin_unlock_irqrestore in the error path.
  
   Also simplify the error handling by separating the successful path
   from error path. I think this change improves readability.
  
   Signed-off-by: Axel Lin axel@gmail.com
 
  Can someone give me a Tested-by so I can take these patches.
 
  --
  Balbi

 Hi Balbi

 I have validated this patch and it works :)

 Tested-by: Keshava Munegowda keshava_mgo...@ti.com

 what about the others ?

 --
 balbi

Hi Felipe,

I responded on another thread. I tested this on a beagleboardxm on
version 2.6.39-rc4

 Hi Keshava,

 I rebuilt my system to boot from flash and now I see what happened. I
 even remember it being discussed on this list. Someone renamed my usb
 ethernet device from usb0 to eth0 !!! The boot log shows it on this
line:

  [4.596130] smsc95xx 1-2.1:1.0: eth0: register 'smsc95xx' at
  usb-ehci-omap.0d


 So this broke my init scripts and uboot script... OK, so I can live with
 this (I hope the name doesn't change too often though).

 So I can manually configure my system to use eth0 and use the network. I
 am sure I will get nfs working shortly.

 I am using the 2.6.39-rc4 with your 3 patches. So from the Beagleboard
 XM perspective it works and you can include my

 Tested-by: Steve Calfee stevecal...@gmail.com
--
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: [PATCH] mfd: Fix usbhs_enable error handling

2011-04-26 Thread Steve Calfee 
On 04/26/11 12:34, Felipe Balbi wrote:
 
 care to reply to this one with your Tested-by so I add to all patches
 and queue them to Greg ?
 
I just checked and these changes were part of the 3 patch set from
Keshava, and from the Beagleboard XM perspective it works and you can
include my

Tested-by: Steve Calfee stevecal...@gmail.com

--
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: [Regression?] Removed regulator support in ehci-omap

2011-04-25 Thread Steve Calfee 
On 04/25/11 09:41, Keshava Munegowda wrote:
 -Original Message-
 From: Steve Sakoman [mailto:sako...@gmail.com]
 Sent: Monday, April 25, 2011 7:46 PM
 To: Alan Ott
 Cc: Keshava Munegowda; Dmitry Artamonow; Steve Calfee; Felipe Balbi;
 linux-...@vger.kernel.org;
 linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org
 Subject: Re: [Regression?] Removed regulator support in ehci-omap

 On Mon, Apr 25, 2011 at 7:11 AM, Alan Ott a...@signal11.us wrote:
 On 04/24/2011 02:37 AM, Keshava Munegowda wrote:
 -Original Message-
 From: Alan Ott [mailto:a...@signal11.us]
 Sent: Friday, April 22, 2011 6:41 AM
 To: Keshava Munegowda
 Cc: Dmitry Artamonow; Steve Sakoman; Steve Calfee; Felipe Balbi;
 linux-...@vger.kernel.org; linux-
 o...@vger.kernel.org; linux-ker...@vger.kernel.org
 Subject: Re: [Regression?] Removed regulator support in ehci-omap

 On 04/12/2011 12:20 PM, Keshava Munegowda wrote:
 Ah, so EHCI/OHCI common code was moved into drivers/mfd... Good.
 But seems regulators support was lost somewhere during transition
 -
 the
 only mentioning about regulators in omap-usb-host.c is #include
 :

 mad@macmini:~/kernel-hack/linux-2.6(master)$ grep -i regulator
 drivers/mfd/omap-usb-host.c
 Thanks ! I will add some time next week!
 I have confirmed this on my BeagleBoard-xM. 2.6.38 works, but the
 2.6.39-rc4+ head from yesterday did not. It seems that the regulator
 does not turn the power on for the USB hub which the ethernet is
 attached to.

 I connected this issue to bug 33092 in bugzilla[1].

 Alan.

 [1] https://bugzilla.kernel.org/show_bug.cgi?id=33092
 I have posted the patches on April 22, 2011.
 If possible I request you to test this.

 Hi Keshava,

 If you mean this patch[1], then I tested it against the head and it
 didn't fix my problem. I couldn't convince myself that your patch was
 supposed to be the whole fix to my problem (since it wasn't mentioned
 on
 this thread) so I didn't reply with my findings. Sorry about that.

 Same here.  The real issue (at least for Overo) turned out to be:

 https://lkml.org/lkml/2011/4/14/45

 Steve
 
 But, I was not aware of the fix of the link:
 https://lkml.org/lkml/2011/4/14/45
 Sorry for this.
 Same fix works for beagle-XM and I have tested this.

I just tried your 3 patches on my beagleboardxm. It still fails to boot.
Maybe I have a different problem? Your fix did enable usb (at least it
found the hub and usbnet driver, but the smsc95xx driver may or may not
be working.

Here is my failed 2.6.39rc4 boot log. If I back up to 2.6.38 the kernel
does find the nfs server and starts.

Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.39-rc4+ (calfee@Gracie) (gcc version
4.5.2 (Bu1
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: OMAP3 Beagle Board
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3630 ES1.1 (l2cache iva sgx neon isp 192mhz_clk )
[0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
[0.00] Reprogramming SDRC clock to 33200 Hz
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pa8
[0.00] Kernel command line: console=tty0 console=ttyO2,115200n8
mpuratet
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[0.00] Memory: 512MB = 512MB total
[0.00] Memory: 508416k/508416k available, 15872k reserved, 0K
highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] DMA : 0xffc0 - 0xffe0   (   2 MB)
[0.00] vmalloc : 0xe080 - 0xf800   ( 376 MB)
[0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .init : 0xc0008000 - 0xc0031000   ( 164 kB)
[0.00]   .text : 0xc0031000 - 0xc0408638   (3934 kB)
[0.00]   .data : 0xc040a000 - 0xc05b6500   (1714 kB)
[0.00] NR_IRQS:410
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96
interrups
[0.00] Total of 96 interrupts on 1 active controller
[0.00] omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
[0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps
every 1s
[0.00] Console: colour dummy device 80x30
[0.00] console [tty0] enabled
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingr
[0.00] ... MAX_LOCKDEP_SUBCLASSES:  8
[0.00

Re: [Regression?] Removed regulator support in ehci-omap

2011-04-25 Thread Steve Calfee 
On 04/25/11 10:23, Steve Calfee wrote:
 On 04/25/11 09:41, Keshava Munegowda wrote:
 -Original Message-
 From: Steve Sakoman [mailto:sako...@gmail.com]
 Sent: Monday, April 25, 2011 7:46 PM
 To: Alan Ott
 Cc: Keshava Munegowda; Dmitry Artamonow; Steve Calfee; Felipe Balbi;
 linux-...@vger.kernel.org;
 linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org
 Subject: Re: [Regression?] Removed regulator support in ehci-omap

 On Mon, Apr 25, 2011 at 7:11 AM, Alan Ott a...@signal11.us wrote:
 On 04/24/2011 02:37 AM, Keshava Munegowda wrote:
 -Original Message-
 From: Alan Ott [mailto:a...@signal11.us]
 Sent: Friday, April 22, 2011 6:41 AM
 To: Keshava Munegowda
 Cc: Dmitry Artamonow; Steve Sakoman; Steve Calfee; Felipe Balbi;
 linux-...@vger.kernel.org; linux-
 o...@vger.kernel.org; linux-ker...@vger.kernel.org
 Subject: Re: [Regression?] Removed regulator support in ehci-omap

 On 04/12/2011 12:20 PM, Keshava Munegowda wrote:
 Ah, so EHCI/OHCI common code was moved into drivers/mfd... Good.
 But seems regulators support was lost somewhere during transition
 -
 the
 only mentioning about regulators in omap-usb-host.c is #include
 :

 mad@macmini:~/kernel-hack/linux-2.6(master)$ grep -i regulator
 drivers/mfd/omap-usb-host.c
 Thanks ! I will add some time next week!
 I have confirmed this on my BeagleBoard-xM. 2.6.38 works, but the
 2.6.39-rc4+ head from yesterday did not. It seems that the regulator
 does not turn the power on for the USB hub which the ethernet is
 attached to.

 I connected this issue to bug 33092 in bugzilla[1].

 Alan.

 [1] https://bugzilla.kernel.org/show_bug.cgi?id=33092
 I have posted the patches on April 22, 2011.
 If possible I request you to test this.

 Hi Keshava,

 If you mean this patch[1], then I tested it against the head and it
 didn't fix my problem. I couldn't convince myself that your patch was
 supposed to be the whole fix to my problem (since it wasn't mentioned
 on
 this thread) so I didn't reply with my findings. Sorry about that.

 Same here.  The real issue (at least for Overo) turned out to be:

 https://lkml.org/lkml/2011/4/14/45

 Steve

 But, I was not aware of the fix of the link:
 https://lkml.org/lkml/2011/4/14/45
 Sorry for this.
 Same fix works for beagle-XM and I have tested this.
 
 I just tried your 3 patches on my beagleboardxm. It still fails to boot.
 Maybe I have a different problem? Your fix did enable usb (at least it
 found the hub and usbnet driver, but the smsc95xx driver may or may not
 be working.
 
 Here is my failed 2.6.39rc4 boot log. If I back up to 2.6.38 the kernel
 does find the nfs server and starts.
 
snip
 [4.301788] mmc0: new high speed SDHC card at address 1234
 [4.310424] mmcblk0: mmc0:1234 SA04G 3.67 GiB
 [4.321441]  mmcblk0: p1 p2 p3
 [4.359619] usb 1-2.1: new high speed USB device number 3 using ehci-omap
 [4.485046] usb 1-2.1: New USB device found, idVendor=0424,
 idProduct=ec00
 [4.492309] usb 1-2.1: New USB device strings: Mfr=0, Product=0,
 SerialNumbe0
 [4.505432] smsc95xx v1.0.4
 [4.596130] smsc95xx 1-2.1:1.0: eth0: register 'smsc95xx' at
 usb-ehci-omap.0d
 [   16.620605] Root-NFS: no NFS server address
 [   16.625122] VFS: Unable to mount root fs via NFS, trying floppy.
 [   16.632354] List of all partitions:
 [   16.636230] b300 3858432 mmcblk0  driver: mmcblk
 [   16.641876]   b301 1020096 mmcblk0p1
 ----0001
 [   16.650634]   b302 1028160 mmcblk0p2
 ----0002
 [   16.659515]   b303 1807312 mmcblk0p3
 ----0003
 [   16.668243] No filesystem could mount root, tried:  nfs
 [   16.673767] Kernel panic - not syncing: VFS: Unable to mount root fs
 on unkn


Hi Keshava,

I rebuilt my system to boot from flash and now I see what happened. I
even remember it being discussed on this list. Someone renamed my usb
ethernet device from usb0 to eth0 !!! The boot log shows it on this line:

 [4.596130] smsc95xx 1-2.1:1.0: eth0: register 'smsc95xx' at
 usb-ehci-omap.0d


So this broke my init scripts and uboot script... OK, so I can live with
this (I hope the name doesn't change too often though).

So I can manually configure my system to use eth0 and use the network. I
am sure I will get nfs working shortly.

I am using the 2.6.39-rc4 with your 3 patches. So from the Beagleboard
XM perspective it works and you can include my

Tested-by: Steve Calfee stevecal...@gmail.com


--
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: [Regression?] Removed regulator support in ehci-omap

2011-04-11 Thread Steve Calfee 
On 04/11/11 02:32, Dmitry Artamonow wrote:
 Hi, guys!
 
 Can anyone explain why regulator support has been removed from ehci-omap
 driver in commit 19403165 (usb: host: omap: ehci and ohci 
 simplification)[1]?
 In 2.6.37/2.6.38 it was enough to apply simple patch[2] adding regulators
 description to board file to make USB work on omap3evm board (because USB PHY
 is powered via regulator). But now it won't work anymore in 2.6.39-rc2.
 BTW, I suspect that this commit also broke USB on omap3pandora board, as it
 defines hsusb0 regulator supply in its board file:
 
Yes, And Beagleboard xm (and I suspect other beagleboard versions) has
been broken in 2.6.39rc1+.

Regards, Steve
--
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