lkml.org 
[lkml]   [2020]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] ARM: dts: uniphier: change support card to simple-mfd from simple-bus
On Mon, 29 Jun 2020, Masahiro Yamada wrote:

> On Thu, Jun 25, 2020 at 11:57 PM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > On Thu, 25 Jun 2020, Masahiro Yamada wrote:
> >
> > > On Thu, Jun 25, 2020 at 3:16 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > >
> > > > On Thu, 25 Jun 2020, Masahiro Yamada wrote:
> > > >
> > > > > On Tue, Jun 23, 2020 at 9:24 PM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > >
> > > > > > On Tue, 23 Jun 2020, Masahiro Yamada wrote:
> > > > > >
> > > > > > > 'make ARCH=arm dtbs_check' emits the following warning:
> > > > > > >
> > > > > > > support-card@1,1f00000: $nodename:0: 'support-card@1,1f00000' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
> > > > > > >
> > > > > > > Maybe, simple-mfd could be a better fit for this device.
> > > > > >
> > > > > > The two should be equivalent.
> > > > >
> > > > > Yes, I know.
> > > > > That's why I can change "simple-bus" to "simple-mfd"
> > > > > with no risk.
> > > > >
> > > > > The difference is schema-check.
> > > > >
> > > > > The node name for "simple-bus" is checked by 'make dtbs_check'.
> > > > >
> > > > > See this code:
> > > > > https://github.com/robherring/dt-schema/blob/v2020.05/schemas/simple-bus.yaml#L17
> > > > >
> > > > > Even if I rename the node, it does not accept the
> > > > > unit name '1,1f00000'
> > > > >
> > > > > > What do you mean by "maybe"? Does this squash the warning?
> > > > >
> > > > > "maybe" means I am not quite sure
> > > > > which compatible is a better fit
> > > > > to describe this device.
> > > > >
> > > > > As mentioned above, simple-bus and simple-mfd
> > > > > are interchangeable from a driver point of view.
> > > > >
> > > > > This add-on board is integrated with various peripherals
> > > > > such as 16550a serial, smsc9115 ether etc.
> > > > > The address-decode is implemented in a CPLD device.
> > > > > It has chip selects and local addresses, which are mapped to
> > > > > the parent.
> > > > >
> > > > > It can be either simple-bus or simple-mfd, I think.
> > > > >
> > > > >
> > > > > dt-schema checks the node name of simple-bus.
> > > > > Currently, there is no check for simple-mfd.
> > > > >
> > > > > So, I think this patch is an easy solution
> > > > > to fix the warning.
> > > >
> > > > Yes, looking at the documentation it seems as though 'simple-mfd'
> > > > would be a better fit. Is the device a single IP with various
> > > > different functions?
> > >
> > > Not an IP.
> > >
> > > This is a small board that consists of
> > > a CPLD + ethernet controller + serial controller + LED, etc.
> >
> > Then simple MFD does not seem like a good fit.
> >
> > Neither does 'simple-bus'.
>
> Then, I do not know what to do.
>
>
> This board connection is so simple
> that no hardware initialization needed to get access
> to peripherals.
>
> So, 'simple-bus' or 'simple-mfd' is preferred.
>
> If this is not either simple-bus or simple-mfd,
> I need a special driver to probe the
> child devices such as ethernet, serial etc.
>
>
>
> > What is it you're trying to describe in the device hierarchy?
>
>
> The connection is as follows:
>
>
> |-Main board -| |----- add-on board ----|
> | | | (this board) |
> | | | |
> | (SoC) ---|------|--- CPLD --- ethernet |
> | | | |- serial |
> |-------------| | |- LED |
> | |
> |-----------------------|
>
>
>
> uniphier-support-card.dtsi describes the
> "add-on board" part.
> Address-decode is implemented in CPLD.
>
>
> So, the criteria to become MFD is
> whether it is an IP integrated into SoC.
>
>
> - implemented in an SoC --> MFD

If

s/in an SoC/in a single piece of silicon/

... then yes.

> - implemented in a board + CPLD --> not MFD
>
> Right?

Right. Unless all H/W is represented inside the CPLD, in which case
the CPLD is, in theory, the MFD. Although, due to the nature of
CPLDs, this is a slippery slope.

You may want something like:

arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezzanine.dts

... where the add-on board is represented separately (not in the
same hierarchical structure as the main board. The main board is then
included as a DTSI from the add-on board.

It might also be worth looking at how consumer boards such as the
RaspberryPi, BeagleBoard and the like handle their add-on boards,
mezzanines, capes, hats, etc.

--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

\
 
 \ /
  Last update: 2020-06-29 22:46    [W:0.094 / U:42.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site