Re: [PATCH 2/2] gpio / ACPI: add support for GPIO operation regions

[Mika Westerberg]

On Tue, Sep 24, 2013 at 12:47:56AM +0000, Zheng, Lv wrote:
> > From: Mika Westerberg [mailto:mika.westerberg@xxxxxxxxxxxxxxx]
> > Sent: Tuesday, September 17, 2013 4:37 PM
> > 
> > On Mon, Sep 16, 2013 at 11:35:56PM +0000, Zheng, Lv wrote:
> > > > From: Mika Westerberg [mailto:mika.westerberg@xxxxxxxxxxxxxxx]
> > > > Sent: Monday, September 16, 2013 4:11 PM
> > > >
> > > > On Mon, Sep 16, 2013 at 01:21:53AM +0000, Zheng, Lv wrote:
> > > > > > A pseudo device may be created to access the GPIO operation region fields provided by one GPIO device.
> > > > > > The pseudo device may have other functions to access other GPIO operation region fields provided by other GPIO devices, or even
> > worse
> > > > to
> > > > > > access other ACPI provided value-adds.
> > > > > > So hierarchically the pseudo device only requires CPU, thus should not be under the GPIO device, which means the GPIO operation
> > > > regions
> > > > > > have nothing to do with the GPIO devices' ACPI handle.
> > > > >
> > > > > Sorry for the wording.
> > > > > It's better to say the GPIO operation region users haven't strict
> > > > > relationship to the GPIO operation region providers.
> > > > > As the installation is to provide GPIO operation regions to the users, it
> > > > > shouldn't relate to the providers' ACPI handle.
> > > >
> > > > If I understand you correctly you mean that there might be multiple users
> > > > (different devices) for the same GPIO operation region, right?
> > >
> > > No, this is not what I meant.
> > > Can one vendor device uses two or more GPIO pins from different GPIO ports?
> > 
> > Yes.
> 
> So how can such a device under one of these GPIO ports?
> It can only be under one particular GPIO port device, right?
> 
> Thus I believe such device will appear below other devices rather than
> below a GPIO port device in the ACPI namespace.

I'm sorry, but I can't follow what you mean.

> > > > That shouldn't be a problem as far as I can tell.
> > > >
> > > > What comes to the hierarchy you refer, I'm not sure if that is a problem
> > > > either (unless I'm missing something). The GPIO can be used anywhere in the
> > > > ASL, it doesn't have to be descendant of the GPIO device. You only need to
> > > > do something like this:
> > > >
> > > > 	// Assert the GPIO
> > > > 	Store(1, \_SB.PCI0.SHD3)
> > > >
> > > > In other words, use the fully qualified name.
> > >
> > > Yes, which means this line of code can be everywhere in the namespace.
> > > It is not required to be under one particular GPIO device as long as there is an operation region defined in that scope.
> > >
> > > The problem is the installation, the first parameter for
> > > acpi_install_address_space_handler() is a namespace node, the function
> > > will call _REG for all OperationRegions below the scope whose top most
> > > node is the specified node.
> > > The nodes out of this scope are not affected.  So if an OperationRegion
> > > is defined out of this scope, problem happens.
> > 
> > I suppose for that operation region another GPIO device should be
> > introduced then, no?
> 
> I believe the answer is no.

Consider a situation, where you have two different GPIO controllers and the
ASL code needs to access GPIOs on both controllers. That requires
introducing two GPIO devices in ACPI namespace and two separate drivers as
well.

> 
> > So if we don't have a GPIO driver for the given operation region, what can
> > we do? We don't want the ASL code to erroneusly think that there is an
> > operation region available when it is not.
> 
> I think GPIO "address_space_handler" should be provided by an ACPI GPIO
> address space module rather than provided by a particular GPIO driver.
> 
> Actually, without the readiness of the GPIO driver, currently ASL code
> can still access the GPIO fields, though it just results in "handler not
> found" ACPICA error message.  If the "setup" callback is implemented,
> then the proper GPIO driver can be matched in this "setup" callback.  If
> the GPIO driver hasn't been loaded by Linux and thus not matched in the
> "setup" callback, from users' point of view, the result is just changing
> the error message from "handler not found" to "driver not found".

Well, I'm fine implementing a single global GPIO region handler (instead of
what is done in this series).

Rafael, do you have any comments on this?
--
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/