| Message ID | 20190513075641.1277716-2-lkundrak@v3.sk (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | Add support for OLPC XO 1.75 Embedded Controller | expand |
On Mon 2019-05-13 09:56:32, Lubomir Rintel wrote: > The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra > signals for handshaking. It needs to know when is the slave (Linux) > side's TX FIFO ready for transfer (the ready-gpio signal on the SPI > controller node) and when does it wish to respond with a command (the > cmd-gpio property). > > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> > Acked-by: Pavel Machek <pavel@ucw.cz> > Reviewed-by: Rob Herring <robh@kernel.org> Who is expected to apply this? I don't think more iterations will make it better... it seems pretty good already :-). Pavel
On Mon, 2019-05-13 at 11:07 +0200, Pavel Machek wrote: > On Mon 2019-05-13 09:56:32, Lubomir Rintel wrote: > > The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra > > signals for handshaking. It needs to know when is the slave (Linux) > > side's TX FIFO ready for transfer (the ready-gpio signal on the SPI > > controller node) and when does it wish to respond with a command (the > > cmd-gpio property). > > > > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> > > Acked-by: Pavel Machek <pavel@ucw.cz> > > Reviewed-by: Rob Herring <robh@kernel.org> > > Who is expected to apply this? I don't think more iterations will make > it better... it seems pretty good already :-). The whole set is meant to go in through platform/x86; it just missed 5.2 due to some issues discovered by the kbuild bot when it entered Andy's review queue. > > Pavel >
On Mon, May 13, 2019 at 4:18 PM Lubomir Rintel <lkundrak@v3.sk> wrote: > > On Mon, 2019-05-13 at 11:07 +0200, Pavel Machek wrote: > > On Mon 2019-05-13 09:56:32, Lubomir Rintel wrote: > > > The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra > > > signals for handshaking. It needs to know when is the slave (Linux) > > > side's TX FIFO ready for transfer (the ready-gpio signal on the SPI > > > controller node) and when does it wish to respond with a command (the > > > cmd-gpio property). > > > > > > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > Reviewed-by: Rob Herring <robh@kernel.org> > > > > Who is expected to apply this? I don't think more iterations will make > > it better... it seems pretty good already :-). > > The whole set is meant to go in through platform/x86; it just missed > 5.2 due to some issues discovered by the kbuild bot when it entered > Andy's review queue. It will be promoted in a few days to our for-next.
Hi! What is status of OLPC-1.75 in v5.3? IIRC most of the patches went in, but I don't see suitable dts file in the tree. I tried porting one from working (4.19 or so) kernel, but it was not quite trivial. Is there time for dts to be merged? Thanks, Pavel
Hello Pavel, On Thu, 2019-08-01 at 21:27 +0200, Pavel Machek wrote: > Hi! > > What is status of OLPC-1.75 in v5.3? IIRC most of the patches went in, > but I don't see suitable dts file in the tree. I tried porting one > from working (4.19 or so) kernel, but it was not quite trivial. > > Is there time for dts to be merged? Short answer is that it's not absolutely necessary. With a new enough OpenFirmware, the firmware will just construct a correct FDT. To upgrade your machine to the new firmware, just copy http://dev.laptop.org/~quozl/q4e00ja.rom to a FAT partition on a USB flash stick and run "flash u:\q4e00ja.rom" from the "ok" prompt. Then you'll be able to run stock mainline kernels happily. That said, it might still be useful to have a DTS file in tree (for reference, testing, machines with older firmware, etc.). I've now re- sent the MMP2 devicetree update patch set with the DTS file included and copied you on that one. As usual, I'm thankful for testing, reviews and acks. Take care! Lubo
Hi! > > What is status of OLPC-1.75 in v5.3? IIRC most of the patches went in, > > but I don't see suitable dts file in the tree. I tried porting one > > from working (4.19 or so) kernel, but it was not quite trivial. > > > > Is there time for dts to be merged? > > Short answer is that it's not absolutely necessary. With a new enough > OpenFirmware, the firmware will just construct a correct FDT. > To upgrade your machine to the new firmware, just copy > http://dev.laptop.org/~quozl/q4e00ja.rom to a FAT partition on a USB > flash stick and run "flash u:\q4e00ja.rom" from the "ok" prompt. > Then you'll be able to run stock mainline kernels happily. Aha, good, thanks. That went smoothly. > That said, it might still be useful to have a DTS file in tree (for > reference, testing, machines with older firmware, etc.). I've now re- > sent the MMP2 devicetree update patch set with the DTS file included > and copied you on that one. Yes: sometimes it is neccessary to modify the dts. I was changing the kernel command line, for example. > As usual, I'm thankful for testing, reviews and acks. I'll take a look. I tried 5.2 with defconfig from one of the branches (olpc_xo175_defconfig), and that does not boot. What config should I use? Is it enough to produce zImage and put it on the flashdisk with olpc.fth file? Is there some kind of documentation somewhere? :-). Thanks and best regards, Pavel
----- On Aug 3, 2019, at 10:47 AM, Pavel Machek pavel@ucw.cz wrote: > Hi! > >> > What is status of OLPC-1.75 in v5.3? IIRC most of the patches went in, >> > but I don't see suitable dts file in the tree. I tried porting one >> > from working (4.19 or so) kernel, but it was not quite trivial. >> > >> > Is there time for dts to be merged? >> >> Short answer is that it's not absolutely necessary. With a new enough >> OpenFirmware, the firmware will just construct a correct FDT. > >> To upgrade your machine to the new firmware, just copy >> http://dev.laptop.org/~quozl/q4e00ja.rom to a FAT partition on a USB >> flash stick and run "flash u:\q4e00ja.rom" from the "ok" prompt. >> Then you'll be able to run stock mainline kernels happily. > > Aha, good, thanks. That went smoothly. > >> That said, it might still be useful to have a DTS file in tree (for >> reference, testing, machines with older firmware, etc.). I've now re- >> sent the MMP2 devicetree update patch set with the DTS file included >> and copied you on that one. > > Yes: sometimes it is neccessary to modify the dts. I was changing the > kernel command line, for example. Well, you can do that from OFW too. E.g.: " console=ttyS2,115200" to boot-file >> As usual, I'm thankful for testing, reviews and acks. > > I'll take a look. I tried 5.2 with defconfig from one of the branches > (olpc_xo175_defconfig), and that does not boot. I'm using [1]. [1] https://raw.githubusercontent.com/hackerspace/olpc-xo175-linux/lr/olpc-xo175/arch/arm/configs/olpc_xo175_defconfig I'm wondering if it would make sense to include this upstream? My guess was that nowadays multi_v7_defconfig that just works on any DT-based platform is preferred to machine specific ones. However, this one would enable OLPC-specific drivers the multi_v7_defconfig defconfig wouldn't. I've sent out an update to multi_v7_defconfig [2]. Once it is applied, it should work on the XO-1.75 (without fancy things like camera or power button). [2] https://lore.kernel.org/lkml/20190620114816.1387881-1-lkundrak@v3.sk/ > What config should I use? Is it enough to produce zImage and put it on > the flashdisk with olpc.fth file? Yes. OFW loads olpc.fth from the first active FAT or ext3 partition on SD card or a USB flash drive. If you put the zImage in the same place, the following script would work: \ OLPC boot script " last:\zImage" to boot-device visible unfreeze boot Note that it has to start with a backslash. The "visible" and "unfreeze" words enable the DCON pass-through mode. You would see the XO logo instead of the actual screen output without it. > Is there some kind of documentation somewhere? :-). This is always a tough question. Short answer would be no. I'm happy to answer questions though, if the above wouldn't be sufficient to make the thing boot for you. I'd prefer if things just worked to documenting how to hack things to make them work. If you got a Fedora machine, you can already just pick a nightly [1] armhfp image and install it with fedora-arm-installer the same way as any other ARM machine. I hope to make Debian work too. An image that already boots would then hopefully be a good start for whoever wishes to run their own kernels. That's my excuse for not documenting things... [1] https://www.happyassassin.net/nightlies.html > Thanks and best regards, > Pavel Take care Lubo > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi! > I'm using [1]. > > [1] https://raw.githubusercontent.com/hackerspace/olpc-xo175-linux/lr/olpc-xo175/arch/arm/configs/olpc_xo175_defconfig > Thanks a lot. I got it to work with 5.2 and 5.3-rc. One thing I noticed... "reboot: Restarting system", "Reboot failed --- System halted". > I'm wondering if it would make sense to include this upstream? > My guess was that nowadays multi_v7_defconfig that just works > on any DT-based platform is preferred to machine specific ones. > > However, this one would enable OLPC-specific drivers the > multi_v7_defconfig defconfig wouldn't. Yes, I believe that would be useful. Getting all the extras without that would be quite tricky. > > Is there some kind of documentation somewhere? :-). > > This is always a tough question. Short answer would be no. > > I'm happy to answer questions though, if the above wouldn't be > sufficient to make the thing boot for you. Ok, it seems to work now ;-). I'll make some notes... Best regards, Pavel
On Wed, 2019-08-07 at 14:31 +0200, Pavel Machek wrote: > Hi! > > > I'm using [1]. > > > > [1] https://raw.githubusercontent.com/hackerspace/olpc-xo175-linux/lr/olpc-xo175/arch/arm/configs/olpc_xo175_defconfig > > > > Thanks a lot. I got it to work with 5.2 and 5.3-rc. One thing I > noticed... > > "reboot: Restarting system", "Reboot failed --- System halted". Yes. Another unhappy Russel issue, if it's fair to put it that way. :) Ideas appreciated. https://lore.kernel.org/lkml/20190108233137.GW11171@n2100.armlinux.org.uk/ > > > I'm wondering if it would make sense to include this upstream? > > My guess was that nowadays multi_v7_defconfig that just works > > on any DT-based platform is preferred to machine specific ones. > > > > However, this one would enable OLPC-specific drivers the > > multi_v7_defconfig defconfig wouldn't. > > Yes, I believe that would be useful. Getting all the extras without > that would be quite tricky. Okay, I'll take a mental note to send it out eventually. > > > Is there some kind of documentation somewhere? :-). > > > > This is always a tough question. Short answer would be no. > > > > I'm happy to answer questions though, if the above wouldn't be > > sufficient to make the thing boot for you. > > Ok, it seems to work now ;-). I'll make some notes... That's cool. > > Best regards, > > Pavel Take care Lubo
diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt new file mode 100644 index 000000000000..8c4d649cdd8f --- /dev/null +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt @@ -0,0 +1,23 @@ +OLPC XO-1.75 Embedded Controller + +Required properties: +- compatible: Should be "olpc,xo1.75-ec". +- cmd-gpios: gpio specifier of the CMD pin + +The embedded controller requires the SPI controller driver to signal readiness +to receive a transfer (that is, when TX FIFO contains the response data) by +strobing the ACK pin with the ready signal. See the "ready-gpios" property of the +SSP binding as documented in: +<Documentation/devicetree/bindings/spi/spi-pxa2xx.txt>. + +Example: + &ssp3 { + spi-slave; + ready-gpios = <&gpio 125 GPIO_ACTIVE_HIGH>; + + slave { + compatible = "olpc,xo1.75-ec"; + spi-cpha; + cmd-gpios = <&gpio 155 GPIO_ACTIVE_HIGH>; + }; + };