On 30 September 2014 20:28, David Müller (ELSOFT AG)
<d.muel...@elsoft.ch> wrote:
> Jagan Teki wrote:
>> On 30 September 2014 18:41, David Müller (ELSOFT AG)
>> <d.muel...@elsoft.ch> wrote:
>>> Jagan Teki wrote:
>>>> On 30 September 2014 16:53, David Müller <d.muel...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
