tech-kern archive

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

Re: i2c and indirect vs. direct config



I think I like this approach.


But I'm unclear on how/where the i2c-SMBus device's property-list gets
set in the first place.

For modular drivers loaded from the file-system after the system is up
and running, there is a module prop-list, but I don't think it gets
"hooked in" to the device's prop-list.

For non-modular (built-in) drivers on fdt-based platforms, I suppose
that the fdt stuff could provide the prop-list.  (Does it?)  But on
non-fdt systems the prop-list would have to be specified somehow,
presumably at "build" time, which to me implies something in the
config language?

Or maybe there's some other mechanism(s) of which I'm not aware?

Or maybe I'm just blind (or more likely, clueless)!




On Mon, 4 Jun 2018, Jason Thorpe wrote:



On Jun 4, 2018, at 2:47 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:



On Jun 3, 2018, at 7:44 AM, Jason Thorpe <thorpej%me.com@localhost> wrote:

Actually, I am thinking more of a set of properties that control the behavior of the generic i2c code:

To follow-up, I think I have this sorted out.  There were a couple of other issues with how indirect-config was taking place on i2c bus instances, which I fixed as part of this.

I’ll post a more complete follow-up with the details tonight or tomorrow.

OK!

So, a couple of things:

— iic_search() was structured incorrectly, really.  In indirect-config, the “search” routine is called one for each directive in the kernel config file that matches the pspec.  If that directive has non-wildcarded locators, there is zero need to scan the address space of the bus.  It wasn’t entirely wrong before (because of the “check for wildcard” in the loop), but it certainly wasted cycles.

— i2c really needs varying levels of matchy-ness, based on the quality of the match, which I have addressed in my proposed changes.

…which are thus:

— iic_search() chooses a “probe strategy” based on the "i2c-indirect-probe-strategy” property on the “iic” instance.  Valid values are "smbus-quick-write”, "smbus-receive-byte”, and “none”.  If no value is specified, the default is "smbus-quick-write”.

— If the "i2c-indirect-device-whitelist” exists on the “iic” instance, iic_search() will first check the driver name in the cfdata_t against this list, and only allow the match/probe to move forward if the cfdata_t driver name is in the list.  This is primarily to accommodate the Intel integrated memory controller neutered-i2c-thing.

— If the cfdata_t specifies a wildcard address, each address of the i2c bus will be consulted.  If the cfdata_t contains a nailed-down address, then we limit the bus scan to that specific address.

— We explicitly skip reserved / special i2c addresses, such as the All-Call address, etc.

— We introduce the notion of a “match quality” for i2c drivers.  From lowest-quality to highest-quality: matched by plausible address only, matched by plausible address and poking at the bus to see if the device looks reasonable, matched by direct-config “compatible” string, matched by direct-config “driver name” string.

— If the “match quality” is merely “plausible address only”, then iic_search() will use the probe strategy selected above to see if a device responds to that address.


None of these things impact direct-config, at least not yet.  Eventually I will change all drivers to use the match quality values in their various match routines, including those for direct-config.

I haven’t tested these on my RPI just yet — but I will try to do so tonight or tomorrow.  But would like to solicit feedback on the approach now.



!DSPAM:5b160dd0170195038547222!


+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+


Home | Main Index | Thread Index | Old Index