I saw that this patch was marked as not applicable, but on most qoriq devices the pre-scaler is 2 especially for p2020/p2010 devices arch/powerpc/boot/dts/fsl/p2020si-post.dtsi from the P2020 RM: p. 477 "Frequency divider ratio. Used to prescale the clock for bit rate selection. The serial bit clock frequency of SCL is equal to one half the platform ( CCB ) clock divided by the designated divider ." This means that the current dts for these devices are providing false clock settings. I have a p2020 board and can take some scope measurements next week to prove this. I think something should be modified to address this. On Tue, Nov 25, 2014 at 5:41 PM, Scott Wood <scottwood@xxxxxxxxxxxxx> 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. > > -Scott > > > -- > 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 -- - Danielle Costantino -- 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
