Sorry I did not send this out sooner -- I rewrote it a several
different times over the last week to play with some ideas...
Nonetheless, here's the simple bit of ASL I'm using for GPIO right
now:
Scope (\_SB)
{
// Base Address: 0x11400000
Device (GPA0) // GPIO controller GPA0
{
Name (_HID, "LINA0002")
Name (_UID, 0x00)
Method (_CRS, 0x0, Serialized)
{
Name(RBUF, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0x11400000,
0x18)
GpioIo (Exclusive,
PullDefault,
, // debounce timeout
, // drive strength
, // IO restriction
"GPA0")
{ // pin numbers
0x00,
0x01,
0x02,
0x03,
0x04,
0x05,
0x06,
0x07
}
})
Return(RBUF)
}
}
}
This is still not quite working in the Samsung gpiolib code just yet.
They never really used FDT before (or at least, not in a way I would
consider proper) so I'm having to unwind some partial movement to FDT
and their specific data structures.
GPIO interrupts are not going to be much different but I don't have a
good example to send out just yet.
You should be able to figure out the address from the current FDT.
The pin numbers are much better hidden in
mach-exynos/include/mach/gpio.h. Sometimes it's easier just to read
them from /sys :).
I put this in an SSDT just for grins, but it can also go in the DSDT.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone(a)linaro.org
-----------------------------------
Hi Everyone,
I have combined our work on armv7 and armv8 into one branch based on 3.10rc6
mainline kernel. This is newer than our previous base which was 3.9 based.
This kernel boots on both of our main test platforms
1) Arndale
2) armv8 Foundation Model
The branch is available here.
https://git.linaro.org/gitweb?p=arm/acpi/acpi.git;a=shortlog;h=refs/heads/a…
I have attached to the email the two configs I used.
I would suggest that we use this is a base for ongoing work so its easy to
switch between model and hardware for tests.
Thanks
Graeme
Hi,
I think the upstreaming session I was talking about at standup is this one.
http://lce-13.zerista.com/event/member/81058
I suggest that even though this clashes with hacking sessions most of the
team should go to this to prevent Greg KH using you as an example at future
connects.
For those who were not at last connect here is the video of Gregs talk
https://www.youtube.com/watch?v=iiED1K98lnw
Thanks
Graeme
Hi Guys,
I have just pushed this series of patches to the official repo.
Branch is acpi-armv8
This brings us to the same state in armv8 as we are in for armv7. Without
the prototype stuff like i2c drivers. But is a base to start work on
for armv8.
I have tried to get these patches as checkpatch clean as possible.
I want to try and merge armv7 and armv8 changes into one and maintain that
together as I think there is very little different in the two platforms
from the point of initialisation or drivers.
Thanks
Graeme
Hi,
I have managed to get us to boot as far as the dreaded
> ACPI: Interpreter enabled
state on armv8 now.
For now ACPI tables cannot be bigger than 1MB in size (we are nowhere near
this size). And also FDT cannot be bigger than 1MB (still nowhere near).
>From the conversion which was mostly changing
u32 -> void *
u32 -> phys_addr_t
and adding the correct initialisation to the setup.c on armv8 it is becoming
clear that with the correct universal types used that the arch/arm/kernel/acpi
and arch/arm64/kernel/acpi are actually mostly generic to both platforms so we
will need to decide where to put them.
This genericness is nice to have as it means we should be able to switch
v7/v8 at will for testing!
There is still some code from armv7 that I have not yet brought over to v8
and someone fluent in v8 assembler needs to fix the two assembly bits.
I shall continue to bring code over and enable more ACPI features.
Graeme