Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201230012724.1326156-1-martin.blumenstingl@googlemail.com>
 <20201230012724.1326156-4-martin.blumenstingl@googlemail.com> <YFLBPGNQpT9mM3AJ@builder.lan>
In-Reply-To: <YFLBPGNQpT9mM3AJ@builder.lan>
From:   Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Tue, 23 Mar 2021 23:02:06 +0100
Message-ID: <CAFBinCA92411o5+AGApr8+nkMdmzJ4ddzVY+Cb5FLBez+-92nA@mail.gmail.com>
Subject: Re: [PATCH 3/5] dt-bindings: remoteproc: Add the documentation for
 Meson AO ARC rproc
To:     Bjorn Andersson <bjorn.andersson@linaro.org>
Cc:     linux-remoteproc@vger.kernel.org,
        linux-amlogic@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, ohad@wizery.com, robh+dt@kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Bjorn,

On Thu, Mar 18, 2021 at 3:55 AM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
[...]
> > +examples:
> > +  - |
> > +    remoteproc@1c {
> > +      compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
> > +      reg = <0x1c 0x8>, <0x38 0x8>;
>
> I'm generally not in favor of mapping "individual" registers, do you
> know what hardware block this is part of? Can you express the whole
> block as an single entity in your DT?
the answer is unfortunately not easy :-)

some background information:
Amlogic SoCs have two power domains:
- AO (Always-On)
- EE (Everything-Else)

AO includes (at least) one ARC core for which this remoteproc dt-binding is.
EE includes ARM Cortex-A7/15/... cores

The AO registers can be accessed from the EE power-domain and vice versa

Following is an extract (with comments added by me) for the AO
registers (taken from the GPL vendor kernel):
#define AO_RTI_STATUS_REG0 ((0x00 << 10) | (0x00 << 2))
#define AO_RTI_STATUS_REG1 ((0x00 << 10) | (0x01 << 2))
#define AO_RTI_STATUS_REG2 ((0x00 << 10) | (0x02 << 2))
these three are used for communication with the firmware on the AO ARC core
I am not sure into which Linux subsystem these would fit into best

#define AO_RTI_PWR_CNTL_REG1 ((0x00 << 10) | (0x03 << 2))
#define AO_RTI_PWR_CNTL_REG0 ((0x00 << 10) | (0x04 << 2))
this includes various power-domains for the following functionality
(and probably more):
- DDR PHY I/O
- AHB SRAM
- video encoder/decoders
- EE domain isolation

#define AO_RTI_PIN_MUX_REG ((0x00 << 10) | (0x05 << 2))
first part of the pin controller registers for the "AO" bank pads
this includes various GPIOs, UART, I2C for communication with a PMIC,
infrared remote decoder, two PWMs, etc.
all (known) functionality can be used by Linux as well.
especially the UART, I2C, IR decoder and GPIOs are functionality that
we use with Linux today - without involving the AO ARC
remote-processor.

#define AO_WD_GPIO_REG ((0x00 << 10) | (0x06 << 2))
(I think this is related to the watchdog being able to trigger the
SoC's reset line, but there's no documentation on this register)

#define AO_REMAP_REG0 ((0x00 << 10) | (0x07 << 2))
#define AO_REMAP_REG1 ((0x00 << 10) | (0x08 << 2))
remap registers for the AO ARC remote-processor as used in this binding

#define AO_GPIO_O_EN_N ((0x00 << 10) | (0x09 << 2))
#define AO_GPIO_I ((0x00 << 10) | (0x0A << 2))
GPIO controller registers for the "AO" bank pads

#define AO_RTI_PULL_UP_REG ((0x00 << 10) | (0x0B << 2))
second part of the pin controller registers for the "AO" bank pads

#define AO_RTI_WD_MARK ((0x00 << 10) | (0x0D << 2))
again, I think this is somehow related to the watchdog but there's no
documentation on this

#define AO_CPU_CNTL ((0x00 << 10) | (0x0E << 2))
#define AO_CPU_STAT ((0x00 << 10) | (0x0F << 2))
used for booting the AO ARC remote-processor

#define AO_RTI_GEN_CNTL_REG0 ((0x00 << 10) | (0x10 << 2))
seems to be a multi purpose register as it (seems to) contains some
reset bits (for the AO UART and RTC) - not documented

(more registers are following)

to summarize this: I think there's indeed three different sets of registers
having one big device-tree node spanning all of these registers seems
incorrect to me as the other IPs are independent of the AO ARC
remote-processor.
so the way I have done it in the original patch is the best I could
come up with.

Please let me know what you think!


Best regards,
Martin