Hi, On Tue, Sep 06, 2016 at 12:43:41AM +0100, André Przywara wrote: > 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.
Ok. I'll respin my sunxi-ng patches with a bunch of changes compared to the first version (mostly to split the H3 and A64 drivers, as Jean Francois and Chen-Yu suggested). Do you want to send your initial patches on top, or should I do it? Thanks! 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
