On 27/11/2019 20:36, Linus Walleij wrote:
Hi Phil,
I think the people I added to the To: line are better suited to answer
this question, they have used the MCP23* chips in practice more
than me and know how they work.
Some minor comments inline.
On Wed, Nov 27, 2019 at 12:20 PM Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote:
We have a user asking for help to construct a Device Tree overlay to use
the GPIOs exported by multiple MCP23S17s sharing an SPI Chip Select
line. This is a special feature of the MCP devices whereby the SPI bus
is treated rather like an I2C bus with each device assigned a unique
address. His problem is in constructing gpiospecs to refer to all of the
GPIOs.
The mcp23s08 driver claims to support this feature, and there is a DT
property ("microchip,spi-present-mask") to declare which addresses are
used buy the devices.
It's an interesting hack and I kind of see why they are doing it.
I've spent an hour or so looking at the driver
code and crawling through the kernel GPIO infrastructure, and I don't
think it's possible. Here's my logic:
1. Although all devices that are found are presented as a single SPI
device, they are each registered as independent gpio_chips.
So they are presented as a single SPI device, but they are
different physical packages (right?) so it is actually correct to
have several gpio_chips but incorrect that they are all
represented in a single device tree node.
Interestingly there is not a single device tree in the entire
kernel that uses the "*,spi-present-mask" attribute.
Could you provide an example?
I *THINK* the idea behind this attribute is just plain wrong
and cannot be made to work.
Instead the device should be represented as one SPI node
with subnodes for each separate physical device when this
attribute would be used.
mcp {
compatible = "microchip,mcp23s08";
microchip,spi-present-mask = <0x03>;
mcp0: chip0 {
reg = <0>;
....
}
mcp1: chip1 {
reg = <1>;
....
}
};
By introducing such child nodes it gets possible to reference
these chips by phandle <&mcp1 ...>;
Notice use of reg attribute to address subchip.
IIUC this needs to be figured out and both the DT bindings
and the driver need to be fixed to support this peculiar addressing
scheme.
Similar problem has come up before with gpio line props from Jan.
The above was similar to what was discussed previously a couple of times.
eg: https://patchwork.ozlabs.org/patch/1052925/
I'd say it's the way to solve the problem.
I don't have any shared cs spi devices so it hasn't been relevant to my systems.
--
Regards
Phil Reid
