Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support

[Linus Walleij]

On Mon, Nov 5, 2012 at 3:03 PM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
(...)
>> If the addresses are consecutive like ours it makes sense
>> to just instantiate one device and have the driver know that it will
>> also be able to access address +1, +2 ... +n. So is it possible
>> to group the consecutive related addresses after each other
>> here at the acpi-spi level and just create a single device?
>
> We were actually discussing I2C here, although I admit not in the right
> thread, and maybe some of this applies to SPI as well.

This is my typo. The AB8500 example is indeed I2C.

> So if multiple slave addresses must be
> supported, please do not limit this support to consecutive addresses.

I buy that ... in Nomadik we even have an instance of a single device
with two discrete *physical* interfaces connected to it, on both of
them it responds to the same address, but with totally different
register layouts ... hardware engineers rule! :-)

> There really is no reason to limit us that way anyway, as i2c-core
> supports attaching any additional slave address to en existing
> i2c_client using i2c_new_dummy().

Yes, this is how we do it in AB8500. We just take advantage of
the fact that the addresses are consecutive.

> Note for DDR3 DIMM SPD chips we currently have two different drivers
> handling the two slave addresses (eeprom/at24 and jc42.) I don't know
> if this is something that could be instantiated from ACPI. So it seems
> we really have two different cases when a single chip replies to
> multiple slave addresses: either they refer to the same function and we
> want a single driver for all of them, or they are for unrelated
> functions and we want separate drivers (and thus separate i2c_clients.)
> Not sure how we can always handle that properly on the ACPI side.

If they can be accessed concurrently and do not share
any locks or code they should be separate I think?
When they have strong dependencies we immediately sort of
fall into the MFD class where you need a mediator I think.

>> If the addresses are not consecutive I guess you need to have
>> one device driver bind to several devices and return -EPROBE_DEFER
>> until the driver has been probed for all of them or something like
>> that, this is what multi-block GPIO drivers sometimes do.
>
> Consecutive or not makes no difference really, as long as the driver
> can deduce the additional addresses from the main address or register
> contents accessible from the main address. This has always been the
> case so far.

You're right.

Yours,
Linus Walleij
--
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/