On 01/14/2014 07:59 AM, Tomasz Nowicki wrote:
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
I had thought about structuring this the way Tomasz suggested; in fact, I would still prefer to do that -- it seems the right way to handle it.
And I agree with Graeme that it may be hard to do -- the APIs are so very different in so many odd ways.
That difficulty is partly why this prototype looks like it does. But, I was also trying to see if I could make this work by not changing any code in the driver itself. Or, if that was not possible, make the API so that you could just do "sed 's/of_*/gufi_*/g'" on the source and it would be mostly done. That is, ideally, absolute minimal changes in order to enable ACPI. If we go to a combined/abstracted API (the more elegant solution, truth be told), every driver would eventually need to change should GUFI become the default, and that's a lot of work.
The other thing I was thinking about at the time was the idea of having some way to support development or transition. For example, just like we have been doing, suppose I have a DT-based driver I am converting to ACPI. If GUFI could allow me to intermix the two while I'm making the changes -- i.e., get some info from DT, some from ACPI -- then I can do incremental changes. If we use the protocol idea, that may still be possible, but I'd have to think that through some more.
That being said, perhaps these things should not be requirements; patches are always welcome :), and I'm definitely going to step back and play with the idea of the protocol method more seriously just to see what happens.
Oh, the other concern I have is I would like to avoid creating an API just to have an API. The chances of getting that upstream I assume are nil. Features like those mentioned above would help keep that from happening.
BTW, thanks for all the comments -- that's exactly the sort of feedback I was hoping to get.
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