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  wrote:
> "Cousson, Benoit"  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.
>>>

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

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  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/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: 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  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-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  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: 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: [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: [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

Re: beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-13 Thread Steve Calfee 
On Thu, May 12, 2011 at 10:59 PM, Peter Ujfalusi  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

beagleboardxm 2.6.39rc4 mcbsp problems.

2011-05-11 Thread Steve Calfee 
On 05/11/11 11:16, Steve Calfee wrote:
New title, more appropriate to the topic.

I was replying to the fix posted by Sanjeev fixing
a/sound/soc/omap/omap-mcbsp.c

I am pretty near the cutting edge kernel, trying to use the latest alsa
changes. I cannot get bbxm to talk to an external codec via mcbsp1.

Has anyone been able to use mcbsp1 on a recent linux-next.

More below.

> 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?
> 
Sanjeev pointed me to:
 Check this page to find the differences:
http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide

Where it appears TI has some new chip naming scheme and maybe the bbxm
is a am3730? In any case it doesn't seem that mcbsp is affected by the
package change.

> 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

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 
> cc: Mark Brown 
> cc: Liam Girdwood 
> cc: Jarkko Nikula 
> ---
> 
>  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
[ 1566.148681] snd_pcm_lib_write1: state 3 siz

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 

--
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 Tue, Apr 26, 2011 at 2:04 AM, Felipe Balbi  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 
>> > >
>> > > 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 
>> >
>> > 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 
>
> 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 
--
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 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  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.
> 

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


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

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