On 30/10/2019 15.51, Philipp Zabel wrote: > On Wed, 2019-10-30 at 15:32 +0200, Peter Ujfalusi wrote: >> >> On 30/10/2019 15.12, Rob Herring wrote: >>> On Wed, Oct 30, 2019 at 7:03 AM Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote: >>>> Hi, >>>> >>>> The shared GPIO line for external components tends to be a common issue and >>>> there is no 'clean' way of handling it. >>>> >>>> I'm aware of the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag, which must be provided when >>>> a driver tries to request a GPIO which is already in use. >>>> However the driver must know that the component is going to be used in such a >>>> way, which can be said to any external components with GPIO line, so in theory >>>> all drivers must set this flag when requesting the GPIO... >>>> >>>> But with the GPIOD_FLAGS_BIT_NONEXCLUSIVE all clients have full control of the >>>> GPIO line. For example any device using the same GPIO as reset/enable line can >>>> reset/enable other devices, which is not something the other device might like >>>> or can handle. >>>> For example a device needs to be configured after it is enabled, but some other >>>> driver would reset it while handling the same GPIO -> the device is not >>>> operational anymmore as it lost it's configuration. >>>> >>>> With the gpio-shared gpiochip we can overcome this by giving the gpio-shared >>>> the role of making sure that the GPIO line only changes state when it will not >>>> disturb any of the clients sharing the same GPIO line. >>> >>> Why can't we just add a shared flag like we have for interrupts? >>> Effectively, we have that for resets too, it's just hardcoded in the >>> the drivers. >> >> This would be kind of the same thing what the >> GPIOD_FLAGS_BIT_NONEXCLUSIVE does, which was a quick workaround for >> fixed-regulators afaik. >> >> But let's say that a board design will pick two components (C1 and C2) >> and use the same GPIO line to enable them. We already have the drivers >> for them and they are used in boards already. >> >> Both needs the GPIO line to be high for normal operation. >> One or both of them needs register writes after they are enabled. >> >> During boot both requests the GPIO (OUTPUT_LOW) and sets it high, then >> run the register setup. >> >> C1 request GPIO (LOW) >> C1 gpio_set(1) >> C1 register writes >> C2 requests GPIO (LOW) >> C1 placed to reset and looses the configuration >> C2 gpio_set(1) >> C1 also enabled >> C2 register writes >> >> At this point C2 is operational, C1 is not. >> >> In shared GPIO case the GPIO should be handled like a regulator with a >> twist that the 'sticky' state of the GPIO might be low or high depending >> on the needs of the components it is connected to. >> >> The shared GPIO line is a board design quirk and basically any device >> which have reset/enable GPIO must be able to work in a situation when >> they are sharing that line with other components and the driver should >> not know much about this small detail. > > What about components that require a register write right after being > enabled, for example to put the device into a low power state, to > silence it on a bus, or to mask some initially enabled interrupts? You are right, if a device needs driver to silence it when enabled (we might not have the driver compiled) then this can be a problem. But the same thing applies to components without enable/reset GPIO and only needing power, no? I would trust (I know...) on the board designers to not bundle components of such kinds. > > regards > Philipp > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
