[linux-sunxi] Re: [PATCH 3/6] sunxi: SPL SPI: Introduce is_new_gen_spi()

2020-01-26 Thread André Przywara
On 21/01/2020 08:20, Jagan Teki wrote:

Hi Jagan,

first: many thanks for merging those other patches of mine, much
appreciated!

> On Mon, Jan 6, 2020 at 6:59 AM Andre Przywara  wrote:
>>
>> So far we were using the CONFIG_SUNXI_GEN_SUN6I symbol to select between
>> the two SPI controller generations used on Allwinner SoCs. This is a
>> convenience symbol to roughly differentiate between "older" and "newer"
>> generation of SoCs.
>>
>> The H6 SoCs is the newest SoC so far, but is sufficiently different to
>> not define this symbol. However it is using a SPI controller compatible
>> to the "new gen" SoCs.
>>
>> To prepare for H6 support, we replace the check for this single symbol
>> with an explicit function, which can later be extended.
>> For now we just return CONFIG_SUNXI_GEN_SUN6I in there, so this does not
>> create a functional change.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  arch/arm/mach-sunxi/spl_spi_sunxi.c | 22 ++
>>  1 file changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c 
>> b/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> index 5b4598a25b..b19f1bf4af 100644
>> --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> @@ -100,9 +100,14 @@ static void spi0_pinmux_setup(unsigned int pin_function)
>> sunxi_gpio_set_cfgpin(SUNXI_GPC(3), pin_function);
>>  }
>>
>> +static bool is_new_gen_spi(void)
>> +{
>> +   return IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I);
>> +}
> 
> Doesn't it confusing? new gen is H6, but it returns 6I?

Well, naming ...
For the purpose of U-Boot there are two generations of SPI controller
*register interfaces*, the "old" one used in the older SoCs like the
A20, and the "newer" one used in everything halfway recent. The H6 uses
the same "new" generation, just at a different address. Yes, it adds
quad-SPI, but this is not relevant for this driver.
I have seen this old/new terminology at different places, so just went
with it.
I could rename it to is_spi_sun6i_gen() or something if that makes you
happy...

Cheers,
Andre

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/915f8cff-5639-224d-5c27-6f8b617b1f9e%40arm.com.


[linux-sunxi] Re: [PATCH 0/2] sunxi: Support automated booting from 128KB

2020-01-26 Thread Jagan Teki
On Fri, Jan 10, 2020 at 7:17 AM Andre Przywara  wrote:
>
> The Allwinner Boot ROM on all later SoCs can load the initial SPL code
> from offset 128KB or from offset 8KB of an SD card or eMMC.
> We support this in the SPL for a while now, but so far needed to manually
> adjust the U-Boot image MMC load sector during compile time.
>
> Since the Boot ROM writes a different boot source ID into the SRAM when
> loaded from the higher offset, we can check this value and dynamically
> adjust the raw MMC load sector for the U-Boot proper image.
>
> This allows to generate *one* image file, which can be written to either
> offset 8KB or to offset 128KB. The latter has the advantange of not
> overlapping with a standard GPT partition table.
>
> Tested on Bananapi M2 Berry (R40), Orangepi Zero (H2+), Orangepi PC 2 (H5),
> Pine64-LTS (A64), Bananapi-M64 (A64, both SD card and eMMC) and
> Pine H64 (H6), on all boards writing the same image to both 8K and 128K.
>
> Cheers,
> Andre.
>
> Andre Przywara (2):
>   sunxi: SPL: Factor out sunxi_get_boot_source()
>   sunxi: Automate loading from 128KB MMC offset

Applied to u-boot-sunxi/master

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZDcoOMdn%3D%2BQyfuRw_HdU7sJYBuK0SR7BQuss8eAhcTi-g%40mail.gmail.com.