Differential D15067
spigen overlays for RPI-B, RPI-2 in base (was: possible new port for spigen overlay for Raspberry Pi) Authored by bobf_mrp3.com on Apr 14 2018, 8:15 PM. Tags None Referenced Files
Details
spigen overlays to be placed into 'base'. one for RPI-B, the other for RPI-2. requires loader.conf 'fdt_overlays' entry for the correct overlay (either spigen-rpi-b.dtbo or spigen-rpi2.dtbo) Implements 3 spigen devices on RPI2, but only 2 on RPi-B. This is because RPi-B uses GPIO16 for an LED, and it therefore cannot be used for SPI. Needs DS15301 if you want a relationship between the cs pin and the spigen device name. overlays tested in -CURRENT along with DS15301, all good. This overlay contains fixes for pins for spi0@7e200000 and spi0_cs_pins. This allows cs==2 on RPI2. Need to verify that RPI2 overlay also works on RPI3 [since they have the same pin assignments]
Diff Detail
Event TimelineComment Actions it seemed to me that a port was the better choice, although I'm not opposed at all to having it in the base. It's just that an overlay like this is not something that's necessarily common to all bcm2835 devices, but is intended for the raspberry pi only. Although, it _could_ become part of the base, I've been told that we're not supposed to edit the dts files, nor patch them, but to use overlays instead. That being said, if the overlay were included in the base, and installed by default, the end-user would still have to add the 2 entries to loader.conf to activate it. Ideally I'd like to see it installed by default (not requiring loader.conf entries) when you build the kernel+world for the RPI-B and RPI2 [and RPI3, eventually] kernels, but that matter is also up for discussion, I guess. The same goes with the 'spigen' device, which needs kldload before the overlay will work. Comment Actions For things like that (using custom spigen properties) base is better now that we build and install overlays.
One per board (or compatible board I think that for spi RPI1 = RPI2 = RPI0) is fine.
It will be installed but not activated, this isn't something that we want to do, we cannot please everyone.
Comment Actions removed recommended port; added to base instead, to be installed in /boot/dtb/overlays/ uses -CURRENT definitions for DTB (not compatible with what is being done in 11-STABLE) implements CS=2 for RPI2 only (RPI-B uses same pin for LED, not compatible). Comment Actions I think you should go ahead and add these to DTSO= in sys/modules/dtb/rpi/Makefile while you're here to hook them up to be installed at the same time; see modules/dtb/allwinner/Makefile for example. We'd still need to figure out how to work this in with arm64/GENERIC for RPI-3, I guess, since it doesn't build dtb modules by default and thus no overlays.
Comment Actions Requires D15301 to work properly, i.e. allows the overlay to create the actual devices in reverse order without affecting the ability to relate the 'spigen' device name to its bus and CS number. The fdt library itself causes this to happen; that is, for an overlay the devices are inserted at the beginning of the section, as they are created, resulting in a kind of reversed sort of how they're specified in the overlay. but relying on the order in which the devices are created is undesirable. That is where D15301 comes in, and now the overlays won't have to specify spigen devices in reverse order. Also removed a comment. Also might want to (later, after I test it) use 'spigen@0' rather than 'spigen0' (etc.) This comment was removed by bobf_mrp3.com. Comment Actions whoops - sorry people - I posted that last comment to the wrong Phab (it was for D15787 Comment Actions verified working ok in r335524 which includes the name change applied to spigen ( https://reviews.freebsd.org/rS335506 ) on RPi 1 B. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||