On 05/09/16 22:17, maxime.ripard wrote: Hi Maxime,
thanks for your answer. > 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. I agree ;-) > > 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 can see that and totally agree here. > >> 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. Excellent! You actually anticipate the suggestion I wanted to make in the reply to that other mail ;-) I guess I have no real stand against the sunxi-ng clocks anyway, since I seem to be the only opponent and maintainers seem to be happy with it. And similar to the regulator issue I think we don't clash on any binding. In the world I imagine the DT comes with the firmware anyway (EDK2 does it that way), so as long as the kernel works with both DTs ... >> 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. Alright, I will try to go as far as I can with the firmware based approach. As SCPI services are requested by the OS, we can even use the very same firmware code, on a sunxi-ng based system SCPI will just never be used and I will try my best to keep it compatible. Thanks! 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
