Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> writes: > On Sun, 8 Jun 2014, Lorenzo Pieralisi wrote: > >> On Sun, Jun 08, 2014 at 12:53:34AM +0100, Olof Johansson wrote: >> > Lorenzo, >> > >> > Since you're emailing from @arm.com, some of this is to the wider >> > recipient and maybe not directly to you: >> >> I am glad to reply and take blame since this is a debate definitely worth >> having. > > Great. Because I would like to steer this debate a little towards the > genuine cause rather than sticking to some particular consequences. > >> Guys, do not get me wrong here. There are fixes that can be deemed >> acceptable in an OS, there are fixes that can't. I just can't help thinking >> that Nicolas' patch is a nasty hack (and I am far, really really far from >> blaming him for that, because that's the only patch that can fix that >> issue in the kernel), and he perfectly knows that. > > You know what? The more I think about my patch, the more I consider > this should be the standard way of setting up things unconditionally on > _all_ platforms using MCPM. Why? Because that's the most coherent thing > to do! I agree. > I really think the kernel should either be responsible for the CCI or it > should not at all. And conversely for the bootloader. Right now we > have an implicit requirement that the bootloader should turn on the CCI, > but only for cold boot, and only for the boot cluster, and not for CPU > resuming from idle, and what other case we haven't thought about yet. > And as noticed this requirement is not documented. In addition to being a firmware minimalist like Nico, what I find most objectional to the bootloader approach is that even with CCI enabled by the firmware, since it's a runtime requirement (for low-power idle or suspend), the kernel has to handle it anyways. So you end up with a partial solution in the firwmare (for boot cluster only) *and* a full solution in the kernel. This doesn't make any sense, expecially because the kernel might then have to do things differently on cold boot vs. low-power idle/suspend or differently on the boot cluster vs. other clusters. From a maintenance PoV, this is a mess and could easily lead to just as many SoC specific hacks that are different across platforms. Stated more simply: If the kernel has to manage the resource at runtime due to low-power idle/suspend. I don't see any reason why it shouldn't manage it at cold boot time also. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html