On 06/19/18 08:52, Rob Herring wrote: > On Mon, Jun 18, 2018 at 1:45 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> This is a proposal for how to handle the non-discoverable >> 96boards plug-in expansion boards called "mezzanines" in the >> Linux kernel. It is a working RFC series meant for discussion >> at the moment. >> >> The RFC was done on the brand new Ultra96 board from Xilinx >> with a Secure96 mezzanine expansion board. The main part >> is in patch 4, the rest is enabling and examples. >> >> The code can be obtained from here: >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96 >> >> You can for example probably augment the DTS file for any >> upstream-supported 96board and get the Secure96 going with >> it with minor efforts. >> >> TODO: >> >> - Proper device tree bindings for the connector, for now >> look at the example. >> >> - Discuss whether to actually do this or just take it all and >> flush it down the drain because the community doesn't like >> it. I'm not one of those especially infatuated with my own code, >> I always stay by the old programming project management mantra >> to calculate to make one version and throw it away as stepping >> stone to a good final design. >> >> - Placement: putting this in drivers/bus is just an example. >> drivers/platform/96boards-mezzanines is fine too, maybe better? >> >> - I am especially curious about input from Andy and Mika from >> the Intel/ACPI camp on what they have seen for non-discoverable >> plug-in boards. Does this problem even exist in the Intel >> world, or not... >> >> Background: >> >> - These boards connect on a custom connector on this family >> of boards. The relationship is many-to-many with the connector >> as nexus. The electronic standard for the connector is specified: >> https://github.com/96boards/documentation/blob/master/Specifications/96Boards-CE-Specification.pdf >> Example mezzanines: >> https://www.96boards.org/documentation/mezzanine/ >> >> - These boards have siblings on other platforms, the problem >> scope is similar with BeagleBone "capes": >> https://beagleboard.org/capes >> Raspberry Pi expansion boards: >> https://www.abelectronics.co.uk/products/18/raspberry-pi-expansion-boards >> Intel Edison, Galileo, Joule also have expansion boards. >> >> Idea: add a driver for the connector itself and tie it in to >> the device tree with a compatible string. Since the boards >> are non-discoverable two mechanisms are provided to discover >> them: >> >> - Add a very simple device tree node with just a compatible >> string for the board in the node. This will be simple to >> add from e.g. a boot loader or as an overlay from userspace. >> >> board { >> compatible = "96boards,secure96"; >> }; >> >> >> - Echo 1 > boardname into a sysfs file to populate the >> board and echo 0 > boardname to depopulate it. This >> makes it easy to even switch out expansion boards at >> runtime, if allowed by the electronics. >> >> > cd /sys/devices/platform/connector >> > echo 1 > secure96 >> lscon connector: called mezzanine_store on secure96 >> lscon connector: populate secure96 >> at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write >> atmel-ecc 1-0060: configuration zone is unlocked >> tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16) >> (...) >> >> What this patch set does not do: >> >> - It does not use device tree or ACPI DSDT or any other >> hardware decription language to model the contents of the >> board per se. Instead the boards buses are populated >> directly with platform devices. >> >> Predictable complaints about this design: >> >> Q: This is not device tree overlays. Why is it not device >> tree overlays? >> >> A1: Right tool for the job, overlays are complex and the >> plan to get it in place seems to be spanning years, this >> is a few devices on simple busses and it works today. >> Using this approach I can already work on shaping up >> drivers for the mezzanine board devices as proved by: >> https://marc.info/?l=linux-crypto-vger&m=152820660120590&w=2 >> https://marc.info/?l=linux-crypto-vger&m=152820662820595&w=2 >> (...) >> >> I can work on drivers for the chips on the >> Secure96 mezzanine board. It's just an example of >> what the mezzanine community can do. >> Now they are hacking around in userspace instead of >> doing/reusing kernel drivers for their stuff: >> https://github.com/jbech-linaro/secure96 >> >> This way we can bring developers for these components >> into the kernel community instead of telling them to >> wait for some big infrastructure that comes later >> before they can contribute their stuff. >> >> A2: Overlays does not solve the problem if the system runs >> ACPI, and what about if the same connector[s] appear >> on a server board, servers use ACPI. Also notice >> that Intel have development boards with non-discoverable >> expansion boards as well. They just will not use >> device tree. >> >> A3: Overlays is Big Upfront Design. >> https://en.wikipedia.org/wiki/Big_Design_Up_Front >> This way of designing things is associated with the >> (pejorative term) "waterfall model" which is out of >> fashion as a way of doing development. I think I am not >> the only one slightly annoyed by the fact that device >> tree overlays is now starting to look like a very >> big very upfront design. It's just not possible to get >> something up and running in small iterative steps with >> device tree overlays. Instead huge efforts are >> required and it involves major possible showstoppers >> and uncertain outcome as indicated by Frank's TODO: >> https://elinux.org/Frank's_Evolving_Overlay_Thoughts > > I don't agree. This can be broken down into various smaller mostly > independent problems. Overlay handling is mostly an orthogonal > problem. The exception is that we need to ensure bindings allow a > decoupling of upstream of the connector and downstream of the > connector so the downstream part can be a reusable overlay. Defining > anything while ignoring this known criteria would be a mistake. > > The list is roughly like this: > > - Connector node binding and probing infrastructure > - GPIO (already done w/ gpio-map binding) > - I2C > - SPI > - Pinmux > - clocks > - OF graph (displays, cameras, etc.) > - USB (re-use the USB connector binding for non-standard connectors) > - Userspace interface > > We don't have to support every interface from the start. The bindings > and corresponding kernel support can be designed 1-by-1 for the most > part. Start with something simple like a GPIO LED on a mezzanine. Once > the base is functionality is there, the other parts can be worked on > incrementally. We can punt any overlay handling to the bootloader > initially. That punts all the issues around overlays like designing a > userspace interface, where overlays are located (filesystem, passed > from bootloader, built into the kernel), when they are loaded, and how > to specify which overlays to load. Most of Frank's list is related to > these issues. > > Rob > Agreeing with Rob (despite my other reply asking why the current devicetree mechanisms can't be used) that we do have a desire to have the ability to create bindings for connectors - this has been discussed before. -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
