lkml.org 
[lkml]   [2020]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/6] i2c: designeware: Add Baikal-T1 SoC DW I2C specifics support
    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@baikalelectronics.ru wrote:
    > > > From: Serge Semin <fancer.lancer@gmail.com>
    > >
    > > 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


    \
     
     \ /
      Last update: 2020-03-31 16:26    [W:4.208 / U:1.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site