Problem with multiple SPI devices

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a custom board (99% based on the NGW100) but with 2 devices (rtc and eeprom) hung off the spi 0 bus.

I'm using the Atmel buildroot 2.1.0 distro.

I have written (i.e. modified existing max6902 driver) a driver to create a new driver for the rtc (DS1390). I have the following in my board setup.c file.

static struct spi_board_info spi0_board_info[] __initdata = {
	{
		.modalias	= "rtc-ds1390",
		.max_speed_hz	= 4000000,
		.chip_select	= 2,
	},
};

...

	at32_add_device_spi(0, spi0_board_info, ARRAY_SIZE(spi0_board_info));

This all works fine (i.e. I can read / set the time / date in the rtc device using hwclock).

I now want to add the eeprom (Microchip 25LC010). This should be covered by the at25 driver, so I have changed my setup.c file ...

static struct spi_eeprom eeprom_25lc010 = {
		.name = "25lc010",
		.byte_len = 128,
		.page_size = 16,
		.flags = EE_ADDR1,
};

static struct spi_board_info spi0_board_info[] __initdata = {
	{
		.modalias	= "rtc-ds1390",
		.max_speed_hz	= 4000000,
		.chip_select	= 2,
	},
	{
		.modalias	= "at25",
		.max_speed_hz	= 1000000,
		.chip_select	= 1,
		.platform_data	= &eeprom_25lc010, 
	},
};

...

	at32_add_device_spi(0, spi0_board_info, ARRAY_SIZE(spi0_board_info));

But the at25 driver does not see the eeprom. Looking at the at25 driver, I can see that the driver tries to "ping" the eeprom by reading the status register.

Using a scope, I can see the /CS and MOSI lines being driven okay, but the MISO line remains inactive.

Have I added the SPI devices correctly ?

Does the SPI driver work okay with 2 devices ?

Any other thoughts ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to answer my own question, but I've fixed the problem.

I've added a dummy read before the "ping" code ...

	sr = spi_w8r8(spi, AT25_RDSR);	// dummy read
	sr = spi_w8r8(spi, AT25_RDSR);
	if (sr < 0 || sr & AT25_SR_nRDY) {
		dev_dbg(&spi->dev, "rdsr --> %d (%02x)\n", sr, sr);
		err = -ENXIO;
		goto fail;
	}

The first read always appeared to return 0xff, but subsequent reads were all okay.

Weird !!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this behavior guaranteed by the Microchip 25LC010? You might submit a patch for the at25 driver then...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm ... I couldn't say if this is normal behaviour or not.

I'm certainly not a device driver expert, but this fix works for me, so I'll keep it locally.

I've lots of patches for our custom board, but not sure how to submit them upstream ???

At the moment, I'm working entirely off our local cvs server, with the original based on the NGW100 from the Atmel 2.1.0 buildroot tarball.

What's the best way to proceed ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check the specs, compare them to Atmel's similar device. If this is something the chip says it will always do, then see Documentation/SubmittingPatches for more info.