Wolfgang, Scott, On 12/11/2014 02:44 PM, Valentin Longchamp wrote: > Hi all, > > Picking up this issue again. > > On 11/26/2014 02:41 AM, Scott Wood wrote: >> On Tue, 2014-11-25 at 19:13 +0100, Wolfram Sang wrote: >>> On Mon, Nov 17, 2014 at 07:28:03PM -0600, Scott Wood wrote: >>>> On Fri, 2014-11-14 at 09:28 +0100, Wolfram Sang wrote: >>>>>>> >>>>>>> If we're going to change the device tree I'd rather just add a property >>>>>>> to say what the prescaler is. >>>>>> >>>>>> We would however, leave the boards' device trees that use things like >>>>>> "fsl,mpc8543-i2c" as is and introduce the prescaler for the others requiring it. >>>>>> >>>>>> >>>>>> Now the drawback is that the driver would require a change, to parse this >>>>>> prescaler new prescaler property. Would this be OK from your point of view >>>>>> Wolfram ? If yes, I will send the patches for it. >>>>> >>>>> I don't think it is OK. >>>> >>>> Why? >>> >>> Because I thought it could be deduced. Then, a seperate property would >>> not be OK. >>> >>>>> I'd think it can be deduced from the compatible property. >>>> >>>> For almost all existing device trees it cannot be. >>> >>> Pity :( If we do introduce a new property, it should probably be >>> "clock-div". Grepping through binding documentation, that seems >>> accepted. We should ask DT maintainers, too, to be safe. >>> >>>> If you want something that will work without changing device trees, >>>> you'll need to use SVR to identify the SoC. >>> >>> The driver is doing that already, see mpc_i2c_get_sec_cfg_8xxx(). Dunno >>> if it makes sense to add to it for consistency reasons? >> >> That's not SVR, but sure. Better to avoid messing with existing device >> trees. >> > > What is then the agreement here ? Add a clock-div to the device trees ? Or do > something similar to mpc_i2c_get_sec_cfg_8xxx() ? > > I think the clock-div property is better according to Freescale's AN 2919 > section 3.1 Source clock. All the source clocks are fixed (with a clock-div of 2 > in case of mpc8536/43/45/47/48/67/68/72, plus p2020) except for the mpc8533/44 > where it can be 2 or 3, and that's what mpc_i2c_get_sec_cfg_8xxx() determines. > > So mpc_i2c_get_sec_cfg_8xxx() should remain the exception and the other > prescaler values should be derived from an additional clock-div that must be > added in the respective device trees (at least for the qoriq devices, because > for instance mpc8543 already has the correct prescaler thanks to > mpc_i2c_data_8543 from i2c-mpc.c). > Do you have an opinion on the above ? Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html