Hi Icenowy,

On Sun, Aug 14, 2016 at 06:16:16PM +0800, Icenowy Zheng wrote:
> Hi,
> I currently want to work on more peripherals on A64.
> However, many features needs clocks and regulators support.
> Maxime have sent out a series of clock driver based on sunxi-ng, and Andre
> sent out a RFC series of clock driver based on firmware-based SCPI.
> It's said that SCPI can also hold regulators.
> 
> Here're some questions:
> - Can SCPI handle all the functions on AXP803? Or can a private protocol
>   be used to handle the other functions that SCPI do not support?

SCPI is defined here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922g/index.html

Basically, it supports:
  - Clocks
  - Regulators (named power supplies)
  - Resets? (seems like we could implement them as device power states)
  - DVFS
  - Sensors (for voltage, current, temperature, energy and power)

However, the AXP803 has the following features:
  - Regulators: ok
  - GPIOs: not supported
  - Power supplies (the Linux ones, ie which power source is connected
    to the PMIC, the voltage, current they deliver, etc.): not supported
  - Battery Charger: not supported
  - VBUS monitoring: not supported
  - ADCs: I guess that could fall in the sensors category
  - Timers: not supported
  - IRQs for all of the above: as far as I understand, SCPI is on the
    kernel initiative, so that wouldn't work (but I might very well be
    wrong on this one)

So even though we might ignore some of them (I'm not seeing the
relevance of implementing the timers support for example), some
critical features already used are missing.

> - Which one will be more easy to implement? (I think it's the kernel-side
> drivers, as there're mature frameworks in the kernel now)

We even have most of the infrastructure thanks to the previous PMIC we
support, so it should be rather easy to get in the kernel.

> - Is it really valuable for a generalized driver? (As different Allwinner
>   SoCs features usually different IP blocks)

I guess it's just moving the same stuff to different locations: either
in the kernel or in the firmware. Doing it in the kernel would be at
almost no cost, it is yet to be entirely implemented in the firmware
(including the missing parts of the spec).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: PGP signature

Reply via email to