Messages in this thread | | | From | "Wang, Lawrence (NSB - CN/Hangzhou)" <> | Subject | RE: [PATCH] i2c: designware: Get HCNT/LCNT values from dts | Date | Mon, 15 Nov 2021 10:41:06 +0000 |
| |
Hello Shevchenko
Thanks for your quick reply.
Besides the fact it misses DT schema update, why this is needed at all? ------> we need a interface to configure the HCNT/LCNT via dts (current we just have ACPI to config it). What's wrong with the existing DT timings? --------> the HCNT/LCNT value calculated by code is not accuracy. This is similar changes as the ACPI interface. i2c_dw_acpi_params(device, "SSCN", &dev->ss_hcnt, &dev->ss_lcnt, &ss_ht); i2c_dw_acpi_params(device, "FPCN", &dev->fp_hcnt, &dev->fp_lcnt, &fp_ht); i2c_dw_acpi_params(device, "HSCN", &dev->hs_hcnt, &dev->hs_lcnt, &hs_ht); i2c_dw_acpi_params(device, "FMCN", &dev->fs_hcnt, &dev->fs_lcnt, &fs_ht); - i2c-scl-falling-time-ns - i2c-scl-internal-delay-ns - i2c-scl-rising-time-ns - i2c-sda-falling-time-ns Yeah, I know those properties. But those are common for i2c. My changes is for the specific HW controller(designware) for configuring its two register HCNT/LCNT. In this case, still we need one property per each value?
-- With Best Regards, Lawrence, Wang
-----Original Message----- From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Sent: 2021年11月15日 18:28 To: Wang, Lawrence (NSB - CN/Hangzhou) <lawrence.wang@nokia-sbell.com> Cc: jarkko.nikula@linux.intel.com; mika.westerberg@linux.intel.com; linux-i2c@vger.kernel.org; linux-kernel@vger.kernel.org; Wang@wrlinb193.emea.nsn-net.net Subject: Re: [PATCH] i2c: designware: Get HCNT/LCNT values from dts
On Mon, Nov 15, 2021 at 12:19:26PM +0200, Andy Shevchenko wrote: > On Mon, Nov 15, 2021 at 10:35:55AM +0100, Lawrence,Wang wrote: > > From: "Wang, Lawrence" <lawrence.wang@nokia-sbell.com> > > > > Current code support config the HCNT/LCNT only via ACPI method. for > > those platform that not support ACPI, will get the HCNT/LCNT value > > based on input clock. But it is not always accuracy. for example in > > some platform will get lower speed(320khz) in fast mode, and get > > faster speed(105khz/even more) in standard mode. > > > > This patch makes it possible for the non-ACPI platform to pass more > > optimal HCNT/LCNT values to the core driver via dts if they are known beforehand. > > If these are not set we use the calculated values. > > Besides the fact it misses DT schema update, why this is needed at all? > What's wrong with the existing DT timings?
Just for your convenience an excerpt from Documentation/devicetree/bindings/i2c/i2c.txt
- i2c-scl-falling-time-ns Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C specification.
- i2c-scl-internal-delay-ns Number of nanoseconds the IP core additionally needs to setup SCL.
- i2c-scl-rising-time-ns Number of nanoseconds the SCL signal takes to rise; t(r) in the I2C specification.
- i2c-sda-falling-time-ns Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C specification.
-- With Best Regards, Andy Shevchenko
| |