ACPI

[Grant Likely]

On Tue, 26 Nov 2013 14:43:30 +0100, Jürgen Beisert <jbe at pengutronix.de> wrote:
> On Tuesday 26 November 2013 13:55:10 Grant Likely wrote:
> > On Tue, Nov 26, 2013 at 12:43 PM, Linus Walleij
> >
> > <linus.walleij at linaro.org> wrote:
> > > On Mon, Nov 25, 2013 at 4:41 PM, Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> > >> In the past ACPI implementations handled GPIO by providing
> > >> methods that accessed hardware registers directly. I've seen DSDTs that
> > >> implement i2c entirely in ASL.
> > >
> > > Is that common?
> > >
> > > Since i2c is a slow bus, can be 100kHz or so, how does that
> > > avoid locking the entire CPU while e.g. waiting for transactions on
> > > the external bus to complete?
> > >
> > > In I2C drivers we typically use completion IRQs so that we can
> > > do other stuff when the I2C traffic is busy ...
> > >
> > > I have a feeling we should not recommend ARM implementers
> > > to go and do things like this.
> >
> > ACPI5 defines a binding for serial busses (i2c & spi) which allows
> > real device drivers to drive the bus and allows ACPI and the kernel to
> > share the bus safely. Using that binding means some i2c devices can be
> > 'owned' by ACPI and others owned by the kernel.
> 
> This means bus locking. And Linus' other question about CPU locking while ACPI
> drives the I2C bus?

It means Linux owns the I2C bus and AML methods request the OS to
perform a transaction on its behalf.

g.