Message-ID: <20180301102836.odxjy4lak2spujii@flea>
Date:   Thu, 1 Mar 2018 11:28:36 +0100
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Samuel Holland <samuel@...lland.org>
Cc:     Chen-Yu Tsai <wens@...e.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        Andre Przywara <andre.przywara@....com>
Subject: Re: [PATCH 0/3] Allwinner sunxi message box support

Hi,

On Wed, Feb 28, 2018 at 11:18:50AM -0600, Samuel Holland wrote:
> On 02/28/18 02:24, Maxime Ripard wrote:
> > On Tue, Feb 27, 2018 at 08:27:11PM -0600, Samuel Holland wrote:
> >> This series adds support for the "hardware message box" in recent
> >> Allwinner sunxi SoCs, used for communication with the ARISC management
> >> processor (the platform's equivalent of the ARM SCP). The end goal is to
> >> use the arm_scpi driver as a client, communicating with firmware running
> >> on the ARISC CPU.
> >>
> >> This driver has been tested with the base arm_scpi driver (which sends
> >> the SCPI_CMD_SCPI_CAPABILITIES command at probe time) and an in-progress
> >> firmware application running on the ARISC CPU. Because no firmware for
> >> the other end of the mailbox is complete at the moment, I have not
> >> included changes to the SoC device trees.
> > 
> > This is not directly related to this series, but what is your end goal
> > with regard to SCPI? What features do you expect to have there?
> 
> Current plans are to support in SCPI:
> - SMP bringup and CPU hotplug (via PSCI in ATF)
> - System reset and poweroff (via PSCI in ATF)
> - System standby and suspend (via PSCI in ATF)
> - DVFS for ARM CPUs
> - Clock control for clocks in R_PRCM (e.g. R_CIR_RX)
> - Thermal sensor reading
> 
> Other planned features of the firmware:
> - System wakeup from poweroff (via GPIO or interrupt to firmware)
> - System power/suspend LED control (connected to GPIO or PMIC GPIO)
> - Polling of thermal sensor in firmware for thermal throttling

Nice.

> > I'm asking because last time we discussed this, SCPI wasn't able to abstract
> > all the features the PMIC provides, and thus Linux needed to still be able to
> > access it.
> 
> This should only be an issue for devices with AXP PMICs.

So this should only be an issue for most devices out there :)

> Other devices with GPIO or simple I²C regulator control, such as H3
> and H5 boards, can have all necessary features described with
> standard SCPI commands. SCPI provides for 127 vendor-defined
> "extended" commands, which could be used to build a full AXP PMIC
> driver, or simply provide commands to read/write PMIC registers.

So I'm not sure whether it was your plan, but the last plan that was
discussed was that the whole RSB bus would be put outside of Linux
control, hence why I was asking.

And in this case the RSB bus is used to access the PMIC, but also its
secondary devices such as the audio codec on the AC100/AC200, so we
really need to have access to the RSB bus in Linux. If you can
implement that through custom SCPI commands, that works for me though.

Another thing that I'm not quire sure about is how would interrupts be
reported throuh that mecanism? We want to use the PMIC as an interrupt
controller for things like VBUS detection, GPIOs or the Jack detect in
the codec. Is that doable?

> For the moment I'm not concerned with battery powered devices. So
> right now the relevant boards either a) don't have a PMIC, or b) can
> have everything but DVFS voltage hard-coded in the firmware.

I wasn't asking you to implement everything from the start, just that
you consider the rest in your design.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists