On Sat, May 01, 2021 at 12:10:16AM +0200, Michael Walle wrote:
Am 2021-04-30 19:26, schrieb Mark Brown:
> But that's a driver for a specific device AFAICT which looks like it's
> only got an I2C binding on the MFD so the driver knows that it's for a
> device that's on a bus that's going to sleep and doesn't need to infer
> anything? This looks like the common case I'd expect where there's no
> variation.
You are right, at the moment this driver only has an I2C binding. But
the idea was that this IP block and driver can be reused behind any
kind of bridge; I2C, SPI or MMIO. Actually, I had the impression
Is this actually a way people are building hardware though?
that all you need to do to convert it to MMIO is to replace the
"kontron,sl28cpld" compatible with a "syscon" compatible. But it isn't
that easy. Anyway, the idea is that you don't need to change anything
in the gpio-sl28cpld driver, just change the parent. But if we can't
ask the regmap what type it is, then we'll have to modify the
gpio-sl28cpld driver and we will have to figure it out by some other
means.
Well, you don't need to change anything at all - the driver will work
perfectly fine if it's flagging up the GPIOs as potentially sleeping
even if they end up not actually sleeping.
> If users happen to end up with a map flagged as fast they can work on
> the whatever driver uses this stuff and not realise they're breaking
> other users of the same driver that end up with slow I/O. The whole
> point of the flag in GPIO is AIUI warnings to help with that case.
Hm, but as of now, the only thing which makes the gpio-regmap driver
slow i/o is the regmap itself.
Surely it's just a case of the device that's creating the gpio regmap
setting a flag when it instantiates it? It's just one more thing that
the parent knows about the device. This doesn't seem insurmountable.