Messages in this thread | | | Date | Wed, 24 Feb 2010 08:49:50 +0200 | From | Mike Rapoport <> | Subject | Re: [PATCH v3 3/3] gpio: add Intel SCH GPIO controller driver |
| |
David Brownell wrote: > On Sunday 21 February 2010, Denis Turischev wrote: >> v2: there is no acpi_check_region, it will be implemented in mfd-core >> v3: patch refreshed against the latest Linus tree > > Could such call really address the GPIO conflict issue I mentioned? > > The AML bytecodes I looked at were writing directly to Southbridge > GPIO registers (or reading them), or relying on ACPI to mediate the > GPIO interrupts. ISTR that button drivers, and code to switch into > or out of low power states, were good sources of such bad examples.
I'm really not an ACPI expert, but as far as I understand possibility of such conflicts largely depends on particular board/BIOS implementation. On the hardware we have such conflict cannot happen, unless there are bugs in ACPI we are not yet aware of. :)
> Calls like that should clearly be able to handle cases where ACPI > has a "Real" Driver (tm) ... e.g. for SMBus hardware. > > I'm not sure what a good solution for this would be, short of just > not using ACPI ... which may not be practical, given the limited > degree of x86 board/system support for Linux. > > I mention this mostly because when I looked at the issue in the > context of an ICHx GPIO driver, I didn't see a good solution to > the problem then ... and nothing seems to have changed meanwhile.
I've looked at two x86 drivers in drivers/gpiolib (cs5535 and langwell) and there's no treatment of ACPI in either of them. Since SCH is defined by Intel as "embedded" product, having a GPIO driver for it seems logical even despite problems you mention.
> - Dave > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
-- Sincerely yours, Mike.
| |