Hi Andre, I'm leaving aside the rest of your mail, since we apparently have a very fundamental disagreement and will never reach an agreement. So, let's agree to disagree.
That being said... On Mon, Sep 05, 2016 at 01:25:36AM +0100, André Przywara wrote: > From thinking more about this I think we can have both approaches > implemented: > - An embedded design for people who either want full control or who > don't care too much about the potential danger. > - A server design which hides those bits from Linux, instead offers > abstracted firmware interfaces to monitor (or control, if necessary) AXP > functionality. > > The DT would then ultimately describe which version is used: A "server > firmware" would switch the RSB to secure and would expose SCPI > regulators and sensors in the DT. People in favour of the embedded > design could load a different firmware (or somehow switch over) and use > the "embedded" DT with a RSB node and have full control. What I don't want is to wait for the year of SCPI on embedded boards. We already wasted way too much time on this, and people are asking for it. > I don't see how those should clash from a Linux perspective, as we just > use different drivers and describe the wanted one in the DT, without > having conflicting bindings. > > Yes, having different DTs for the same hardware may rise some eyebrows, > but in the end we just describe firmware interfaces (like PSCI) and > avoid describing some hardware (RSB). But PSCI is actually a very good example. The implementation we have right now just generates the right DT nodes if the bootloader is PSCI-enabled, and the kernel just picks whatever is provided, without having to actually declare anything. I could imagine the same thing for SCPI. And it would even be easier with sunxi-ng to modify the DT to basically drop the CCU node, and insert the scpi-clocks node instead. You would only need to keep the same phandle (which is trivial) and to keep the same clock indices (which is not that hard either). That would be the most obvious way to have things working I guess: if you use an SCPI-enabled firmware, everything is just generated at runtime depending on what the firmware supports. And everything just works. > I really want to depart from this all-embedded approach which > exposes every bit to Linux. So why not use the first 64-bit > Allwinner chip as a test vehicle to prototype this? Could you live > with a different approach living in parallel with the classic sunxi > way? If we don't have to maintain and ship several DTs depending on the option, yes, sure. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
