[Arm-netbook] devicetree and testing

[Richard Wilbur]

On Apr 16, 2018, at 22:04, Luke Kenneth Casson Leighton <***@lkcl.net>
wrote:
On Tue, Apr 17, 2018 at 4:53 AM, Richard Wilbur <***@gmail.com>
wrote:
I am working on the devicetree for the microdesktop v1.7 and the DS113
v2.7.5 as it sounds like that is the natural prerequisite to
auto-configuration and more-automated testing.

awesome. remember though that testing will be done with 3.4.104+ as it's
where 100% of the functionality is present.

If I'm understanding you correctly the 3.4.104 kernel is the most recent
kernel to have free support for all the promised functionality of the
DS-113, but lacks devicetree support to make that functionality
autoconfigurable? That is a beastly spot to be in! In that case I'll make
the manual tables from which we can initially code up some tests by using
the gpio driver and later write up the devicetree.

So, sorry for being a bit thick headed, it just dawned on me what our
priorities have to be and why:

1. Hack together some tests under 3.4.104 that we can run on the extant
drivers.
2. Work on getting extant A20 drivers mainlined in the linux kernel.
3. Create devicetree for DS113 v2.7.4 and v2.7.5, … (all extant versions
of DS113 and microdesktop case).
4. Work on getting devicetree with add/remove overlay support mainlined in
the linux kernel (and u-boot?).

--Richard
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 17, 2018 at 9:54 PM, Richard Wilbur

Post by Richard Wilbur
I am working on the devicetree for the microdesktop v1.7 and the DS113
v2.7.5 as it sounds like that is the natural prerequisite to
auto-configuration and more-automated testing.
awesome. remember though that testing will be done with 3.4.104+ as it's
where 100% of the functionality is present.
If I'm understanding you correctly the 3.4.104 kernel is the most recent
kernel to have free support for all the promised functionality of the
DS-113, but lacks devicetree support to make that functionality
autoconfigurable?

that's correct.

Post by Richard Wilbur
That is a beastly spot to be in!

yyup.

Post by Richard Wilbur
In that case I'll make
the manual tables from which we can initially code up some tests by using
the gpio driver and later write up the devicetree.

yep.

Post by Richard Wilbur
So, sorry for being a bit thick headed, it just dawned on me what our

:)

Post by Richard Wilbur
1. Hack together some tests under 3.4.104 that we can run on the extant
drivers.
2. Work on getting extant A20 drivers mainlined in the linux kernel.

people have been working on that for many many years.

Post by Richard Wilbur
3. Create devicetree for DS113 v2.7.4 and v2.7.5, … (all extant versions
of DS113 and microdesktop case).
4. Work on getting devicetree with add/remove overlay support mainlined in
the linux kernel (and u-boot?).

yes.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send la

[Richard Wilbur]

Post by Luke Kenneth Casson Leighton
On Tue, Apr 17, 2018 at 9:54 PM, Richard Wilbur
[…]

Post by Richard Wilbur
1. Hack together some tests under 3.4.104 that we can run on the extant
drivers.
2. Work on getting extant A20 drivers mainlined in the linux kernel.

people have been working on that for many many years.

Post by Richard Wilbur
3. Create devicetree for DS113 v2.7.4 and v2.7.5, … (all extant versions
of DS113 and microdesktop case).
4. Work on getting devicetree with add/remove overlay support mainlined in
the linux kernel (and u-boot?).

yes.

I understand that people have been working on steps 2 and 4 for years and I had no diminution of their efforts in mind.

In my estimation the tasks that can be completed relatively quickly are 1 and 3 as they don't require convincing anyone else of the importance of the goal or merit of the implementation.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb

[Luke Kenneth Casson Leighton]

On Tue, Apr 17, 2018 at 11:12 PM, Richard Wilbur

Post by Richard Wilbur
I understand that people have been working on steps 2 and 4 for years and I had no diminution of their efforts in mind.

absolutely.

Post by Richard Wilbur
In my estimation the tasks that can be completed relatively quickly are 1 and 3 as they don't require convincing anyone else of the importance of the goal or merit of the implementation.

it is slightly more complex (3 that is) because a library and
associated linux kernel device-driver has to also be written that
reads from the I2C EEPROM (to be added to both u-boot and the linux
kernel), in order to use the devicetree fragment merging... overlay!
that's what it's called.

it is *not* going to be okay to just blop in one devicetree file for
eoma68-a20-with-microdesktop, one devicetree file for
eoma68-rk3288-with-microdesktop, one devicetree file for
eoma68-a20-with-laptop-housing, one devicetree file for
eoma68-rk3288-with-laptop-housing etc. etc.

preventing that kind of insane O(N * M) devicetree proliferation and
reducing it down to O(N + M) *IS* the entire point of the EOMA68
initiative.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large att

[Richard Wilbur]

On Apr 17, 2018, at 16:17, Luke Kenneth Casson Leighton <***@lkcl.net>
wrote:

On Tue, Apr 17, 2018 at 11:12 PM, Richard Wilbur
<***@gmail.com> wrote:

In my estimation the tasks that can be completed relatively quickly are 1
and 3 as they don't require convincing anyone else of the importance of the
goal or merit of the implementation.


it is slightly more complex (3 that is) because a library and
associated linux kernel device-driver has to also be written that
reads from the I2C EEPROM (to be added to both u-boot and the linux
kernel), in order to use the devicetree fragment merging... overlay!
that's what it's called.

it is *not* going to be okay to just blop in one devicetree file for
eoma68-a20-with-microdesktop, one devicetree file for
eoma68-rk3288-with-microdesktop, one devicetree file for
eoma68-a20-with-laptop-housing, one devicetree file for
eoma68-rk3288-with-laptop-housing etc. etc.

preventing that kind of insane O(N * M) devicetree proliferation and
reducing it down to O(N + M) *IS* the entire point of the EOMA68

I agree wholeheartedly with the modular mix and match overlay fragment
design but saw the software support for it in what I had labelled as
priority 4. Whereas I understood priority 3 to entail creating the
devicetree fragments for the EOMA hardware that already exists.


1. Hack together some tests under 3.4.104 that we can run on the extant

drivers.

2. Work on getting extant A20 drivers mainlined in the linux kernel.

3. Create devicetree [fragments] for DS113 v2.7.4 and v2.7.5, … (all
extant versions

of DS113 and microdesktop case).

4. Work on getting devicetree with [fragment] add/remove overlay support
mainlined in

the linux kernel (and u-boot?).


Let me restate without relying only on numbers to identify the tasks:
We can create the tests to run on 3.4.104 kernel (priority 1) and the
devicetree overlays or fragments for each version of the processor card and
microdesktop case (priority 3) without buy in from anyone else.

Getting the A20 drivers mainlined in the linux kernel (priority 2) and
devicetree fragment overlay add/remove support in the linux kernel and
u-boot (priority 4) will require continued collaboration with those who
maintain the linux kernel and u-boot. Others have already been working on
this effort for several years.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large at

[Luke Kenneth Casson Leighton]

On Wed, Apr 18, 2018 at 1:46 PM, Richard Wilbur

Post by Richard Wilbur
I agree wholeheartedly with the modular mix and match overlay fragment
design but saw the software support for it in what I had labelled as
priority 4. Whereas I understood priority 3 to entail creating the
devicetree fragments for the EOMA hardware that already exists.

ok sorry didn't quite read clearly, just spotted that 3 wasn't clear.

looks great to me, richard.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Se

[Jonathan Neuschäfer]

On Tue, Apr 17, 2018 at 02:54:29PM -0600, Richard Wilbur wrote:
[...]

Post by Richard Wilbur
So, sorry for being a bit thick headed, it just dawned on me what our
1. Hack together some tests under 3.4.104 that we can run on the extant
drivers.
2. Work on getting extant A20 drivers mainlined in the linux kernel.

In case you haven't seen it (although you probably have), Paul
Kocialkowski is working on a mainline driver for the video encode/decode
unit in allwinner SoCs:

https://bootlin.com/blog/allwinner-vpu-support-in-mainline-linux-status-update-week-15/

Post by Richard Wilbur
3. Create devicetree for DS113 v2.7.4 and v2.7.5, … (all extant versions
of DS113 and microdesktop case).
4. Work on getting devicetree with add/remove overlay support mainlined in
the linux kernel (and u-boot?).

BTW, the GPIO nexus patch by Stephen Boyd was merged for 4.17:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd6f2fd5a1d52198468c5cdc3c2472362dff5aaa

As far as I understand it, this new syntax will be useful for specifying
devicetree overlays that work with multiple different SoCs.


Jonathan Neuschäfer
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Apr 18, 2018 at 2:50 PM, Jonathan Neuschäfer

Post by Jonathan Neuschäfer
[...]

Post by Richard Wilbur
So, sorry for being a bit thick headed, it just dawned on me what our
1. Hack together some tests under 3.4.104 that we can run on the extant
drivers.
2. Work on getting extant A20 drivers mainlined in the linux kernel.

In case you haven't seen it (although you probably have), Paul
Kocialkowski is working on a mainline driver for the video encode/decode
https://bootlin.com/blog/allwinner-vpu-support-in-mainline-linux-status-update-week-15/

great! we like paul.

Post by Jonathan Neuschäfer

Post by Richard Wilbur
3. Create devicetree for DS113 v2.7.4 and v2.7.5, … (all extant versions
of DS113 and microdesktop case).
4. Work on getting devicetree with add/remove overlay support mainlined in
the linux kernel (and u-boot?).

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd6f2fd5a1d52198468c5cdc3c2472362dff5aaa
As far as I understand it, this new syntax will be useful for specifying
devicetree overlays that work with multiple different SoCs.

thx jonathan.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co