Re: Fwd: [PATCH 1/3] i2c: Add Device Tree support to the NomadikI2C driver

From: Srinidhi Kasagar
Date: Mon Jun 18 2012 - 03:59:36 EST


On Mon, Jun 18, 2012 at 09:18:05 +0200, Lee Jones wrote:
> On 17/06/12 18:43, Linus Walleij wrote:
> > Gah, what a thread...
> >
> > On Fri, Jun 15, 2012 at 3:18 PM, Lee Jones<lee.jones@xxxxxxxxxx> wrote:
> >> On 15/06/12 14:05, Srinidhi Kasagar wrote:
> >>> On Fri, Jun 15, 2012 at 14:45:11 +0200, Lee Jones wrote:
> >>>> On 15/06/12 12:50, Srinidhi Kasagar wrote:
> >
> >>>>>> +static struct nmk_i2c_controller u8500_i2c = {
> >>>>>> + /*
> >>>>>> + * Slave data setup time; 250ns, 100ns, and 10ns, which
> >>>>>> + * is 14, 6 and 2 respectively for a 48Mhz i2c clock.
> >>>>>> + */
> >>>>>> + .slsu = 0xe,
> >>>>>> + .tft = 1, /* Tx FIFO threshold */
> >>>>>> + .rft = 8, /* Rx FIFO threshold */
> >>>>>> + .clk_freq = 100000, /* std. mode operation */
> >>>>>> + .timeout = 200, /* Slave response timeout(ms) */
> >>>>>> + .sm = I2C_FREQ_MODE_FAST,
> >>>>>
> >>>>> How is this possible? you are setting clk_freq as 100kb/s and mode
> >>>>> as fast mode which is supposed to be 400kb/s.
> >>>>
> >>>> That's not how I read it:
> >>>
> >>> But it is not readable. It confuses people.
> >>
> >> I understood it. :)
> >>
> >> If you think it's unclear speak to the author, Linus. He's CC'ed.
> >
> > Author of what? The i2c driver was written by Srinidhi. (The
> > MODULE_AUTHOR() clause should be a good hint...)
>
> Actually, we appear to have our wires crossed. You wrote the board data
> stuff below, which changes the mode from STANDARD to FAST, no doubt
> using Srinidhi's struct explanation comments found in
> arch/arm/plat-nomadik/include/plat/i2c.h.
>
> > I'll cook a separate patch for this or something.
>
> Cool, thanks Linus.
>
> But you're correct in what you say Linus. Srinidhi, the comments which
> are you say are confusing are the bits you are the author of:
> e208c447bd728920e4f3d438a706344ea31249b9?

yes, it is of course evident that it's my commit from git.
I think you are not catching my point. What I mean is:
fast mode devices are downward compatible and can communicate
with the devices with standard only mode. Those comments in that
enum says exactly that (with "up to" keyword). However the code
which configures the bus in fast mode and restrict the frequency
to operate in 100 kb/s without any reason, and this creates
confusion..

Perhaps, I think we need to remove one of these
parameters as configurable options and derive out the
frequency based on the mode of operation..

/srinidhi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/