[lowrisc-dev] Re: [sw-dev] Is a de facto standard memory map helpful or harmful?

Karsten Merker merker at debian.org
Tue Jul 19 21:10:06 BST 2016

On Tue, Jul 19, 2016 at 07:14:40PM +0100, Alex Bradbury wrote:
> On 19 July 2016 at 18:30, Wesley Terpstra <wesley at sifive.com> wrote:

> > I think that whatever decision we make wrt. how the system describes
> > its contained hardware should not consider whether a hypothetical
> > kernel developer will reject a merge of the architecture, because this
> > is not within the scope of kernel software. That said, if it makes
> > porting many drivers to RISC-V a pain, then we might want to take that
> > pain into consideration.
> I disagree, with RISC-V we have the opportunity for much greater
> collaboration between hardware and software developers. These
> decisions should be made ins consultation with software developers
> rather than thrown over the wall (publishing drafts of the privileged
> spec before they are adopted by the RISC-V Foundation has of course
> been useful for this).

> >> The config-string code
> >> will recognise resources such as irqs and addresses but of course many
> >> drivers need more parameters than that.
> >
> > Yes. See, for example, gpio-riscv.c which executes:
> >>      rv->chip.ngpio = config_string_u64(pdev, "ngpio");
> > ... which does not seem so cumbersome.
> Yes I saw that. It's not cumbersome to add it for any given device,
> but it does seem a shame if we're now going to end up with three
> configuration codepaths for every platform device that might want to
> be used on RISC-V as well as other devicetree supporting platforms.

Devicetree is already supported out of the box in a large part of
the existing platform drivers, so with using devicetree there
wouldn't be any need to port specific drivers at all in many
cases - they could be used as is.  As Wesley has pointed out,
there _are_ legacy drivers onto which device-tree support has
been grafted on in a not-so-ideal way, but that isn't the default

> >> Modifying any driver that
> >> might be used as part of a RISC-V platform so it can use
> >> config_string_u64 and config_string_str as well as of_property_read_*
> >> and the platdata approach seems like a non-starter.
> >
> > Well, that depends.
> >
> > How many existing devices are we planning on integrating directly into
> > the SoC? Again, any device that connects via another bus standard will
> > work unmodified. I would hope that we aim to include open source
> > hardware in the SoC, which would need a new driver anyway.
> Sometimes you want to instantiate existing IP, e.g. Xilinx SPI. Some
> open source IP is already supported in the kernel (e.g. some devices
> from open cores). Additionally, it seems unnecessary to assume that
> newly-created open source IP will be RISC-V only. People may choose to
> instantiate it with other cores (ARM, MIPS, proprietary, OpenRISC,
> OpenSPARC, ...). Although at lowRISC we aim for open-source
> peripherals, many other RISC-V implementers are likely to use existing
> in-house IP or commercially licensed IP.

Another important field for platform driver support are
peripherals on non-discoverable busses such as I2C and SPI, for
which we have a plethora of existing drivers with device-tree
support.  Those can be instantiated with just a few lines in the
dts and don't need any driver porting work on device-tree-using
systems.  This encompasses things such as power management ICs,
SPI flash memory, ADCs, DACs, lots of sensors (magnetometer,
accelerometer, orientation, temperature, pressure, etc.), tons of
different touchscreens, SPI-driven graphical LCDs for embedded
use, various forms of I/O controllers, etc.

> > In summary: I am not necessarily advocating for the config string, but
> > I don't find the config string approach to be much of a show stopper.
> > The porting effort is minimal per device. This only leaves open the
> > question of how many devices would we need to port. The only impacted
> > devices are those with existing (but not already widely ported)
> > drivers that we would want to integrate directly into the SoC.

This is not really true, see the paragraph above.

> Devicetree can also be used for configuring on-board devices as used
> with devices like Beaglebone Black and Raspberry Pi through
> device-tree overlays. e.g. you may load a certain device tree overlay
> when an audio 'hat' or 'cape' is connected to enable I2S on the
> desired pins. For use cases like this, it doesn't seem it would be
> worth totally stripping the system of DT and instead you'd end up
> using either a mixture of config-string and device-tree or device-tree
> throughout (by e.g. having the bootloader convert the config-string).
> I'm far from an expert here though, so do correct me if you think I'm
> missing the point.

I fully agree. 

As a practical example why I consider mixing different hardware
description systems a bad idea: I have already been exposed way
more than I would like to a mixup between two hardware description
systems on the Allwinner sunxi platform. Allwinner has implemented
their own proprietary hardware description system called "FEX" in
their vendor bootloader and in their vendor kernels.  They have
patched the drivers they consider important to support their FEX
system and ignore everything else.  This results in an absolute
mess if you want to use some device that they didn't consider
important and therefore haven't added FEX support for, as the
standard device drivers expect devicetree configuration, but e.g. 
their pinctrl driver expects everything to be handled by FEX. In
contrast to the vendor code, the sunxi platform support in mainline
is purely devicetree-based and there wouldn't have been even the
slightest chance of the Allwinner FEX system being included in the
mainline kernel and u-boot.

Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

More information about the lowrisc-dev mailing list