[U-Boot] [U-Boot:RESEND][[PATCH 6/7] k2hk: add support for k2hk SOC and EVM

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/10/2014 08:44 PM, Vitaly Andrianov wrote:
> On 02/10/2014 04:25 PM, Tom Rini wrote:
>> On Fri, Feb 07, 2014 at 06:23:13PM -0500, Murali Karicheri wrote:
>>
>>> k2hk EVM is based on Texas Instruments Keystone2 Hawking/Kepler
>>> SoC. Keystone2 SoC has ARM v7 Cortex-A15 MPCore processor. Please
>>> refer the ti/k2hk_evm/README for details on the board, build and other
>>> information.
[snip]
>>> +#ifdef CONFIG_SOC_K2HK
>>> +#define ASYNC_EMIF_BASE            K2HK_ASYNC_EMIF_CNTRL_BASE
>>> +#endif
>> So, does Keystone 1 have this in a different location?
> That is not for Keystone1. K2HK is for Hawking and Kepler SoC.
> The ASYNC_EMIF_BASE may be different for other SOC of the Keystone2 family.

That seems pretty unlikely, unless you've seen actual plans to the
contrary, so lets assume the base won't change for this family at least.

>>> +#define ASYNC_EMIF_CONFIG(cs)        (ASYNC_EMIF_BASE+0x10+(cs)*4)
>>> +#define ASYNC_EMIF_ONENAND_CONTROL    (ASYNC_EMIF_BASE+0x5c)
>>> +#define ASYNC_EMIF_NAND_CONTROL        (ASYNC_EMIF_BASE+0x60)
>>> +#define ASYNC_EMIF_WAITCYCLE_CONFIG    (ASYNC_EMIF_BASE+0x4)
>> Register access is done over structs not define of base + offset, please
>> rework.
> This style was taken form Davinci code. Shall we rework it?

Yes.

[snip]
>>> +++ b/arch/arm/cpu/armv7/keystone/clock.c
>> [snip]
>>> +static void pll_delay(unsigned int loop_count)
>>> +{
>>> +    while (loop_count--)
>>> +        asm("   NOP");
>>> +}
>> If we cannot use udelay yet use sdelay.
>>
>>> +#include "clock-k2hk.c"
>> Please use function prototypes, header files and then build the right
>> SoC clock file itself.
> The idea was to have common clock.h for all Keystone2 family and include
> in to
> it a specific for each SoC include file. Are you asking to remove that
> specific include
> from the clock.h?

I'm saying we can't include a c file from another c file.  See
arch/arm/cpu/armv7/am33xx/ (and asm/arch-am33xx/) for how we support
different clocks in similar-but-different families.

[snip]
>>> diff --git a/arch/arm/cpu/armv7/keystone/ddr3.c
>>> b/arch/arm/cpu/armv7/keystone/ddr3.c
>>> new file mode 100644
>>> index 0000000..4875db7
>>> --- /dev/null
>>> +++ b/arch/arm/cpu/armv7/keystone/ddr3.c
>> Part of me wonders just how close/far this is from the omap-common
>> EMIF/DDR code.  Some parts look pretty familiar (and makes me wonder if
>> you don't have some corner-case bugs around not setting shadow registers
>> and initially setting some of the values to max, then setting them
>> optimally due to which bits cause a refresh cycle).
> This code is based on AVV test code and is very specific to SOC DDR3
> controller,
> which as I know is different from OMAP.

I'm not going to push this too hard since I don't have all the low level
knowledge (nor contacts) about just how the block was re-used, but it's
not 100% different from the rest of the EMIF parts TI uses.  We should
revisit this later (and once I've got the right docs for keystone parts
around).

[snip]
>>> +++ b/drivers/i2c/keystone_i2c.c
>>> @@ -0,0 +1,372 @@
>>> +/*
>>> + * TI Keystone i2c driver
>>> + * Based on TI DaVinci (TMS320DM644x) I2C driver.
>> And how different is it really?  Can we not reuse the davinci driver?
>>
> It is reworked a little bit and also supports multiple ports, while
> davinci driver supports only one.

Right, so lets enhance the existing driver.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS+27JAAoJENk4IS6UOR1W/FAP/iUgQQf7q1NiGMwF4HfJqeZe
PsrO3ElN3TPPrnFQ5PgqXk3t8RSAFy7EVIetLjs8ZSh+JZvH48/YH9RCVm0err/I
LQVeQbklHNiV5kNtxMWQlwGmG/ySG3S7DiZ9wS2GyTbrJV0v4Zl9P6qjdxyc5vAl
O6aWDHv7IvqG5GXY8tSsptb8oN6H71foniufSLref5qQWeDxJtXpS31f0g0R9h4e
r76o7eQ4iNpUoCu5eKz4XzOUEV9ve1zQP1Iv5d2JGxV0FXkSyZ32STAkkdf6zglP
vnrK+dzk7B67hc1EQb2V0y3oY3yEmY+Z3aXkf3ws+5BY7R7SfZ8WfLxg1i7NJBZs
CFwFPVV91A05Tq4yRMnniCs6mOCpG08IwyxEz5SmEoG52H/onNHd1HnYhBEiuwRI
ENKm7IxdYFuWBVSd+FLaU6IQQdL8WnzL9YVkBuYdA+hPEAbcPVEWGFTVGo9fJP9r
SoWXzI8ue+fUiJxvVJdcwJ8AJrq7Ci4FBFjMDtxe+8e9wgUp0ZVeFPOW6kEml7I2
O8HkgtMB0MdMDdESB9m/neFs0E3Va7EX3tlVPAcfqlQjjkFS0v9OmlGZG23bs9HP
emejngR267JKcmJjuimf12IhIRWc62QtJBPXx+8WmEUy53CjkFhUfD7EKEzHT/52
CKaOAhmNc1EZAZkZcaBv
=anbB
-----END PGP SIGNATURE-----