Hi,
On 7 January 2015 at 02:22, Masahiro Yamada <yamad...@jp.panasonic.com> wrote:
>
> On Tue, 6 Jan 2015 22:33:02 -0700
> Simon Glass <s...@chromium.org> wrote:
>
>> Hi Peng,
>>
>> On 6 January 2015 at 20:06, Peng Fan <b51...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
