On 12/09/2016 03:29 AM, Marek Vasut wrote:
> On 12/08/2016 05:36 PM, Cédric Le Goater wrote:
>> Hello Marek,
>
> Hi!
Hello Hello,
[...]
>>>> + /*
>>>> + * Read the existing control register to get basic values.
>>>> + *
>>>> + * XXX This register probably needs more sanitation.
>>>
>>> What's this comment about ?
>>
>> This is an initial comment about settings being done by U-Boot
>> before the kernel is loaded, and some optimisations should be
>> nice to keep, for the FMC controller. I will rephrase.
>
> Shouldn't that be passed via DT instead ? We want to be bootloader
> agnostic in Linux.
Yes, clearly, Linux should do its own timing calibration and not depend
on the bootloader but I am not sure how to do that correctly, yet, in
the driver for all controllers. It depends on the controller type and
a lot on the flash model being used, which can vary for the same board.
U-Boot uses specific registers of the FMC controller to evaluate the
best SPI clock frequency. So, for the moment, keeping the previous
setting for :
bits [11:8] SPI clock frequency selection
is a nice thing to have. we can replace this setting when calibration
is handled from Linux.
The SPI controllers are different, they don't have the specific registers
for calibration, and so the algo is bit more painful.
> btw off-topic, but is U-Boot support for these aspeed devices ever
> be upstreamed ?
It is the plan to.
This year, we have spent quite sometime porting, fixing, cleaning
up the original code and getting ready to send a minimal framework,
cpu and console, to mainline (flash and net drivers can come later).
The code is operational on various boards but there is a major task
we have not completed yet, which is to rewrite the 2/3 KLOC of
assembly doing the DDR initialization :/ Once this is done, we
should send.
Here is the tree we use on OpenBMC :
https://github.com/openbmc/u-boot/commits/v2016.07-aspeed-openbmc
and a more recent branch with some extra cleanups :
https://github.com/legoater/u-boot/commits/v2016.11-aspeed-openbmc
Thanks,
C.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
