Re: [PATCH 2/2 v2] mtd: physmap_of_gemini: Handle pin control

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Fri, Nov 30, 2018 at 12:17 PM Boris Brezillon
<boris.brezillon@xxxxxxxxxxx> wrote:
> On Thu, 22 Nov 2018 15:10:47 +0100 Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:

> Do you mean that the GPIO controller does not request the pins it's
> using? If it does, the pinctrl framework should complain, when the pins
> are already assigned to another dev.

That depends on whether the pin controller is "strict" or
not. Several pin controllers actually allow the pin to be used
for some device and GPIO at the same time.

Gemini is not strict, there is a field in struct pinmux_ops
that controls strictness and this depends on the hardware
and use cases.

I would prefer if the world was simpler, but sadly hardware
engineers doing this kind of stuff don't know what that
means.

> If the flash and SPI bus are never accessed concurrently and things are
> controlled from userspace, maybe it's cleaner to bind/unbind devices on
> demand, and let each driver mux the conflicting pins as they expect it
> to be muxed.

These are in-kernel use cases.

The problem is not entirely new: if we want a pin
to be absolutely exclusively under control of a certain
hardware block, or even another CPU, we use a hardware
semaphore, see for example how STM32 does it:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=devel&id=97cfb6cd34f2a3dab03dce5f885333c213bbec8a

The same can of course be done using software, somehow,
with something like a global mutex that the SPI host and MTD
need to take respectively. (I imagine this would be retrieved as
a resource like any other like regulator, clock etc).

However implementing that when there isn't even a clash in
reality, just in theory, and only if I construct specific test programs
to make this happen ... I dunno it's just a bit overly ambitious.
This router is already working fine, so...

Yours,
Linus Walleij

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/