W dniu 01/14/14 15:52, Graeme Gregory pisze:
On Tue, Jan 14, 2014 at 12:03:04PM +0100, Tomasz Nowicki wrote:
W dniu 12/10/13 01:13, al.stone@linaro.org pisze:
From: Al Stone al.stone@linaro.org
These patches are purely experimental; they just barely compile and they do not run just yet. The reason for posting them is really just to stir some discussion and see if this is a truly crazy idea or if it has some potential for easing the ACPI transition.
These patches introduce GUFI: the Grand Unified Firmware Interface. Okay, yes, it is a silly name. I didn't spend a lot of time on it. What I'm most interested in is the idea and whether it is worth pursuing further, and whether or not there are better ways to do this if it does make sense.
The idea is very simple: introduce a shim layer that looks like a merge of some sort between ACPI and FDT functionality in the kernel. In that shim layer, make it possible for a driver to make a single call to a function, and with that call, retrieve configuration information stored in either ACPI tables or a DT. Further, allow the kernel to specify which has priority -- i.e., search through ACPI tables, and then through FDT if data is not found, or vice versa -- or which is exclusive, either ACPI or FDT only.
Why would I do this? As a kernel developer, this allows me to make changes in the direction of either FDT or ACPI as quickly or as slowly as I want to. Most of my config can be in FDT and I can then piecemeal convert to ACPI as I figure out ASL and/or any driver changes that may be needed. Secondly, if I do this well, the changes to convert from FDT to ACPI *should* be very small; from ACPI to FDT may be much more difficult but over time that can likely be improved as well. Third, in the really, really long term, maybe someone comes up with yet another hardware configuration description format that is so cool it provides sharks with laser beams on their heads and *everyone* wants to convert to it. With this layer in place, perhaps we can smooth even that transition by abstracting out the config info that's needed and the API to retrieve it.
So, what do you think?
Hi Al,
Sorry you had to wait so long.
Here is my 2 cents on this:
- The goal is really noble :)
- AFAIU, that should be generic API for driver binding, which is
hardware configuration independent. But, I can see OF and ACPI specific arguments in GUFI's API. Image how hard would it be to add next h/w description (with laser and turbo on his back :) ).
Hi Tomasz,
you reminded me to look at the patch, I think you are correct about the API, I think it should take dev/pdev arguments only. All the of/acpi stuff should be actually hidden so if your trying to get a config string all the finding correct node/ACPI ASL bit should be invisible.
This may actually be impossible in the non trivial case as it requires ACPI and DT bindings to be pretty identical which is already not going to happen with _PRP method + ACPI native support. I especially expect values hidden in sub-nodes to break.
Right, that was one of my concerns.
Tomasz
Graeme
In my opinion, we could treat GUFI layer like socket with many protocols supported. First step would be to register h/w configuration description handlers to GUFI's list and then use generic GUFI's API in drivers which suppose to dispatch appropriate handler:
struct gufi_protocol of_protoc { .find_node = of_find_compatible_node, .... };
gufi_register_prot(struct gufi_protocol prot) { add_prot_to_gufi_list(prot); ... }
gufi_find_compatible_node(struct gufi_device_node *node) { struct gufi_protocol prot;
/* h/w config description handler dispatch */ prot = find_prot_for_node_from_gufi_list(node); /* Call h/w configuration specific handler */ prot.find_node(args...); }
My two concerns:
- Can we find GUFI's API generic enough to satisfy possible h/w
description. 2. Will it be upstreamed with only two h/w configuration description
- OF and ACPI.
Tomasz
Al Stone (5): ACPI: GUFI: add kernel config options for GUFI ACPI: GUFI: add build commands for drivers/gufi ACPI: GUFI: add in early prototype code for some GUFI functions ACPI: GUFI: add in simple test driver placeholders ACPI: GUFI: start modifying the vexpress-sysreg driver to use the GUFI
arch/arm64/Kconfig | 6 - drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/acpi/acpi_platform.c | 1 + drivers/gufi/Kconfig | 54 ++++++++ drivers/gufi/Makefile | 11 ++ drivers/gufi/gufi.c | 309 ++++++++++++++++++++++++++++++++++++++++++ drivers/gufi/gufi_acpi_test.c | 84 ++++++++++++ drivers/gufi/gufi_of_test.c | 83 ++++++++++++ drivers/mfd/vexpress-sysreg.c | 14 +- include/linux/gufi.h | 83 ++++++++++++ 11 files changed, 636 insertions(+), 12 deletions(-) create mode 100644 drivers/gufi/Kconfig create mode 100644 drivers/gufi/Makefile create mode 100644 drivers/gufi/gufi.c create mode 100644 drivers/gufi/gufi_acpi_test.c create mode 100644 drivers/gufi/gufi_of_test.c create mode 100644 include/linux/gufi.h
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-acpi