On Tue, Mar 31, 2020 at 02:48:24PM +0300, Sergey Semin wrote: > Hello Andy, > > Finally I've thought this through reasonably conformed with the changes > requested in the framework of the other patchsets. My comments are > below. > > On Fri, Mar 06, 2020 at 03:54:45PM +0200, Andy Shevchenko wrote: > > First of all, I got only 3 out of 6 patches. Are you sure you properly prepared > > the series? > > > > On Fri, Mar 06, 2020 at 04:19:49PM +0300, Sergey.Semin@xxxxxxxxxxxxxxxxxxxx wrote: > > > From: Serge Semin <fancer.lancer@xxxxxxxxx> > > > > Same comment as per DMA series, try next time to link the cover letter to the > > series correctly. > > > > > There are three DW I2C controllers embedded into the Baikal-T1 SoC. Two > > > of them are normal with standard DW I2C IP-core configurations and registers > > > accessible over normal MMIO space - so they are acceptable by the available > > > DW I2C driver with no modification. > > > > > But there is a third, which is a bit > > > different. Its registers are indirectly accessed be means of "command/data > > > in/data out" registers tuple. In order to have it also supported by the DW > > > I2C driver, we must modify the code a bit. This is a main purpose of this > > > patchset. > > > > > > First of all traditionally we replaced the legacy plain text-based dt-binding > > > file with yaml-based one. Then we found and fixed a bug in the DW I2C FIFO size > > > detection algorithm which tried to do it too early before dw_readl/dw_writel > > > methods could be used. > > > > So far so good (looks like, I think colleagues of mine and myself will review > > individual patches later on). > > > > > Finally we introduced a platform-specific flag > > > ACCESS_INDIRECT, which would enable the indirect access to the DW I2C registers > > > implemented for one of the Baikal-T1 SoC DW I2C controllers. See the commit > > > message of the corresponding patch for details. > > > > This is quite questionable. In Intel SoCs we have indirect I²C controllers to > > access (inside PMIC, for example). The approach used to do that is usually to > > have an IPC mechanism and specific bus controller driver. See i2c-cht-wc.c for > > instance. > > > > I'm not sure if it makes a lot of duplication and if actually switching I²C > > DesignWare driver to regmap API will solve it. At least that is the second > > approach I would consider. > > > > But I'll wait others to comment on this. We have to settle the solution before > > going further. > > > > As I see the others have not comments.) Anyway I see your point and having the > regmap-based interface might be better than the approach I've suggested > in this patchset particularly seeing that our DW i2c IP registers are > hidden behind a system controller register space. > > In order to follow your proposition to create a dedicated regmap and to supply > it to the DW i2c driver, I have to redevelop not only this patchset, but > also an adjacent drivers. In particular the changes will concern the > MFD-based System Controller driver (which will instantiate this DW i2c > controller device), Clocks Control Unit drivers set, and a few > others. The whole alteration I described in the RFC: > https://lkml.org/lkml/2020/3/22/393 > You've been in Cc there, so fill free to send your comments regarding > the changes I suggested. Though this time I hope the solution will > satisfy everyone, who had issues with patchsets I've recently sent. > > Getting back to your comment in the framework of this patchset. The approach > used for CHT Whiskey Cove i2c isn't fully suitable in our case for > the reason of the DW I2C controller nature. DW I2C controller is a generic > controller and used on many different platforms, while AFAICS CHT Whiskey Cove > I2C is the SoC-specific used to access a charger-IC. So in the former case we > may have an arbitrary set of i2c-slaves connected to the controller on > different platforms, while on the latter one - there is a fixed set of > slaves. In addition due to the same reason the DW I2C IP might be > embedded into different sub-blocks on different platforms, while the CHT > Whiskey Cove I2C is known to be a part of Intel CHT WC SoC PMIC. > For instance Baikal-T1 SoC has one DW I2C controller embedded into the > System Controller with indirectly accessible registers and two DW I2C > interfaces with normal memory mapped registers. Due to this in case of DW I2C > driver we can't just "suck" the regmap out from a parental MFD or > anywhere else as it's done in the CHT Whiskey Cove I2C driver, but instead > we should somehow supply a regmap pointer to the driver. > > Taking into account all of these we can utilize a combined approach > implemented in ./drivers/i2c/busses/i2c-cht-wc.c and > drivers/mfd/intel_quark_i2c_gpio.c . I'll add a regmap pointer field to the > "struct dw_i2c_platform_data" structure, so in case if there is no > IORESOURCE_MEM resources available (platform_get_resource() fails), we > try to get a regmap pointer from the platform data. If there is no valid > regmap available, then completely fail the driver probe procedure. Though > due to this alteration I'll have to change the > dw_i2c_platform_data.i2c_scl_freq field usage a bit. In case if it's > zero, then call i2c_parse_fw_timings(). This won't hurt ACPI or dt-less > platforms, but will let us cover a case when regmap is set while i2c > clock frequency is supposed to be taken from the kernel firmware (like > dtb, etc). > > So if you are Ok with this, I'll send a v2 patchset with corresponding > alteration implemented. I was thinking about something like this: 1/ core driver (library + master + slave) is converted to use regmap 2/ platform and PCI driver may provide regmap MMIO 3/ your glue driver will provide different regmap accessors -- With Best Regards, Andy Shevchenko
