From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
Date: Fri, 19 Feb 2016 12:53:52 +0100 [thread overview]
Message-ID: <2394082.bSJ4DLLTEt@wuerfel> (raw)
In-Reply-To: <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
On Thursday 18 February 2016 15:27:06 Daniel Drake wrote:
> On Thu, Feb 18, 2016 at 3:04 PM, Carlo Caione <carlo@caione.org> wrote:
> >> However, if some or all of the other devices actually are entirely
> >> made up of register ranges within cbus, that would indicate that
> >> cbus itself is not just a collection of random registers but something
> >> that could be considered a bus of itself in hardware, and then
> >> we could represent the other devices as children of this bus.
> >
> > I think that this is exactly the case. We are missing this cbus in the
> > DTS because (for lacking of proper documentation) we are not sure
> > about start / end / size.
>
> Here's a hint from the vendor kernel
> https://github.com/endlessm/linux-meson/blob/master/arch/arm/mach-meson8b/iomapping.c#L87
>
> Having a cbus bus node with child devices does sound like it would
> reflect this particular view of the hardware design. How would we then
> represent the hwrev registers under that?
>
> I am also curious if this is the common practice. We were working with
> Exynos devices before, and even though many of the components are on
> the AXI bus there, there is no AXI bus representation in the DT. But
> now that I go digging, I see other SoCs that do have a DT bus
> representation very similar to what's being described, such as the apb
> and axi busses in mmp2.dtsi. Is one approach preferred over the other
> for new SoC support?
I would always prefer having the dts files describe the hardware as best
as they can.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Daniel Drake <drake@endlessm.com>
Cc: devicetree <devicetree@vger.kernel.org>,
linux-meson@googlegroups.com, Carlo Caione <carlo@endlessm.com>,
Carlo Caione <carlo@caione.org>,
Romain Perier <romain.perier@gmail.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
Date: Fri, 19 Feb 2016 12:53:52 +0100 [thread overview]
Message-ID: <2394082.bSJ4DLLTEt@wuerfel> (raw)
In-Reply-To: <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
On Thursday 18 February 2016 15:27:06 Daniel Drake wrote:
> On Thu, Feb 18, 2016 at 3:04 PM, Carlo Caione <carlo@caione.org> wrote:
> >> However, if some or all of the other devices actually are entirely
> >> made up of register ranges within cbus, that would indicate that
> >> cbus itself is not just a collection of random registers but something
> >> that could be considered a bus of itself in hardware, and then
> >> we could represent the other devices as children of this bus.
> >
> > I think that this is exactly the case. We are missing this cbus in the
> > DTS because (for lacking of proper documentation) we are not sure
> > about start / end / size.
>
> Here's a hint from the vendor kernel
> https://github.com/endlessm/linux-meson/blob/master/arch/arm/mach-meson8b/iomapping.c#L87
>
> Having a cbus bus node with child devices does sound like it would
> reflect this particular view of the hardware design. How would we then
> represent the hwrev registers under that?
>
> I am also curious if this is the common practice. We were working with
> Exynos devices before, and even though many of the components are on
> the AXI bus there, there is no AXI bus representation in the DT. But
> now that I go digging, I see other SoCs that do have a DT bus
> representation very similar to what's being described, such as the apb
> and axi busses in mmp2.dtsi. Is one approach preferred over the other
> for new SoC support?
I would always prefer having the dts files describe the hardware as best
as they can.
Arnd
next prev parent reply other threads:[~2016-02-19 11:53 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-17 17:28 [PATCH 0/2] Adding support to show SoC revision in /proc/cpuinfo Romain Perier
2016-02-17 17:28 ` Romain Perier
2016-02-17 17:28 ` [PATCH 1/2] ARM: meson: Adding support to retrieve serial and SoC revision Romain Perier
2016-02-17 17:28 ` Romain Perier
2016-02-17 20:34 ` Carlo Caione
2016-02-17 20:34 ` Carlo Caione
2016-02-18 12:20 ` Romain Perier
2016-02-18 12:20 ` Romain Perier
2016-02-18 12:24 ` Carlo Caione
2016-02-18 12:24 ` Carlo Caione
2016-02-17 17:28 ` [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node Romain Perier
2016-02-17 17:28 ` Romain Perier
2016-02-17 20:36 ` Carlo Caione
2016-02-17 20:36 ` Carlo Caione
2016-02-18 12:33 ` Romain Perier
2016-02-18 12:33 ` Romain Perier
2016-02-18 12:43 ` Arnd Bergmann
2016-02-18 12:43 ` Arnd Bergmann
2016-02-18 14:14 ` Carlo Caione
2016-02-18 14:14 ` Carlo Caione
2016-02-18 14:22 ` Arnd Bergmann
2016-02-18 14:22 ` Arnd Bergmann
2016-02-18 21:04 ` Carlo Caione
2016-02-18 21:04 ` Carlo Caione
2016-02-18 21:24 ` Carlo Caione
2016-02-18 21:24 ` Carlo Caione
2016-02-18 21:27 ` Daniel Drake
2016-02-18 21:27 ` Daniel Drake
2016-02-19 11:53 ` Arnd Bergmann [this message]
2016-02-19 11:53 ` Arnd Bergmann
2016-02-19 12:54 ` Arnd Bergmann
2016-02-19 12:54 ` Arnd Bergmann
2016-02-19 13:25 ` Carlo Caione
2016-02-19 13:25 ` Carlo Caione
2016-02-24 20:42 ` Carlo Caione
2016-02-24 20:42 ` Carlo Caione
2016-02-26 15:34 ` Carlo Caione
2016-02-26 15:34 ` Carlo Caione
2016-02-26 16:00 ` Arnd Bergmann
2016-02-26 16:00 ` Arnd Bergmann
2016-02-26 16:43 ` Carlo Caione
2016-02-26 16:43 ` Carlo Caione
2016-02-26 17:00 ` Arnd Bergmann
2016-02-26 17:00 ` Arnd Bergmann
2016-02-26 17:40 ` Carlo Caione
2016-02-26 17:40 ` Carlo Caione
2016-02-17 20:50 ` Arnd Bergmann
2016-02-17 20:50 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2394082.bSJ4DLLTEt@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.