Sorry for the slooow response, I've been on vacation. On Tue, Jul 16, 2013 at 01:16:18PM +0200, Christian Ruppert wrote: > > Second step is that if current i2c_dw_scl_hcnt and i2c_dw_scl_lcnt > > calculations don't suit with later DW I2C cores, then it would be > > nice for someone who can access to the data book to update formulas, > > or provide alternative formulas and make them selectable depending > > on DW core versions. > > I'm not having the impression there is a huge difference between the > different generations of DW blocks. Probably we can find one formula > that suits all blocks. We just have to be careful (in doubt rather > conservative) with the transition times. This seems to be currently > the case and if I understand Mika correctly, his objective is to remove > some of this conservatism.
What I had originally in mind was that we could just pass whatever HCNT/LCNT values we get from system FW (with the help of ACPI or DT). However, if we can make the HCNT/LCNT calculation more accurate using tf and tr, that are passed from DT or platform data, we should implement that as well (as a separate patch). > > It always helps us to have a way to calculate *HCNT and *LCNT values > > automatically. As said above, DW I2C core can control tHIGH, tLOW, > > tHD;STA, etc. quite _accurate_, if HCNT/LCNT values were calculated > > with proper formulas. It also helps hardware people as well to > > provide reference HCNT/LCNT values. > > > > And as a third step, if we want to use optimized HCNT/LCNT values > > which can not be obtained from proper formulas + user-requested > > tf/tr, or if we want to use HCNT/LCNT settings verified by vendors > > or provided from hardware team, then I'm fine with having a way to > > _override_ HCNT/LCNT values. Such direct way might be useful. > > I agree. Probably it is best to have both, a default method based on > formulas and timing parameters (the formulas are quite simple anyway) > which works with device tree and such and a second method based on > register values which works with mechanisms like ACPI. I agree. I'm going to post a new version of this patch (and the SDA hold patch) that takes care of the ACPI case if there are no objections. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
