RE: [PATCH v2] i2c: riic: remove fixed clock restriction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, October 13, 2017, Wolfram Sang wrote:
> On Wed, Oct 11, 2017 at 03:20:29PM +0000, Chris Brandt wrote:
> > On Friday, September 29, 2017, Chris Brandt wrote:
> > > Most systems with this i2c are going to have a clock of either 33.3MHz
> or
> > > 32MHz. That 4% difference is not reason enough to warrant that the
> driver
> > > to completely fail.
> > >
> > > Signed-off-by: Chris Brandt <chris.brandt@xxxxxxxxxxx>
> > > ---
> > > v2:
> > >  * simplified error message.
> > > ---
> >
> > What ever happened to this patch?
> > Was there any objection?
> 
> In deed, I'd prefer to limit the settings to the two known frequencies.
> We shouldn't use the settings if someone is using it with e.g. 16MHz?

How about a range of -4% to +2% ?


	/*
	 * TODO: Implement formula to calculate the timing values depending on
	 * variable parent clock rate and arbitrary bus speed.
	 * For now, just use calculations based on a 33325000Hz clock.
	 */
	rate = clk_get_rate(riic->clk);
	if ((rate < 32000000) || (rate > 34000000)) {
		dev_err(&riic->adapter.dev,
			"invalid parent clk (%lu). Must be 32MHz-34MHz\n",
			rate);
		clk_disable_unprepare(riic->clk);
		return -EINVAL;
	}



> Of course, my most favorite option would be implementing the formula
> instead of fixed settings, but I am not forcing that on you.

So I looked at that.

However...

Technically, to do it right, to calculate the ACTUAL I2C baud rate, you 
have to take into effect the load resistance and capacitance of the 
lines in order to factor in the rise and fall times correctly. Of course 
that varies board to board. And then, 100kHz (standard-mode) and 400kHz 
(fast-mode) have different minimum HIGH/LOW times and duty cycle 
restrictions, so that has to be taken into account when coming up with a formula.

   --or--

Just live with the fact that the speed might be off by 4%.


   (I decided on option #2)


Chris





[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux