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). 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
