Re: [PATCH v2 00/16] ARM: support for ICP DAS LP-8x4x (with dts)

Arnd Bergmann
2013-12-15T00:54:03Z

On Saturday 14 December 2013, Sergei Ianovich wrote:
> On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
> > On Friday 13 December 2013, Sergei Ianovich wrote:
> > > I've also decided not to create a single mfd device for
> > > machine-specific devices. Instead each type is supported by a separate
> > > driver in respective subsystem. It was tempting to hardcode all the
> > > constants in one source file, but that requires ugly initialization.
> > > The taken way produces much cleaner code.
> >
> > I think you should at least change the DT representation for the FPGA
> > to show one device as the actual FPGA and attach children to that,
> > multiple indirection levels if necessary.
> >
> > I suspect that the fpga is on some external-bus port with a specific
> > chip-select, so I would model this as
> >
> > extbus {
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > /* bus addresses 0-0xfffff mapped to 0x17000000 */
> > ranges = <0 0x17000000 0x100000>;
> > interrupt-parent = <&fpga-irq>;
> >
> > fpga-irq: irq@6 {
> > regs = <6 16>; /* translated addresses
> > ...
> > };
> >
> > fgpa-bus {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges;
> >
> > serial@9050 {
> > ...
> > };
> > };
> > };
> >
> > I also think you don't need to make the devices quite as fine-grained
> > here but instead group things together more. I would probably indeed
> > put everything that is not on one of the slots into a common device,
> > including the irqchip.
>
> There are basically 2 options: one-for-all mfd device and one-for-one
> device drivers.
>
> MFD
> pros:
> * easy to add into the tree (one file)
> * easy config (one option)
>
> Separate devices
> * easy to support devices as respective subsystems evolve
> * easy to add new feature without breaking existing ones. Eg. it may
> make sense to provide industrial IO interface on analog IO devices
> * possible to have fine-grained configuration (eg. SRAM in kernel,
> serial and slot as modules)
> * proper device tree serves as a datasheet for the machine, so anyone
> who needs to work on it will have a decent view of the internals
>
> I believe long-term benefits of separate devices outweigh immediate
> effects of an MFD. However, I certainly don't see the big picture and
> will accept your decision. Please make one.

Unfortunately I don't have a good way to judge the tradeoffs without
understanding more about the design of the hardware. Did I understand
you right that you expect future versions of the FPGA bitstream
to implement additional features or have a different set of endpoint
devices?

If so, I would argue that anything that you consider an optional
sub-device should have its own device node in the device tree.

Also, do you have to model hardware that is connected to the FPGA
rather than being part of it?

I suspect that you may have a different understanding of the term
MFD than what I was suggesting: A typical MFD driver in Linux is
basically a container device that has some registers on its own
like a version detection or the irqchip but mainly is there to
create sub-devices that each have a subset of the available
registers. The sub-devices may or may not be describe in DT in this
case.

Arnd