[U-Boot] [PATCH 0/4] arm: zynq: migrate to DM I2C driver

[Olliver Schinagl]

Hi all,

On 20-07-18 13:09, Michal Simek wrote:
> On 20.7.2018 08:12, Luis Araneda wrote:
>> Hi Michal,
>>
>> On Thu, Jul 19, 2018 at 3:28 AM Michal Simek <michal.simek at xilinx.com> wrote:
>>> Please take a look at
>>> https://lists.denx.de/pipermail/u-boot/2016-November/274068.html which
>>> was the series which should replace all these boards setting in a
>>> generic way. Unfortunately I don't know why it didn't go through.
Neither do I :) some of them where 'done' as far as I remember, but it 
has been a while and I have somewhat forgotten about them a little. They 
have been used in production since then however for us.

There are plans to work on our u-boot again in the next few months and 
my intention was to pick up the ones that did not get merged.

>>
>> The last version of that series [1] (v6, 28 patches) has the state
>> "Changes Requested" on patchwork, and it even has some TODOs. It's a
>> generic way of reading a MAC address from an EEPROM with helper
>> functions.
>> I'm not proposing something as generic and elaborated as that series,
>> but an improvement to what is used today.
>>
>> I sent this series to move some legacy options to Kconfig.
>> Additionally, the Zybo Z7 has its MAC address stored on an SPI FLASH,
>> which will likely require a new Kconfig option (MAC_ADDR_IN_SPI_FLASH)
>> eventually. Something that [1] doesn't cover (from what I read).
No, I did not have SPI memory available at the time, and was sort of 
waiting for the generic EEPROM framework to progress (that died).

Having said that, adding SPI eeprom would have been trivial.

>>
>> It just occurred to me that what I'm really doing in the fourth patch
>> is reading the MAC address from a generic memory connected to I2C,
>> because it's a generic memory read operation (device address, memory
>> address, read operation). So I think the name of the Kconfigs could be
>> CONFIG_MAC_ADDR_IN_I2C_MEMORY instead of
>> CONFIG_MAC_ADDR_IN_I2C_EEPROM. It can even be more generic like
>> CONFIG_MAC_ADDR_IN_I2C. What do yo think?
Well I think the generic memory framework did make sense at the time, 
and didn't compulab merge something like this at some point?

>>
>>> And then regarding DM i2c. Driver is in the driver for a while but for
>>> i2c muxes support it requires all subbusses to be listed in DTS file
>>> which is not what it is common in Linux dt binding. That's why some work
>>> needs to be done in this area to convert all platforms.
>>
>> Yes, I realize that I2C muxes are a pending issue, but that's why I
>> only migrated the boards that are not using I2C muxes. From my point
>> of view, it's less work to be done when porting
>>
>> Anyway, I just wanted to improve the current state of the code, I
>> don't need these changes for what I'm doing. So if you like to wait
>> for [1] to be merged, it's fine with me and we can drop this series,
>> otherwise, please review it so I can make changes if necessary.
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2017-May/291401.html
> 
> I have no problem to move ZYNQ_GEM_EEPROM_ADDR to Kconfig without
> changing the name.
> 
> Oliver: Any comment about your patch series?
What I just wrote above :)
> 
> And I would let Joe to handle that mac address reading.
> That v6 series contains a lot of patches which have been acked. The
> biggest problem was about sunxi which is something what can be ignored.
> If Oliver doesn't want to send v7 then I would recommend you simply take
> his v6 version and that patches which are required and just send them
> again. I think it won't take so much time because a lot of things were
> already done.
I don't mind starting to work on a v7; i think one of the issues I ran 
into was turn around time which took quite a while. I may even have v7 
locally actually! I'll see what can be done within the comming period; 
but again, we are going to update/add more support to our u-boot so I 
should be working on this again soon-ish.

> 
> Thanks,
> Michal
> 
>