[v7,01/10] dt-bindings: olpc,xo1.75-ec: Add OLPC XO-1.75 EC bindings
diff mbox series

Message ID 20190513075641.1277716-2-lkundrak@v3.sk
State Not Applicable, archived
Headers show
Series
  • Add support for OLPC XO 1.75 Embedded Controller
Related show

Commit Message

Lubomir Rintel May 13, 2019, 7:56 a.m. UTC
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>

---
Changes since v5:
- Added Rob Herring's Reviewed-by tag

Changes since v1:
- s/cmd-gpio/cmd-gpios/
- s/ready-gpio/ready-gpios/ in the documentation paragraph
- Remove status = "okay" from the example

 .../bindings/misc/olpc,xo1.75-ec.txt          | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt

Comments

Pavel Machek May 13, 2019, 9:07 a.m. UTC | #1
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
Lubomir Rintel May 13, 2019, 1:18 p.m. UTC | #2
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
>
Andy Shevchenko May 24, 2019, 4:29 p.m. UTC | #3
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.
Pavel Machek Aug. 1, 2019, 7:27 p.m. UTC | #4
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
Lubomir Rintel Aug. 2, 2019, 10:39 a.m. UTC | #5
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
Pavel Machek Aug. 3, 2019, 8:47 a.m. UTC | #6
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
Lubomir Rintel Aug. 5, 2019, 10:26 a.m. UTC | #7
----- 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
Pavel Machek Aug. 7, 2019, 12:31 p.m. UTC | #8
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
Lubomir Rintel Aug. 7, 2019, 12:41 p.m. UTC | #9
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

Patch
diff mbox series

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>;
+		};
+	};