[U-Boot] [PATCH] PATI: fix broken SPI access

Jagan Teki jagannadh.teki at gmail.com
Tue Sep 30 18:08:33 CEST 2014


On 30 September 2014 20:28, David Müller (ELSOFT AG)
<d.mueller at elsoft.ch> wrote:
> Jagan Teki wrote:
>> On 30 September 2014 18:41, David Müller (ELSOFT AG)
>> <d.mueller at elsoft.ch> wrote:
>>> Jagan Teki wrote:
>>>> On 30 September 2014 16:53, David Müller <d.mueller at elsoft.ch> wrote:
>>>>> +int board_early_init_f(void)
>>>>> +{
>>>>> +       spi_init_f();
>>>>
>>>> Why you need to do this, spi_init_f is trying to call from
>>>> arch/powerpc/lib/board.c
>>>> any specific reason, I couldn't understand the fix you mentioned on
>>>> the commit body.
>>>
>>> There is an EEPROM attached to the SPI channel containing vital board
>>> data. Calling spi_init_f() from arch/powerpc/lib/board.c will be too late.
>>
>> Sorry, this looks an other issue - but anyway we're trying to remove
>
> What kind of "other issue" do you mean?
>
>> spi_init* stuff
>> from drivers/spi/* in future and I don't think it's a good idea to use that.
>
> In this case what is the proposed way of initializing the SPI subsystem?
>

Usually spi got initialized through setup_slave() from the cmd
interface which is of
dynamic probe ie the reason most of drivers have spi_init() with no
functionality code.

On the other hand few are using spi_init() or spi_init_f() from arch
code or from
any other kind to initialize the spi.

Finally spi_init_f() from your case should use from arch(at least) as
this call is more generic
and it shouldn't be a call from board.

And more over we're working on dm-spi where spi_init() calls stuff
would disappear in future.

thanks!
-- 
Jagan.


More information about the U-Boot mailing list