On 24/08/16 20:28, maxime.ripard wrote: Hi,
> 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 Why can't we model this with some sensors? Since you mention voltage and current.... > - Battery Charger: not supported > - VBUS monitoring: not supported Both look like sensors to me. Energy and voltage. > - 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) SCPI normally uses a mailbox, which allows perfect asynchronous communication from both sides. With the current implementation (not using the actual mailbox, but SMC calls) the lack of IRQs is sadly true, although I could envision (ab-)using some interrupt (for instance the mailbox one) for ATF to tell Linux about updates. And SCPI supports sensor alerts using those asynchronous notifications. > 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). So yes, technically SCPI does not cover every feature that the AXP provides, but I am quite wary of exposing this chip to Linux - since one can play really nasty tricks with it, probably frying a board easily. Combine this with the occasional local root exploit and see unhappy users. So this is actually a good example of how firmware abstraction can improve security. I'd implement regulators with boundary checks, for instance: since the firmware is aware of a particular board, it can deny setting wrong voltages for devices which cannot cope with it. Actually this is such an incentive that I'd consider it worthwhile to invent our own firmware protocol to cover up SCPI deficiencies to keep the AXP in the secure world. Cheers, Andre. -- 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.
