Patchwork [U-Boot,v2] OMAP5: I2C: Enable i2c5 clocks

login
register
mail settings
Submitter Lubomir Popov
Date April 4, 2013, 3:52 p.m.
Message ID <515DA1A7.4070007@mm-sol.com>
Download mbox | patch
Permalink /patch/233868/
State Superseded
Delegated to: Tom Rini
Headers show

Comments

Lubomir Popov - April 4, 2013, 3:52 p.m.
V2 fixes line wrap issue of the patch itself.

I2C5 is used on all known OMAP5 hardware platforms, therefore enable.

Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>

---
 arch/arm/cpu/armv7/omap5/hw_data.c |    1 +
 1 file changed, 1 insertion(+)
SRICHARAN R - April 8, 2013, 6:09 a.m.
On Thursday 04 April 2013 09:22 PM, Lubomir Popov wrote:
> V2 fixes line wrap issue of the patch itself.
> 
> I2C5 is used on all known OMAP5 hardware platforms, therefore enable.
> 
> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
> 
> ---
>  arch/arm/cpu/armv7/omap5/hw_data.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c
> index e5e41fd..5698876 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void)
>  		(*prcm)->cm_l4per_i2c2_clkctrl,
>  		(*prcm)->cm_l4per_i2c3_clkctrl,
>  		(*prcm)->cm_l4per_i2c4_clkctrl,
> +		(*prcm)->cm_l4per_i2c5_clkctrl,

This is fine.
Can you also mention what device is connected on them ? and
how you are using it ?

Also can you add these in a series.

Regards,
 Sricharan
Lubomir Popov - April 8, 2013, 9:35 a.m.
Hi Sricharan,

On 08/04/13 09:09, Sricharan R wrote:
> On Thursday 04 April 2013 09:22 PM, Lubomir Popov wrote:
>> V2 fixes line wrap issue of the patch itself.
>>
>> I2C5 is used on all known OMAP5 hardware platforms, therefore enable.
>>
>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
>>
>> ---
>>  arch/arm/cpu/armv7/omap5/hw_data.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c
>> index e5e41fd..5698876 100644
>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>> @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void)
>>  		(*prcm)->cm_l4per_i2c2_clkctrl,
>>  		(*prcm)->cm_l4per_i2c3_clkctrl,
>>  		(*prcm)->cm_l4per_i2c4_clkctrl,
>> +		(*prcm)->cm_l4per_i2c5_clkctrl,
> 
> This is fine.
> Can you also mention what device is connected on them ? and
> how you are using it ?
> 
> Also can you add these in a series.
> 
> Regards,
>  Sricharan
> 

On our board we have an I/O expander on I2C5 - the same chip that is used on
the TI sEVM (the handset) and uEVM (the PandaBoard5) platforms (on both of
which it is also connected to I2C5). Therefore it seems reasonable to have
I2C5 enabled in the mainline. This requires that the base address is defined,
and that I2C_BUS_MAX is set to 5 (please see related patches).

I shall do make a new series on I2C5 support.

One more thing I would like to clarify to myself: in your patch series of
Apr. 1 you rename the omap5_evm to omap5_uevm. On the other hand, uEVM was
the TI-internal name for the PandaBoard5, and the evm was known as sEVM.
Doesn't this cause confusion? After all, these are two quite different
hardware platforms.

Thanks and regards,
Lubomir
Tom Rini - April 8, 2013, 12:34 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/08/2013 05:35 AM, Lubomir Popov wrote:

> One more thing I would like to clarify to myself: in your patch
> series of Apr. 1 you rename the omap5_evm to omap5_uevm. On the
> other hand, uEVM was the TI-internal name for the PandaBoard5, and
> the evm was known as sEVM. Doesn't this cause confusion? After all,
> these are two quite different hardware platforms.

Moving forward, there is only uEVM and sEVM doesn't exist.

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

iQIcBAEBAgAGBQJRYrlgAAoJENk4IS6UOR1WkBoP/iIMkPldiFmQRmDRCiuvoprd
0qq7Cak8Y1XF1YYwGARXW4Hup/Tvz6UpPxJx5oa5ESTIm0Km3CcBHw+0j3OuLYm5
K3XnXQ0Y+WHBf0V5uZJMMN7PqeoIV/R1SaKKp3421jPuaP9suBiihfKGP5Z78jl7
gXM14711xk4UgGitZc4ER73G6mlwOQyFABGONxyoAOhDuVN2BuPcx69OYUINKDrw
h9iW6JTtVwe+5JVIMPDYqUZJALgbeKsjMBOHjsFMahHlVGHDJ+SAKZ4IWnfKi8tY
J5Wi6PeeSqqokhL+dcMRWDRq5A7ufU9beRkFdmuWJRkFNhc7Jpqd/8kxctGbgf3t
NkI7UrbCTilTJnvv9/oEu+MVx6bBOXfD2uOy5m6kaOqZG+XFN1KsGJGs/PsevklL
zmwxYfDNSJl0DReMK8Wc7zFKN+vbpRDkcFGkG3yJAfTkWWm+fNfhygM/+aFNvT1K
NQivqSf546MbOU4CWWkhaF6pSivObT7br9yHP17QLLJnR2uWINzKu9kk2fcRRltJ
Q+jdQ6XLUDJ/7H22GhtrWNvzLCqphi/v7dpEtfF/0/syUnUnOEYOCtvUulRaMyKT
bHdaylb1lOJtwaf0iGROR6Jb9DuRUBLoRP+iM7PjPQpqhxrONIs6RWe76/0l5Gaf
nnLD8mOPhKBItASlevtK
=lm6d
-----END PGP SIGNATURE-----
SRICHARAN R - April 9, 2013, 6:31 a.m.
Hi Lubomir,

On Monday 08 April 2013 03:05 PM, Lubomir Popov wrote:
> Hi Sricharan,
> 
> On 08/04/13 09:09, Sricharan R wrote:
>> On Thursday 04 April 2013 09:22 PM, Lubomir Popov wrote:
>>> V2 fixes line wrap issue of the patch itself.
>>>
>>> I2C5 is used on all known OMAP5 hardware platforms, therefore enable.
>>>
>>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
>>>
>>> ---
>>>  arch/arm/cpu/armv7/omap5/hw_data.c |    1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> index e5e41fd..5698876 100644
>>> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
>>> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
>>> @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void)
>>>  		(*prcm)->cm_l4per_i2c2_clkctrl,
>>>  		(*prcm)->cm_l4per_i2c3_clkctrl,
>>>  		(*prcm)->cm_l4per_i2c4_clkctrl,
>>> +		(*prcm)->cm_l4per_i2c5_clkctrl,
>>
>> This is fine.
>> Can you also mention what device is connected on them ? and
>> how you are using it ?
>>
>> Also can you add these in a series.
>>
>> Regards,
>>  Sricharan
>>
> 
> On our board we have an I/O expander on I2C5 - the same chip that is used on
> the TI sEVM (the handset) and uEVM (the PandaBoard5) platforms (on both of
> which it is also connected to I2C5). Therefore it seems reasonable to have
> I2C5 enabled in the mainline. This requires that the base address is defined,
> and that I2C_BUS_MAX is set to 5 (please see related patches).
> 
> I shall do make a new series on I2C5 support.
> 
> One more thing I would like to clarify to myself: in your patch series of
> Apr. 1 you rename the omap5_evm to omap5_uevm. On the other hand, uEVM was
> the TI-internal name for the PandaBoard5, and the evm was known as sEVM.
> Doesn't this cause confusion? After all, these are two quite different
> hardware platforms.
> 
 Thanks for the explanation.
 It would good to have the reasoning in the original commit log.

 For the next one,Tom already answered this. So uEVM is the and also
 the only official.

Regards,
 Sricharan

Patch

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c
index e5e41fd..5698876 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -412,6 +412,7 @@  void enable_basic_uboot_clocks(void)
 		(*prcm)->cm_l4per_i2c2_clkctrl,
 		(*prcm)->cm_l4per_i2c3_clkctrl,
 		(*prcm)->cm_l4per_i2c4_clkctrl,
+		(*prcm)->cm_l4per_i2c5_clkctrl,
 		(*prcm)->cm_l3init_hsusbhost_clkctrl,
 		(*prcm)->cm_l3init_fsusb_clkctrl,
 		0