All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Ditto <mditto-Vjf7OWgA3BLqlBn2x/YWAg@public.gmane.org>
To: David Gibson
	<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>,
	Jochen Friedrich <jochen-NIgtFMG+Po8@public.gmane.org>
Cc: linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] i2c-cpm: Add flexibility for I2C clock frequency and filter.
Date: Wed, 05 Nov 2008 17:12:32 -0800	[thread overview]
Message-ID: <49124480.4030409@consentry.com> (raw)
In-Reply-To: <20081106005339.GF28465-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>

[including extra context because some of the thread went to the
 wrong I2C list]

David Gibson wrote:
> On Wed, Nov 05, 2008 at 04:35:03PM -0800, Mike Ditto wrote:
>> David Gibson wrote:
>> > What does worry me, however, is the description says it's about
>> > whether the driver "should" enable the filter.  Generally the device
>> > tree doesn't attempt to say what users "should" do with the hardware,
>> > just what the characteristics of the hardware are.
>> >
>> > What's the underlying difference here that affects the driver's choice
>> > to enable the filter or not?
>> 
>> I think it's a hardware/environment design parameter - e.g. if the I2C
>> bus has hot-pluggable devices, long PCB traces, or a hierarchy of
>> multiplexed bus segments, these can result in a noisy SCL signal that
>> needs to be filtered.  It's also a recommended mitigation for errata
>> in certain CPU revs.
> 
> Ah, ok.  Well the CPU revision thing could be selected based on the
> CPU revision, but the other conditions are a property of the board
> wiring.  Obviously it's hard to precisely characterize what it says
> about the hardware, which is usually best avoided for devtree
> properties, but I can see why this is more-or-less unavoidable in this
> case.
> 
> Ok.  This property name and meaning looks ok to me.  I would suggest a
> note in the binding roughly explaining what leads to the property
> being set (basically what you just told me in the paragraph above).

Will do.  I'll send a revised patch shortly.

Thanks,
					-=] Mike [=-

WARNING: multiple messages have this Message-ID (diff)
From: Mike Ditto <mditto@consentry.com>
To: David Gibson <david@gibson.dropbear.id.au>,
	Jochen Friedrich <jochen@scram.de>
Cc: linuxppc-dev@ozlabs.org, linux-i2c@vger.kernel.org
Subject: Re: [PATCH] i2c-cpm: Add flexibility for I2C clock frequency and filter.
Date: Wed, 05 Nov 2008 17:12:32 -0800	[thread overview]
Message-ID: <49124480.4030409@consentry.com> (raw)
In-Reply-To: <20081106005339.GF28465@yookeroo.seuss>

[including extra context because some of the thread went to the
 wrong I2C list]

David Gibson wrote:
> On Wed, Nov 05, 2008 at 04:35:03PM -0800, Mike Ditto wrote:
>> David Gibson wrote:
>> > What does worry me, however, is the description says it's about
>> > whether the driver "should" enable the filter.  Generally the device
>> > tree doesn't attempt to say what users "should" do with the hardware,
>> > just what the characteristics of the hardware are.
>> >
>> > What's the underlying difference here that affects the driver's choice
>> > to enable the filter or not?
>> 
>> I think it's a hardware/environment design parameter - e.g. if the I2C
>> bus has hot-pluggable devices, long PCB traces, or a hierarchy of
>> multiplexed bus segments, these can result in a noisy SCL signal that
>> needs to be filtered.  It's also a recommended mitigation for errata
>> in certain CPU revs.
> 
> Ah, ok.  Well the CPU revision thing could be selected based on the
> CPU revision, but the other conditions are a property of the board
> wiring.  Obviously it's hard to precisely characterize what it says
> about the hardware, which is usually best avoided for devtree
> properties, but I can see why this is more-or-less unavoidable in this
> case.
> 
> Ok.  This property name and meaning looks ok to me.  I would suggest a
> note in the binding roughly explaining what leads to the property
> being set (basically what you just told me in the paragraph above).

Will do.  I'll send a revised patch shortly.

Thanks,
					-=] Mike [=-

  parent reply	other threads:[~2008-11-06  1:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-31  4:09 [PATCH] i2c-cpm: Add flexibility for I2C clock frequency and filter Mike Ditto
2008-10-31 11:40 ` Jochen Friedrich
2008-10-31 21:19   ` Mike Ditto
     [not found]   ` <490AEEBF.9000707-NIgtFMG+Po8@public.gmane.org>
2008-10-31 21:22     ` Mike Ditto
2008-10-31 21:22       ` Mike Ditto
2008-11-05 23:36   ` David Gibson
2008-11-06  0:35     ` Mike Ditto
2008-11-06  0:53       ` David Gibson
     [not found]         ` <20081106005339.GF28465-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2008-11-06  1:12           ` Mike Ditto [this message]
2008-11-06  1:12             ` Mike Ditto
     [not found]       ` <49123BB7.90503-Vjf7OWgA3BLqlBn2x/YWAg@public.gmane.org>
2008-11-06  0:53         ` David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2008-10-31  4:13 Mike Ditto
2008-10-31 11:43 Jochen Friedrich
2008-11-06  1:55 Mike Ditto
2008-11-06  1:55 ` Mike Ditto
     [not found] ` <49124EAD.8090508-Vjf7OWgA3BLqlBn2x/YWAg@public.gmane.org>
2008-11-06 11:27   ` Jochen Friedrich
2008-11-06 11:27     ` Jochen Friedrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49124480.4030409@consentry.com \
    --to=mditto-vjf7owga3blqlbn2x/ywag@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=jochen-NIgtFMG+Po8@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.