On Wed, Oct 28, 2020 at 8:51 AM Peng Fan <peng.fan@xxxxxxx> wrote: > > Hi Lucas, > > > Subject: Re: [PATCH 00/11] i.MX8MM power domain support > > > > Hi Peng, > > > > On Mi, 2020-10-14 at 01:23 +0000, Peng Fan wrote: > > [...] > > > > > > > 3. either 8MM, 8MN, or 8MP, the power domain design is > > > > > > > different, I am not > > > > > > sure if it is the good to add hundreds line of code in GPCv2 > > > > > > each time > > > > > > > a new SOC is added. > > > > > > > > > > > > I don't buy into this argument. We have lots of drivers in the > > > > > > Linux kernel that require some changes for new SoC generations, > > > > > > that's what Linux drivers are for. The complexity of the > > > > > > hardware doesn't disappear just because you push some of the > > > > > > driver bits into TF-A, you just handle the complexity at a > > > > > > different palce and IMHO that the wrong place. The power domains > > > > > > have complex interactions with other drivers in the Linux > > > > > > system, so debugging and deplyong fixes is much easier when the > > > > > > power domain handling is fully done by a kernel > > > > driver. > > > > > Actually, due to the security requirement from other system > > > > > solution provider, for example, Microsoft Azure Sphere, it has > > > > > strict requirement for power domain to be controlled by secure > > > > > subsystem(either > > > > TF-A, TEE or dedicated secure domain controller). > > > > > Same requirement for reset control, and system critical clock control. > > > > > > > > Yes, I'm aware of those requirements, but to satisfy those you need > > > > a full implementation of all those parts in the secure subsystem. > > > > Doing it just for the power domains adds complexity for no gain, as > > > > you still won't be able to meet all the requirements and frankly I > > > > don't think this is a realistic goal to achieve with the current i.MX8M > > family of SoCs. > > > > > > At least we are moving to that direction. > > > > To me it seems like the current way (custom TF-A interface and > > implementation) is one step in the right direction, but two steps backwards in > > terms of complexity. > > > > > > Meeting those requirements needs a fully system approach where the > > > > secure subsystem parts are made sufficiently independent from the > > > > non- secure parts on a hardware level, which I don't see on the > > > > i.MX8M SoC and hardware design guide. > > > > > > CSU could restrict the access permission. > > > > While this is true, my argument is much broader and not only focused on > > on-SoC peripherals. For example some of the power domains need different > > voltages for specific performance states, which means you need to > > communicate with a external PMIC or other voltage regulator, which in turn > > means you need to set aside the necessary i2c bus and/or GPIO banks > > required for this communication at system design time, so it isn't shared > > between TF-A and the rich OS. I don't see this in any of the i.MX8M designs. > > > > > > > For NXP i.MX8M family, it is ok to implement in linux kernel, just > > > > > a tradeoff to find out a place to hide the complexity ^_^. > > > > > > > > > > BTW, for virtualization support, it is better to put the power > > > > > domain in a central place to simplify the VM implementation. > > > > > > > > Same as above. If you can make all the relevant bits (clock, reset, > > > > power-domain, regulator) available via a virtualization friendly > > > > API, then I would see a point in adding complexity for this > > > > abstraction. As long as this added abstraction only solves a very > > > > tiny bit of the overall picture, I just don't see the point in the added > > complexity and (from a Linux PoV) obfuscation. > > > > > > Could we use SCMI for power domain, system critical clocks, smc > > > watchdog and etc? > > > > If you could demonstrate a working solution with all those pieces hidden > > behind a standard SCMI interface, this would make for a much more > > compelling story supporting the secure subsystem argument. > > > > > Or we support two approaches, one is let Linux control everything, the > > > other is using SCMI. > > > > > > Thoughts? > > > > I wouldn't be opposed to such a solution. If you can put all this behind a > > standard SCMI interface, I guess we wouldn't need two different SoC specific > > drivers for the same purpose, so we could easily have a Linux full-control > > solution (i.e. this patchset) coexist with a SCMI based implementation, > > possibly with just a slightly different base SoC DT with all the power domains, > > clocks and other system level control stuff behind SCMI. > > > > What I'm strongly opposed to is having a custom TF-A interface and all the > > added complexity for little to no gain in actual system security. > > Understand. There are truly the SoC design might not fit well to protect > all the stuff. > > It is good that you did this patchset. Vote for you to add more support > on i.MX. > > Your patchset not conflict with SCMI, as you said, this is true. > > Please continue your effort. Despite ongoing efforts to get the displaymix (and probably vpumix) operational, it would be nice to have operational USB which needs two of the power domains. Could we apply the initial framework and only the DT nodes for the functional power domains (hsiomix and pgc_otg1) . While it's not a perfect solution, I think incremental improvements are better than going stale while we wait for the perfect solution. Having them pulled into a staging branch also helps coordinate efforts. adam > > Thanks, > Peng. > > > > > Regards, > > Lucas > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
