RE: Using McBSP in kernel...

RE: Using McBSP in kernel...

[Khasim, Syed]

Hi

There are some app notes on TI site, I found one here
http://focus.ti.com/lit/an/spra487c/spra487c.pdf

Try to compare your values with this example.

McBSP registers are 16bit, Some times reading them as 32bit will result
in 0s. I don't know if this is the exact issue you are facing when
reading from application space. Make sure you do a 16bit read of every
register.

The FSX line will be used as Chip Select for SPI operations, So, while
doing initial mux settings, you put the line as pulled up. If you are
using a CRO to probe the signals, then probing this line should show
high. 

When you configure your SPI for a low Chip select polarity and then
write to a DXR register, the FSX / CS line should go low. This will
confirm if all your register settings clock and mux settings.

Regards,
Khasim


-----Original Message-----
From: linux-omap-open-source-bounces@linux.omap.com
[mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
Matthew Percival
Sent: Thursday, July 20, 2006 1:54 AM
To: Linux OMAP Open Source
Subject: RE: Using McBSP in kernel...

G'Day,

	Thanks for the reply.

> Configuration seems to fine, did you check pin muxing?

	Aye, MUX settings are correct according to the manual.  The
clock
(ARM_PER, according to the manual) is also on (I checked
both /proc/omap_clocks and the ARM_IDLCT2 register).  I have also
observed that, for whatever reason, I can read/write the registers
perfectly fine in kernel, but they always seem to return 0x0 when I try
to read from user space (using devmem2).  I am not sure if that is
relevant or not, but it seemed odd.

> Also, note that clock will be generated only when there is data on the
> bus. Otherwise the line will be simply high. If CS line is configured
as
> active low, then you might not even see the CS line changing its
> transition. Try to put CS line as high during initialization and then
do
> a write, it should drop to low.

	I am not sure what you mean by configuring the CS line.  Could
you give
a reference for this?  If you are referring to the Frame Sync./Slave
Enable, that is configured to active low, but I am not sure how to
configure it to be high during initialisation.

	-- Matthew

_______________________________________________
Linux-omap-open-source mailing list
Linux-omap-open-source@linux.omap.com
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

RE: Using McBSP in kernel...

[Matthew Percival]

G'Day,

	I am still unsuccessful at using McBSP2 as an SPI Master in a kernel
driver.  I have confirmed that the mux settings are correct, and have
attempted using a pull up (though have noted no change).

	An interesting occurrence I have observed in my testing is that if I
test that XRDY is set, indicating that I can load DXR2/1, load the
transmit registers, then check again, XRDY is still set afterwards, and
both registers still reflect the values I put in them earlier.  Clearly
the module is not attempting to transmit, which would explain why I see
nothing with the CRO.

	Looking over the diagrams in spru762, I came across something
interesting.  I understand that, for an SPI Master, FSXM should be set
to 1, yet Figure 4 suggests that MCBSP2.FSX will only come out if FSXM
is set to 0.  Am I mistaken in this, is the diagram wrong, or perhaps is
McBSP2 unsuitable for use as a SPI Master (or at least in the way I have
configured it)?

	Thanks,

	Matthew

PS I shall include a current register dump, in case this is of use:
		DRR2:  0x0000
		DRR1:  0x0000
		DXR2:  0x0000
		DXR1:  0x0000
		SPCR2: 0x00C3
		SPCR1: 0x1001
		RCR2:  0x0001
		RCR1:  0x00A0
		XCR2:  0x0001
		XCR1:  0x00A0
		SRGR2: 0x2000
		SRGR1: 0x1F00
		PCR0:  0x0A0B

Re: Using McBSP in kernel...

[Mark Howell]

Matthew, I have a working driver that uses McBSP2 to talk to an SPI 
slave on my H2 (1611) dev board. It does *not* use the McBSP SPI driver 
in the kernel, but rather goes straight to the McBSP registers. If this 
would be handy to play with or refer to, I can e it to you off-list.

Cheers,

Mark.

Matthew Percival wrote:
> G'Day,
> 
> 	I am still unsuccessful at using McBSP2 as an SPI Master in a kernel
> driver.  I have confirmed that the mux settings are correct, and have
> attempted using a pull up (though have noted no change).
> 
> 	An interesting occurrence I have observed in my testing is that if I
> test that XRDY is set, indicating that I can load DXR2/1, load the
> transmit registers, then check again, XRDY is still set afterwards, and
> both registers still reflect the values I put in them earlier.  Clearly
> the module is not attempting to transmit, which would explain why I see
> nothing with the CRO.
> 
> 	Looking over the diagrams in spru762, I came across something
> interesting.  I understand that, for an SPI Master, FSXM should be set
> to 1, yet Figure 4 suggests that MCBSP2.FSX will only come out if FSXM
> is set to 0.  Am I mistaken in this, is the diagram wrong, or perhaps is
> McBSP2 unsuitable for use as a SPI Master (or at least in the way I have
> configured it)?
> 
> 	Thanks,
> 
> 	Matthew
> 
> PS I shall include a current register dump, in case this is of use:
> 		DRR2:  0x0000
> 		DRR1:  0x0000
> 		DXR2:  0x0000
> 		DXR1:  0x0000
> 		SPCR2: 0x00C3
> 		SPCR1: 0x1001
> 		RCR2:  0x0001
> 		RCR1:  0x00A0
> 		XCR2:  0x0001
> 		XCR1:  0x00A0
> 		SRGR2: 0x2000
> 		SRGR1: 0x1F00
> 		PCR0:  0x0A0B
> 
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> 
> 
> 

RE: Using McBSP in kernel...

[Khasim, Syed]

Hi,

Configuration seems to fine, did you check pin muxing?

Also, note that clock will be generated only when there is data on the
bus. Otherwise the line will be simply high. If CS line is configured as
active low, then you might not even see the CS line changing its
transition. Try to put CS line as high during initialization and then do
a write, it should drop to low. See if the clock is turned on (for
McBSP2) by reading the proc file for clk (I believe this exits).

Regards,
Khasim

-----Original Message-----
From: linux-omap-open-source-bounces@linux.omap.com
[mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
Matthew Percival
Sent: Wednesday, July 19, 2006 1:56 AM
To: Linux OMAP Open Source
Subject: Using McBSP in kernel...

G'Day,

	I have been trying to write a driver that makes use of McBSP2 in
SPI
mode recently, but seem to have missed a step or something along the
way.  The following code is included in my drivers __init block:

	struct omap_mcbsp_spi_cfg mcbsp2_spi_conf;

	if (omap_mcbsp_request(OMAP_MCBSP2))
		return -EBUSY;
	omap_mcbsp_stop(OMAP_MCBSP2);

	mcbsp2_spi_conf.spi_mode = OMAP_MCBSP_SPI_MASTER;
	mcbsp2_spi_conf.rx_clock_polarity = OMAP_MCBSP_CLK_RISING;
	mcbsp2_spi_conf.tx_clock_polarity = OMAP_MCBSP_CLK_FALLING;
	mcbsp2_spi_conf.fsx_polarity = OMAP_MCBSP_FS_ACTIVE_LOW;
	mcbsp2_spi_conf.clk_div = 1;
	mcbsp2_spi_conf.clk_stp_mode = OMAP_MCBSP_CLK_STP_MODE_NO_DELAY;
	mcbsp2_spi_conf.word_length = OMAP_MCBSP_WORD_32;
	omap_mcbsp_set_spi_mode(OMAP_MCBSP2, &mcbsp2_spi_conf);

	Then, on open(), I make the following call:

	omap_mcbsp_start(OMAP_MCBSP2);

	On certain events, I also call the following:

	omap_mcbsp_spi_master_recv_word_poll(OMAP_MCBSP2, (u32 *)data)
	omap_mcbsp_spi_master_xmit_word_poll(OMAP_MCBSP2, config);

	When I call these, I would expect to see activity on the McBSP2
pins,
but do not see anything on McBSP2.DX, McBSP2.CLKX or McBSP2.FSX.  I have
verified that I am able to write to the registers, so the module should
be configured correctly.  Is there some kind of an additional operation
I need to perform at some point when making use of the functions already
available in kernel?

	A register dump performed after calling omap_mcbsp_start()
returns the
following:
		DRR2:  0x0000
		DRR1:  0x0000
		DXR2:  0x0000
		DXR1:  0x0000
		SPCR2: 0x00c3
		SPCR1: 0x1001
		RCR2:  0x0001
		RCR1:  0x00a0
		XCR2:  0x0001
		XCR1:  0x00a0
		SRGR2: 0x2000
		SRGR1: 0x0000
		PCR0:  0x0a0b
These look about right to me, leaving me at a loss to what could be
wrong.  My initial suspicion was that this were simply a clock issue,
but since McBSP2 only uses ARM_PER, that seems improbable.

	-- Matthew

_______________________________________________
Linux-omap-open-source mailing list
Linux-omap-open-source@linux.omap.com
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

RE: Using McBSP in kernel...

[Matthew Percival]

G'Day,

	Thanks for the reply.

> Configuration seems to fine, did you check pin muxing?

	Aye, MUX settings are correct according to the manual.  The clock
(ARM_PER, according to the manual) is also on (I checked
both /proc/omap_clocks and the ARM_IDLCT2 register).  I have also
observed that, for whatever reason, I can read/write the registers
perfectly fine in kernel, but they always seem to return 0x0 when I try
to read from user space (using devmem2).  I am not sure if that is
relevant or not, but it seemed odd.

> Also, note that clock will be generated only when there is data on the
> bus. Otherwise the line will be simply high. If CS line is configured as
> active low, then you might not even see the CS line changing its
> transition. Try to put CS line as high during initialization and then do
> a write, it should drop to low.

	I am not sure what you mean by configuring the CS line.  Could you give
a reference for this?  If you are referring to the Frame Sync./Slave
Enable, that is configured to active low, but I am not sure how to
configure it to be high during initialisation.

	-- Matthew

Using McBSP in kernel...

[Matthew Percival]

G'Day,

	I have been trying to write a driver that makes use of McBSP2 in SPI
mode recently, but seem to have missed a step or something along the
way.  The following code is included in my drivers __init block:

	struct omap_mcbsp_spi_cfg mcbsp2_spi_conf;

	if (omap_mcbsp_request(OMAP_MCBSP2))
		return -EBUSY;
	omap_mcbsp_stop(OMAP_MCBSP2);

	mcbsp2_spi_conf.spi_mode = OMAP_MCBSP_SPI_MASTER;
	mcbsp2_spi_conf.rx_clock_polarity = OMAP_MCBSP_CLK_RISING;
	mcbsp2_spi_conf.tx_clock_polarity = OMAP_MCBSP_CLK_FALLING;
	mcbsp2_spi_conf.fsx_polarity = OMAP_MCBSP_FS_ACTIVE_LOW;
	mcbsp2_spi_conf.clk_div = 1;
	mcbsp2_spi_conf.clk_stp_mode = OMAP_MCBSP_CLK_STP_MODE_NO_DELAY;
	mcbsp2_spi_conf.word_length = OMAP_MCBSP_WORD_32;
	omap_mcbsp_set_spi_mode(OMAP_MCBSP2, &mcbsp2_spi_conf);

	Then, on open(), I make the following call:

	omap_mcbsp_start(OMAP_MCBSP2);

	On certain events, I also call the following:

	omap_mcbsp_spi_master_recv_word_poll(OMAP_MCBSP2, (u32 *)data)
	omap_mcbsp_spi_master_xmit_word_poll(OMAP_MCBSP2, config);

	When I call these, I would expect to see activity on the McBSP2 pins,
but do not see anything on McBSP2.DX, McBSP2.CLKX or McBSP2.FSX.  I have
verified that I am able to write to the registers, so the module should
be configured correctly.  Is there some kind of an additional operation
I need to perform at some point when making use of the functions already
available in kernel?

	A register dump performed after calling omap_mcbsp_start() returns the
following:
		DRR2:  0x0000
		DRR1:  0x0000
		DXR2:  0x0000
		DXR1:  0x0000
		SPCR2: 0x00c3
		SPCR1: 0x1001
		RCR2:  0x0001
		RCR1:  0x00a0
		XCR2:  0x0001
		XCR1:  0x00a0
		SRGR2: 0x2000
		SRGR1: 0x0000
		PCR0:  0x0a0b
These look about right to me, leaving me at a loss to what could be
wrong.  My initial suspicion was that this were simply a clock issue,
but since McBSP2 only uses ARM_PER, that seems improbable.

	-- Matthew