Hi,
On 7 January 2015 at 02:22, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
On Tue, 6 Jan 2015 22:33:02 -0700 Simon Glass sjg@chromium.org wrote:
Hi Peng,
On 6 January 2015 at 20:06, Peng Fan B51431@freescale.com wrote:
Hi Simon,
I am hacking DTB and DM SPI FLASH support for i.MX 6SoloX. I have a question about `sf probe`. In original way, `sf probe` or `sf probe 0:0` can detect qspi flashes on my platform. But after using DM, I should use `sf probe 35536896:0` to probe flashes. 35536896 is the address of QSPI controller's reg base 0x021e4000 in hex format. Does I miss something in my driver? It seems dev->seq is not valid so should pass req_seq which is the address of qspi controller in dts file.
Any ideas?
You can use:
aliases { spi0 = "/spi@xxxx"; }
to correct the sequence number.
It would be better if we had a way to indicate a bus where reg provides the sequence number, so we know when it doesn't. I haven't come up with a good idea on that yet.
My device tree source is growing its aliases node...
arch/arm/dts/uniphier-ph1-pro4-ref.dts
aliases { serial0 = &uart0; serial1 = &uart1; serial2 = &uart2; serial3 = &uart3; i2c0 = &i2c0; i2c1 = &i2c1; i2c2 = &i2c2; i2c3 = &i2c3; i2c5 = &i2c5; i2c6 = &i2c6; };
This is good. It makes it very clear in one place which port is which.
But I am going to propose dropping the 'reg' support for sequence numbers in driver model. With I2C and SPI doing there own thing, we don't use it. And it just creates problems - e.g. if reg is actually an address we end up with a very strange sequence number on various devices.
Regards, Simon