Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
Hi Rob, On Thu, Apr 16, 2015 at 12:17 PM, Rob Clark wrote: > On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas > wrote: > >> But I'm definitely going to discourage companies like Qualcomm >> deliberately ignoring the existing booting protocols while trying to get >> their code upstream. This patch series is posted by Qualcomm without >> providing any technical reason on why they don't want to/couldn't use >> PSCI (well, I guess there is no technical reason but they may not care >> much about mainline either). > > Sure.. just trying to make sure the wrong people don't end up being > the ones that suffer. I would assume/expect that it is at least > possible for qcom to change firmware/bootloader for their dev boards > and future devices and whatnot, whether they grumble about it or not. > But I guess most of what the general public has are devices w/ signed > fw, which is why "go fix your firmware" is an option that sets off > alarm bells for me. > > I guess the first device where this will matter to me and a large > group of community folks would be the dragonboard 410c.. *hopefully* > it does not require signed firmware or at least qcom could make > available signed firmware which supports psci.. For development boards, one would hope there is a way to sign your own firmware. You can't expect - even for a phone SoC - that the development boards require entering some kind of Faustian contract for development of low-level software. What if someone wants to develop a platform that doesn't require signing? That said most of these dev boards have completely mangled JTAG anyway, and I know Inforce (and Hardkernel, and so on) love their barely-ever-updated custom firmware binaries, so.. The best thing would be to pick up one of those boards and port a PSCI firmware to it (ATF or your own..) and just embarrass the SoC vendor by having better mainline power management support (implemented by 10 lines in a device tree) with the complicated code hidden away behind the scenes there, like it should have been done in the first place.. Ta. Matt Sealey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Thu, Apr 16, 2015 at 01:17:32PM -0400, Rob Clark wrote: > On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas > wrote: > > On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote: > >> There are folks who are working to get saner, more-upstream kernels > >> working on devices.. and improving kernel infrastructure for > >> device-needs (well, in my neck of the woods, there is drm/kms atomic > >> and dsi/panel framework stuff.. I'm sure other similar things in other > >> kernel domains). And it seems like that is a good thing to encourage, > >> rather than stymie. > > > > I'm not looking to discourage individuals trying to get upstream support > > for older boards. Should the need arise, we'll look at options which may > > or may not include kernel changes (e.g. wrap the kernel in a shim). > > I had wondered about that, but afaiu psci is a smc interface, and I > would assume bootloader drops you out of secure mode before entering > the kernel or whatever comes after first stage bootloader if you are > chain-loading? One option is to run the shim at EL2 (hyp mode) which can intercept the SMC calls from EL1. Another option is to release all the CPUs from firmware into the shim and use a spin-table enable method. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas wrote: > On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote: >> On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas >> wrote: >> > On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: >> >> Just speaking as an outsider to this topic, but seems like most/all >> >> tablets/phones/etc ship with signed firmware. Which means for most of >> >> the population, upgrading the firmware to a new version which did >> >> support the standard (assuming it existed), isn't really an option on >> >> our devices, any more than fixing buggy acpi tables is on our >> >> laptops.. >> > >> > I wouldn't expect most population to build their own kernels on >> > tablets/phones. And even if you could install a custom kernel, mainline >> > rarely runs on such devices because of tons of out of tree patches (just >> > look at the Nexus 9 patches that Kumar pointed at; even ignoring the >> > booting protocol they are extremely far from an upstreamable form). >> >> my point being, that it happens some times.. for example John Stultz's >> work on nexus7: >> >> https://plus.google.com/111524780435806926688/posts/DzvpMLmzQiQ >> >> If this had been a year or two in the future and on some 64b >> snapdragon, and support for devices with non-PSCI fw is rejected, then >> he'd be stuck. >> >> There are folks who are working to get saner, more-upstream kernels >> working on devices.. and improving kernel infrastructure for >> device-needs (well, in my neck of the woods, there is drm/kms atomic >> and dsi/panel framework stuff.. I'm sure other similar things in other >> kernel domains). And it seems like that is a good thing to encourage, >> rather than stymie. > > I'm not looking to discourage individuals trying to get upstream support > for older boards. Should the need arise, we'll look at options which may > or may not include kernel changes (e.g. wrap the kernel in a shim). I had wondered about that, but afaiu psci is a smc interface, and I would assume bootloader drops you out of secure mode before entering the kernel or whatever comes after first stage bootloader if you are chain-loading? So wasn't sure even how that could work.. (ofc, well outside of my areas so I could be quite off base) If there is a workaround, then I am much less concerned, and would rather talk about that :-) > But I'm definitely going to discourage companies like Qualcomm > deliberately ignoring the existing booting protocols while trying to get > their code upstream. This patch series is posted by Qualcomm without > providing any technical reason on why they don't want to/couldn't use > PSCI (well, I guess there is no technical reason but they may not care > much about mainline either). Sure.. just trying to make sure the wrong people don't end up being the ones that suffer. I would assume/expect that it is at least possible for qcom to change firmware/bootloader for their dev boards and future devices and whatnot, whether they grumble about it or not. But I guess most of what the general public has are devices w/ signed fw, which is why "go fix your firmware" is an option that sets off alarm bells for me. I guess the first device where this will matter to me and a large group of community folks would be the dragonboard 410c.. *hopefully* it does not require signed firmware or at least qcom could make available signed firmware which supports psci.. BR, -R > -- > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote: > On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas > wrote: > > On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: > >> Just speaking as an outsider to this topic, but seems like most/all > >> tablets/phones/etc ship with signed firmware. Which means for most of > >> the population, upgrading the firmware to a new version which did > >> support the standard (assuming it existed), isn't really an option on > >> our devices, any more than fixing buggy acpi tables is on our > >> laptops.. > > > > I wouldn't expect most population to build their own kernels on > > tablets/phones. And even if you could install a custom kernel, mainline > > rarely runs on such devices because of tons of out of tree patches (just > > look at the Nexus 9 patches that Kumar pointed at; even ignoring the > > booting protocol they are extremely far from an upstreamable form). > > my point being, that it happens some times.. for example John Stultz's > work on nexus7: > > https://plus.google.com/111524780435806926688/posts/DzvpMLmzQiQ > > If this had been a year or two in the future and on some 64b > snapdragon, and support for devices with non-PSCI fw is rejected, then > he'd be stuck. > > There are folks who are working to get saner, more-upstream kernels > working on devices.. and improving kernel infrastructure for > device-needs (well, in my neck of the woods, there is drm/kms atomic > and dsi/panel framework stuff.. I'm sure other similar things in other > kernel domains). And it seems like that is a good thing to encourage, > rather than stymie. I'm not looking to discourage individuals trying to get upstream support for older boards. Should the need arise, we'll look at options which may or may not include kernel changes (e.g. wrap the kernel in a shim). But I'm definitely going to discourage companies like Qualcomm deliberately ignoring the existing booting protocols while trying to get their code upstream. This patch series is posted by Qualcomm without providing any technical reason on why they don't want to/couldn't use PSCI (well, I guess there is no technical reason but they may not care much about mainline either). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote: On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: Just speaking as an outsider to this topic, but seems like most/all tablets/phones/etc ship with signed firmware. Which means for most of the population, upgrading the firmware to a new version which did support the standard (assuming it existed), isn't really an option on our devices, any more than fixing buggy acpi tables is on our laptops.. I wouldn't expect most population to build their own kernels on tablets/phones. And even if you could install a custom kernel, mainline rarely runs on such devices because of tons of out of tree patches (just look at the Nexus 9 patches that Kumar pointed at; even ignoring the booting protocol they are extremely far from an upstreamable form). my point being, that it happens some times.. for example John Stultz's work on nexus7: https://plus.google.com/111524780435806926688/posts/DzvpMLmzQiQ If this had been a year or two in the future and on some 64b snapdragon, and support for devices with non-PSCI fw is rejected, then he'd be stuck. There are folks who are working to get saner, more-upstream kernels working on devices.. and improving kernel infrastructure for device-needs (well, in my neck of the woods, there is drm/kms atomic and dsi/panel framework stuff.. I'm sure other similar things in other kernel domains). And it seems like that is a good thing to encourage, rather than stymie. I'm not looking to discourage individuals trying to get upstream support for older boards. Should the need arise, we'll look at options which may or may not include kernel changes (e.g. wrap the kernel in a shim). But I'm definitely going to discourage companies like Qualcomm deliberately ignoring the existing booting protocols while trying to get their code upstream. This patch series is posted by Qualcomm without providing any technical reason on why they don't want to/couldn't use PSCI (well, I guess there is no technical reason but they may not care much about mainline either). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote: On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: Just speaking as an outsider to this topic, but seems like most/all tablets/phones/etc ship with signed firmware. Which means for most of the population, upgrading the firmware to a new version which did support the standard (assuming it existed), isn't really an option on our devices, any more than fixing buggy acpi tables is on our laptops.. I wouldn't expect most population to build their own kernels on tablets/phones. And even if you could install a custom kernel, mainline rarely runs on such devices because of tons of out of tree patches (just look at the Nexus 9 patches that Kumar pointed at; even ignoring the booting protocol they are extremely far from an upstreamable form). my point being, that it happens some times.. for example John Stultz's work on nexus7: https://plus.google.com/111524780435806926688/posts/DzvpMLmzQiQ If this had been a year or two in the future and on some 64b snapdragon, and support for devices with non-PSCI fw is rejected, then he'd be stuck. There are folks who are working to get saner, more-upstream kernels working on devices.. and improving kernel infrastructure for device-needs (well, in my neck of the woods, there is drm/kms atomic and dsi/panel framework stuff.. I'm sure other similar things in other kernel domains). And it seems like that is a good thing to encourage, rather than stymie. I'm not looking to discourage individuals trying to get upstream support for older boards. Should the need arise, we'll look at options which may or may not include kernel changes (e.g. wrap the kernel in a shim). I had wondered about that, but afaiu psci is a smc interface, and I would assume bootloader drops you out of secure mode before entering the kernel or whatever comes after first stage bootloader if you are chain-loading? So wasn't sure even how that could work.. (ofc, well outside of my areas so I could be quite off base) If there is a workaround, then I am much less concerned, and would rather talk about that :-) But I'm definitely going to discourage companies like Qualcomm deliberately ignoring the existing booting protocols while trying to get their code upstream. This patch series is posted by Qualcomm without providing any technical reason on why they don't want to/couldn't use PSCI (well, I guess there is no technical reason but they may not care much about mainline either). Sure.. just trying to make sure the wrong people don't end up being the ones that suffer. I would assume/expect that it is at least possible for qcom to change firmware/bootloader for their dev boards and future devices and whatnot, whether they grumble about it or not. But I guess most of what the general public has are devices w/ signed fw, which is why go fix your firmware is an option that sets off alarm bells for me. I guess the first device where this will matter to me and a large group of community folks would be the dragonboard 410c.. *hopefully* it does not require signed firmware or at least qcom could make available signed firmware which supports psci.. BR, -R -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Thu, Apr 16, 2015 at 01:17:32PM -0400, Rob Clark wrote: On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote: There are folks who are working to get saner, more-upstream kernels working on devices.. and improving kernel infrastructure for device-needs (well, in my neck of the woods, there is drm/kms atomic and dsi/panel framework stuff.. I'm sure other similar things in other kernel domains). And it seems like that is a good thing to encourage, rather than stymie. I'm not looking to discourage individuals trying to get upstream support for older boards. Should the need arise, we'll look at options which may or may not include kernel changes (e.g. wrap the kernel in a shim). I had wondered about that, but afaiu psci is a smc interface, and I would assume bootloader drops you out of secure mode before entering the kernel or whatever comes after first stage bootloader if you are chain-loading? One option is to run the shim at EL2 (hyp mode) which can intercept the SMC calls from EL1. Another option is to release all the CPUs from firmware into the shim and use a spin-table enable method. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
Hi Rob, On Thu, Apr 16, 2015 at 12:17 PM, Rob Clark robdcl...@gmail.com wrote: On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas catalin.mari...@arm.com wrote: But I'm definitely going to discourage companies like Qualcomm deliberately ignoring the existing booting protocols while trying to get their code upstream. This patch series is posted by Qualcomm without providing any technical reason on why they don't want to/couldn't use PSCI (well, I guess there is no technical reason but they may not care much about mainline either). Sure.. just trying to make sure the wrong people don't end up being the ones that suffer. I would assume/expect that it is at least possible for qcom to change firmware/bootloader for their dev boards and future devices and whatnot, whether they grumble about it or not. But I guess most of what the general public has are devices w/ signed fw, which is why go fix your firmware is an option that sets off alarm bells for me. I guess the first device where this will matter to me and a large group of community folks would be the dragonboard 410c.. *hopefully* it does not require signed firmware or at least qcom could make available signed firmware which supports psci.. For development boards, one would hope there is a way to sign your own firmware. You can't expect - even for a phone SoC - that the development boards require entering some kind of Faustian contract for development of low-level software. What if someone wants to develop a platform that doesn't require signing? That said most of these dev boards have completely mangled JTAG anyway, and I know Inforce (and Hardkernel, and so on) love their barely-ever-updated custom firmware binaries, so.. The best thing would be to pick up one of those boards and port a PSCI firmware to it (ATF or your own..) and just embarrass the SoC vendor by having better mainline power management support (implemented by 10 lines in a device tree) with the complicated code hidden away behind the scenes there, like it should have been done in the first place.. Ta. Matt Sealey n...@bakuhatsu.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Wed, Apr 15, 2015 at 05:17:59PM +0100, Lina Iyer wrote: > On Tue, Apr 14 2015 at 16:32 -0600, Lorenzo Pieralisi wrote: > >On Tue, Apr 14, 2015 at 03:21:17PM +0100, Kumar Gala wrote: > > > >[...] > > > >> > Looking beyond this set of patches, I can foresee that you won't care > >> > about the generic arm64 cpuidle driver either, or more precisely the > >> > separation between cpuidle subsystem+driver and the SoC-specific > >> > back-end (cpu_operations). > >> > >> That's probably true for what I guess are a number of reasons. I'm > >> guessing the arm64 cpuidle driver expects PSCI. > > > >Wrap lines sensibly please. > > > >The arm64 cpuidle driver, that is now arm generic cpuidle driver does > >not expect anything apart from an enable-method (and you pulled > >part of its back-end implementation for arm32 Qualcomm platforms, FYI). > > > The backend for this SoC would leverage the same platform code as ARM32. > The cpu_operations callbacks for init and suspend will call into the the > same platform functions used by arm32 QCOM SoCs. It is understood, but this does not mean we should merge this patchset, actually it is the other way around. It was extremely complicated to factor out some common CPUidle bits because of the prolification of power down interfaces in arm/mach code, each with its quirks du jour. If we had a standard interface (that encompasses what all ARM mach code power interfaces do, basically PSCI) when arm32 power management code was being pushed upstream we would not have that power management arm/mach code today. PSCI is there to solve that problem, and it predates v8, there is no reason to merge code that provides no added value (I am obviously talking about the pseudo-boot protocol this patchset is enabling, not the platforms themselves which we definitely want to support upstream, with some preconditions that are equal for everyone) and to leverage a legacy that does not exist for arm64. Thanks, Lorenzo > > Thanks, > Lina > > >It took years to consolidate it and the main reason was the lack of > >standard interfaces for power down/up sequences that this patchset of > >yours wants to promote in arm64 world. > > > >The lack of standard power interfaces may not have been an issue for you, > >who cares about Qualcomm code, it has been a sore issue for people > >trying to generalize things across ARM platforms in the kernel, which is > >the only sensible way forward. > > > >PSCI is a standard interface (and Qualcomm are already contributing to > >it, for the records) that can certainly be extended, and you are welcome > >to contribute to it, but certainly not ignored. > > > >Thanks, > >Lorenzo > >-- > >To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > >the body of a message to majord...@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14 2015 at 16:32 -0600, Lorenzo Pieralisi wrote: On Tue, Apr 14, 2015 at 03:21:17PM +0100, Kumar Gala wrote: [...] > Looking beyond this set of patches, I can foresee that you won't care > about the generic arm64 cpuidle driver either, or more precisely the > separation between cpuidle subsystem+driver and the SoC-specific > back-end (cpu_operations). That's probably true for what I guess are a number of reasons. I'm guessing the arm64 cpuidle driver expects PSCI. Wrap lines sensibly please. The arm64 cpuidle driver, that is now arm generic cpuidle driver does not expect anything apart from an enable-method (and you pulled part of its back-end implementation for arm32 Qualcomm platforms, FYI). The backend for this SoC would leverage the same platform code as ARM32. The cpu_operations callbacks for init and suspend will call into the the same platform functions used by arm32 QCOM SoCs. Thanks, Lina It took years to consolidate it and the main reason was the lack of standard interfaces for power down/up sequences that this patchset of yours wants to promote in arm64 world. The lack of standard power interfaces may not have been an issue for you, who cares about Qualcomm code, it has been a sore issue for people trying to generalize things across ARM platforms in the kernel, which is the only sensible way forward. PSCI is a standard interface (and Qualcomm are already contributing to it, for the records) that can certainly be extended, and you are welcome to contribute to it, but certainly not ignored. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas wrote: > On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: >> Just speaking as an outsider to this topic, but seems like most/all >> tablets/phones/etc ship with signed firmware. Which means for most of >> the population, upgrading the firmware to a new version which did >> support the standard (assuming it existed), isn't really an option on >> our devices, any more than fixing buggy acpi tables is on our >> laptops.. > > I wouldn't expect most population to build their own kernels on > tablets/phones. And even if you could install a custom kernel, mainline > rarely runs on such devices because of tons of out of tree patches (just > look at the Nexus 9 patches that Kumar pointed at; even ignoring the > booting protocol they are extremely far from an upstreamable form). > my point being, that it happens some times.. for example John Stultz's work on nexus7: https://plus.google.com/111524780435806926688/posts/DzvpMLmzQiQ If this had been a year or two in the future and on some 64b snapdragon, and support for devices with non-PSCI fw is rejected, then he'd be stuck. There are folks who are working to get saner, more-upstream kernels working on devices.. and improving kernel infrastructure for device-needs (well, in my neck of the woods, there is drm/kms atomic and dsi/panel framework stuff.. I'm sure other similar things in other kernel domains). And it seems like that is a good thing to encourage, rather than stymie. BR, -R > -- > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 09:21:17AM -0500, Kumar Gala wrote: > On Apr 13, 2015, at 4:41 AM, Catalin Marinas wrote: > > On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote: > >> On Apr 10, 2015, at 11:10 AM, Catalin Marinas > >> wrote: > >> Qualcomm choose for whatever reasons to not implement it. There are > >> examples on other architectures supporting non-standard platforms all > >> the time (x86 supported Voyager and SGI VIS for a long time). As far > >> as I can tell you are just wanting uniformity to impose this rule. > > > > Don't confuse non-standard hardware (which has always been acceptable on > > ARM) with non-standard ways of entering the kernel from firmware, > > whether it's a primary or secondary CPU. Just look at how many smp_ops > > structures are defined on x86. > > When Voyager was supported it had a unique means for SMP bring up. And was it fixed afterwards on newer board revisions? > In the 4.0 kernel MIPS supports 13 different means, PowerPC has 14 > different means, ARM has 36 different means. Obviously you don't think there is any problem with having 36 different ways to enable secondary CPUs. I have a completely different opinion. While it was not feasible to change the rules on arm32, it's a good opportunity to impose some rules on arm64, given the new AArch64 exception model. > > Looking beyond this set of patches, I can foresee that you won't care > > about the generic arm64 cpuidle driver either, or more precisely the > > separation between cpuidle subsystem+driver and the SoC-specific > > back-end (cpu_operations). > > That’s probably true for what I guess are a number of reasons. I’m > guessing the arm64 cpuidle driver expects PSCI. Lorenzo replied already. It expects a cpu_operations back-end implementing the cpu_suspend function. The only enable-method we have providing cpu_suspend functionality is PSCI. > >>> We haven't really asked for anything difficult like hardware changes, > >>> such decisions are left with Qualcomm. We asked for a standard secure > >>> firmware interface, either an existing one or, if not suitable (with > >>> good arguments), to come up with a proposal for an alternative > >>> _standard_ interface. I don't even have the certitude that the firmware > >>> interface used in these patches would be consistent across Qualcomm > >>> SoCs, let alone being properly documented. > >> > >> If and when those issues arise we can accept or reject that code. > >> Right now when I look at the impact to supporting this to generic > >> arch/arm64 kernel it is either non-existant if we use the > >> CPU_OF_TABLES or extremely minor if we just add an entry to the > >> supported_cpu_ops struct. > > > > Again, see above about how such change is no longer small when each SoC > > does the same. > > There are so many places that we already deal with per SoC uniqueness. > We setup a software interface in the kernel and people develop towards > it. > > Are you saying that going forward all SoCs should have the same > clocking programming interface to ease portability? Do you expect > them all to have the same pin control programming interface if someone > defines a firmware abstraction? What you said is primarily about device interfaces and given how different they are, most of them not even requiring firmware interaction, it doesn't make sense to come up with a firmware abstraction (well, it may actually be impossible). But if you spot some common pattern, it's fine by me to propose such interface. However, what I'm not talking about devices but CPUs. The ARM CPUs are defined by an architecture spec and they have a consistent behaviour. Hardware for CPU powering on/off is not architected/standardised and that's not because ARM wouldn't want to but because SoC vendors want to be able differentiate. Given that (on ARMv8 especially) Linux is not the first thing to run on a CPU out of reset and it may need to go back to firmware for deeper sleep states, it makes sense to at least hide some of the implementation specific SoC details behind a standard firmware interface. It keeps the hardware folk happy as they can design CPU power on/off as they like with little impact on the software world. Yes, I said "little" impact overall, the only thing needed is a shift of such CPU enabling code from the kernel to firmware. ARM even provides an open source (BSD) firmware to make things easier for partners and there is similar work going into U-Boot. Ideally you shouldn't place all the firmware in ROM (just part of it) but even if it is and we find bugs that require working around in the kernel, we can apply quirks on a case by case basis. But what you are arguing about is to plainly ignore this standardisation effort. Long term plan is to avoid most of the SoC specific code in the kernel before device_initcall() level (wouldn't it be nice if you could load the SoC support from modules in initramfs?). The clocks are an exception for the time being but it's
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: > Just speaking as an outsider to this topic, but seems like most/all > tablets/phones/etc ship with signed firmware. Which means for most of > the population, upgrading the firmware to a new version which did > support the standard (assuming it existed), isn't really an option on > our devices, any more than fixing buggy acpi tables is on our > laptops.. I wouldn't expect most population to build their own kernels on tablets/phones. And even if you could install a custom kernel, mainline rarely runs on such devices because of tons of out of tree patches (just look at the Nexus 9 patches that Kumar pointed at; even ignoring the booting protocol they are extremely far from an upstreamable form). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: Just speaking as an outsider to this topic, but seems like most/all tablets/phones/etc ship with signed firmware. Which means for most of the population, upgrading the firmware to a new version which did support the standard (assuming it existed), isn't really an option on our devices, any more than fixing buggy acpi tables is on our laptops.. I wouldn't expect most population to build their own kernels on tablets/phones. And even if you could install a custom kernel, mainline rarely runs on such devices because of tons of out of tree patches (just look at the Nexus 9 patches that Kumar pointed at; even ignoring the booting protocol they are extremely far from an upstreamable form). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 09:21:17AM -0500, Kumar Gala wrote: On Apr 13, 2015, at 4:41 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote: On Apr 10, 2015, at 11:10 AM, Catalin Marinas catalin.mari...@arm.com wrote: Qualcomm choose for whatever reasons to not implement it. There are examples on other architectures supporting non-standard platforms all the time (x86 supported Voyager and SGI VIS for a long time). As far as I can tell you are just wanting uniformity to impose this rule. Don't confuse non-standard hardware (which has always been acceptable on ARM) with non-standard ways of entering the kernel from firmware, whether it's a primary or secondary CPU. Just look at how many smp_ops structures are defined on x86. When Voyager was supported it had a unique means for SMP bring up. And was it fixed afterwards on newer board revisions? In the 4.0 kernel MIPS supports 13 different means, PowerPC has 14 different means, ARM has 36 different means. Obviously you don't think there is any problem with having 36 different ways to enable secondary CPUs. I have a completely different opinion. While it was not feasible to change the rules on arm32, it's a good opportunity to impose some rules on arm64, given the new AArch64 exception model. Looking beyond this set of patches, I can foresee that you won't care about the generic arm64 cpuidle driver either, or more precisely the separation between cpuidle subsystem+driver and the SoC-specific back-end (cpu_operations). That’s probably true for what I guess are a number of reasons. I’m guessing the arm64 cpuidle driver expects PSCI. Lorenzo replied already. It expects a cpu_operations back-end implementing the cpu_suspend function. The only enable-method we have providing cpu_suspend functionality is PSCI. We haven't really asked for anything difficult like hardware changes, such decisions are left with Qualcomm. We asked for a standard secure firmware interface, either an existing one or, if not suitable (with good arguments), to come up with a proposal for an alternative _standard_ interface. I don't even have the certitude that the firmware interface used in these patches would be consistent across Qualcomm SoCs, let alone being properly documented. If and when those issues arise we can accept or reject that code. Right now when I look at the impact to supporting this to generic arch/arm64 kernel it is either non-existant if we use the CPU_OF_TABLES or extremely minor if we just add an entry to the supported_cpu_ops struct. Again, see above about how such change is no longer small when each SoC does the same. There are so many places that we already deal with per SoC uniqueness. We setup a software interface in the kernel and people develop towards it. Are you saying that going forward all SoCs should have the same clocking programming interface to ease portability? Do you expect them all to have the same pin control programming interface if someone defines a firmware abstraction? What you said is primarily about device interfaces and given how different they are, most of them not even requiring firmware interaction, it doesn't make sense to come up with a firmware abstraction (well, it may actually be impossible). But if you spot some common pattern, it's fine by me to propose such interface. However, what I'm not talking about devices but CPUs. The ARM CPUs are defined by an architecture spec and they have a consistent behaviour. Hardware for CPU powering on/off is not architected/standardised and that's not because ARM wouldn't want to but because SoC vendors want to be able differentiate. Given that (on ARMv8 especially) Linux is not the first thing to run on a CPU out of reset and it may need to go back to firmware for deeper sleep states, it makes sense to at least hide some of the implementation specific SoC details behind a standard firmware interface. It keeps the hardware folk happy as they can design CPU power on/off as they like with little impact on the software world. Yes, I said little impact overall, the only thing needed is a shift of such CPU enabling code from the kernel to firmware. ARM even provides an open source (BSD) firmware to make things easier for partners and there is similar work going into U-Boot. Ideally you shouldn't place all the firmware in ROM (just part of it) but even if it is and we find bugs that require working around in the kernel, we can apply quirks on a case by case basis. But what you are arguing about is to plainly ignore this standardisation effort. Long term plan is to avoid most of the SoC specific code in the kernel before device_initcall() level (wouldn't it be nice if you could load the SoC support from modules in initramfs?). The clocks are an exception for the time being but it's something that could be sorted by sane prior firmware initialisation
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote: Just speaking as an outsider to this topic, but seems like most/all tablets/phones/etc ship with signed firmware. Which means for most of the population, upgrading the firmware to a new version which did support the standard (assuming it existed), isn't really an option on our devices, any more than fixing buggy acpi tables is on our laptops.. I wouldn't expect most population to build their own kernels on tablets/phones. And even if you could install a custom kernel, mainline rarely runs on such devices because of tons of out of tree patches (just look at the Nexus 9 patches that Kumar pointed at; even ignoring the booting protocol they are extremely far from an upstreamable form). my point being, that it happens some times.. for example John Stultz's work on nexus7: https://plus.google.com/111524780435806926688/posts/DzvpMLmzQiQ If this had been a year or two in the future and on some 64b snapdragon, and support for devices with non-PSCI fw is rejected, then he'd be stuck. There are folks who are working to get saner, more-upstream kernels working on devices.. and improving kernel infrastructure for device-needs (well, in my neck of the woods, there is drm/kms atomic and dsi/panel framework stuff.. I'm sure other similar things in other kernel domains). And it seems like that is a good thing to encourage, rather than stymie. BR, -R -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14 2015 at 16:32 -0600, Lorenzo Pieralisi wrote: On Tue, Apr 14, 2015 at 03:21:17PM +0100, Kumar Gala wrote: [...] Looking beyond this set of patches, I can foresee that you won't care about the generic arm64 cpuidle driver either, or more precisely the separation between cpuidle subsystem+driver and the SoC-specific back-end (cpu_operations). That's probably true for what I guess are a number of reasons. I'm guessing the arm64 cpuidle driver expects PSCI. Wrap lines sensibly please. The arm64 cpuidle driver, that is now arm generic cpuidle driver does not expect anything apart from an enable-method (and you pulled part of its back-end implementation for arm32 Qualcomm platforms, FYI). The backend for this SoC would leverage the same platform code as ARM32. The cpu_operations callbacks for init and suspend will call into the the same platform functions used by arm32 QCOM SoCs. Thanks, Lina It took years to consolidate it and the main reason was the lack of standard interfaces for power down/up sequences that this patchset of yours wants to promote in arm64 world. The lack of standard power interfaces may not have been an issue for you, who cares about Qualcomm code, it has been a sore issue for people trying to generalize things across ARM platforms in the kernel, which is the only sensible way forward. PSCI is a standard interface (and Qualcomm are already contributing to it, for the records) that can certainly be extended, and you are welcome to contribute to it, but certainly not ignored. Thanks, Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Wed, Apr 15, 2015 at 05:17:59PM +0100, Lina Iyer wrote: On Tue, Apr 14 2015 at 16:32 -0600, Lorenzo Pieralisi wrote: On Tue, Apr 14, 2015 at 03:21:17PM +0100, Kumar Gala wrote: [...] Looking beyond this set of patches, I can foresee that you won't care about the generic arm64 cpuidle driver either, or more precisely the separation between cpuidle subsystem+driver and the SoC-specific back-end (cpu_operations). That's probably true for what I guess are a number of reasons. I'm guessing the arm64 cpuidle driver expects PSCI. Wrap lines sensibly please. The arm64 cpuidle driver, that is now arm generic cpuidle driver does not expect anything apart from an enable-method (and you pulled part of its back-end implementation for arm32 Qualcomm platforms, FYI). The backend for this SoC would leverage the same platform code as ARM32. The cpu_operations callbacks for init and suspend will call into the the same platform functions used by arm32 QCOM SoCs. It is understood, but this does not mean we should merge this patchset, actually it is the other way around. It was extremely complicated to factor out some common CPUidle bits because of the prolification of power down interfaces in arm/mach code, each with its quirks du jour. If we had a standard interface (that encompasses what all ARM mach code power interfaces do, basically PSCI) when arm32 power management code was being pushed upstream we would not have that power management arm/mach code today. PSCI is there to solve that problem, and it predates v8, there is no reason to merge code that provides no added value (I am obviously talking about the pseudo-boot protocol this patchset is enabling, not the platforms themselves which we definitely want to support upstream, with some preconditions that are equal for everyone) and to leverage a legacy that does not exist for arm64. Thanks, Lorenzo Thanks, Lina It took years to consolidate it and the main reason was the lack of standard interfaces for power down/up sequences that this patchset of yours wants to promote in arm64 world. The lack of standard power interfaces may not have been an issue for you, who cares about Qualcomm code, it has been a sore issue for people trying to generalize things across ARM platforms in the kernel, which is the only sensible way forward. PSCI is a standard interface (and Qualcomm are already contributing to it, for the records) that can certainly be extended, and you are welcome to contribute to it, but certainly not ignored. Thanks, Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 03:21:17PM +0100, Kumar Gala wrote: [...] > > Looking beyond this set of patches, I can foresee that you won't care > > about the generic arm64 cpuidle driver either, or more precisely the > > separation between cpuidle subsystem+driver and the SoC-specific > > back-end (cpu_operations). > > That's probably true for what I guess are a number of reasons. I'm guessing > the arm64 cpuidle driver expects PSCI. Wrap lines sensibly please. The arm64 cpuidle driver, that is now arm generic cpuidle driver does not expect anything apart from an enable-method (and you pulled part of its back-end implementation for arm32 Qualcomm platforms, FYI). It took years to consolidate it and the main reason was the lack of standard interfaces for power down/up sequences that this patchset of yours wants to promote in arm64 world. The lack of standard power interfaces may not have been an issue for you, who cares about Qualcomm code, it has been a sore issue for people trying to generalize things across ARM platforms in the kernel, which is the only sensible way forward. PSCI is a standard interface (and Qualcomm are already contributing to it, for the records) that can certainly be extended, and you are welcome to contribute to it, but certainly not ignored. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 5:17 PM, Catalin Marinas wrote: > On Tue, Apr 14, 2015 at 02:49:04PM -0500, Kumar Gala wrote: >> On Apr 14, 2015, at 11:36 AM, Mark Rutland wrote: >> > On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: >> >> On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: >> >>> This patch set adds support for SMP boot on the MSM8x16 family of >> >>> Qualcomm SoCs. >> >>> >> >>> To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM >> >>> interfaces to >> >>> setup the boot/release addresses for the secondary CPUs. In addition we >> >>> need >> >>> a uniquie set of cpu ops. I'm aware the desired methods for booting >> >>> secondary >> >>> CPUs is either via spintable or PSCI. However, these SoCs are shipping >> >>> with a >> >>> firmware that does not support those methods. >> >> >> >> And the reason is? Some guesses: >> >> >> >> a) QC doesn't think boot interface (and cpuidle) standardisation is >> >> worth the effort (to put it nicely) >> >> b) The hardware was available before we even mentioned PSCI >> >> c) PSCI is not suitable for the QC's SCM interface >> >> d) Any combination of the above >> >> >> >> I strongly suspect it's point (a). Should we expect future QC hardware >> >> to do the same? >> >> >> >> You could argue the reason was (b), though we've been discussing PSCI >> >> for at least two years and, according to QC press releases, MSM8916 >> >> started sampling in 2014. >> >> >> >> The only valid reason is (c) and if that's the case, I would expect a >> >> proposal for a new firmware interface protocol (it could be PSCI-based), >> >> well documented, that can be shared with others that may encounter the >> >> same shortcomings. >> > >> > There's no need to even fork PSCI. The PSCI specification will evolve >> > over time as vendors request changes and we try to accomodate them. >> > >> > If there's something that PSCI doesn't do that you need it to, contact >> > ARM. Other vendors already have. > > Mostly yes but there may be valid reasons for not being able to use > PSCI. The spin-table method is still a firmware interface, though not > necessarily secure (a.k.a. SMC-based). The ACPI parking protocol is > another and, who knows, maybe we define a way to park CPUs back to > firmware without SMC calls (when EL3 is not available). > >> But what is someone to do between the period of getting PSCI spec >> updated and needing to ship a product with firmware? >> >> The take still sounds like if you don’t implement an exact version of >> PSCI you are screwed from being supported in the upstream ARM64 >> kernel. > > These are silly arguments. There is a big difference between "we > couldn't get the firmware implementing the standard for the early > silicon but we are working on fixing it for future revisions" vs. "we > don't give a s**t about these standards, the kernel must be inclusive". > So please make up your mind on which direction you want to pursue. > Just speaking as an outsider to this topic, but seems like most/all tablets/phones/etc ship with signed firmware. Which means for most of the population, upgrading the firmware to a new version which did support the standard (assuming it existed), isn't really an option on our devices, any more than fixing buggy acpi tables is on our laptops.. BR, -R > -- > Catalin > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 02:49:04PM -0500, Kumar Gala wrote: > On Apr 14, 2015, at 11:36 AM, Mark Rutland wrote: > > On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: > >> On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: > >>> This patch set adds support for SMP boot on the MSM8x16 family of > >>> Qualcomm SoCs. > >>> > >>> To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM > >>> interfaces to > >>> setup the boot/release addresses for the secondary CPUs. In addition we > >>> need > >>> a uniquie set of cpu ops. I'm aware the desired methods for booting > >>> secondary > >>> CPUs is either via spintable or PSCI. However, these SoCs are shipping > >>> with a > >>> firmware that does not support those methods. > >> > >> And the reason is? Some guesses: > >> > >> a) QC doesn't think boot interface (and cpuidle) standardisation is > >> worth the effort (to put it nicely) > >> b) The hardware was available before we even mentioned PSCI > >> c) PSCI is not suitable for the QC's SCM interface > >> d) Any combination of the above > >> > >> I strongly suspect it's point (a). Should we expect future QC hardware > >> to do the same? > >> > >> You could argue the reason was (b), though we've been discussing PSCI > >> for at least two years and, according to QC press releases, MSM8916 > >> started sampling in 2014. > >> > >> The only valid reason is (c) and if that's the case, I would expect a > >> proposal for a new firmware interface protocol (it could be PSCI-based), > >> well documented, that can be shared with others that may encounter the > >> same shortcomings. > > > > There's no need to even fork PSCI. The PSCI specification will evolve > > over time as vendors request changes and we try to accomodate them. > > > > If there's something that PSCI doesn't do that you need it to, contact > > ARM. Other vendors already have. Mostly yes but there may be valid reasons for not being able to use PSCI. The spin-table method is still a firmware interface, though not necessarily secure (a.k.a. SMC-based). The ACPI parking protocol is another and, who knows, maybe we define a way to park CPUs back to firmware without SMC calls (when EL3 is not available). > But what is someone to do between the period of getting PSCI spec > updated and needing to ship a product with firmware? > > The take still sounds like if you don’t implement an exact version of > PSCI you are screwed from being supported in the upstream ARM64 > kernel. These are silly arguments. There is a big difference between "we couldn't get the firmware implementing the standard for the early silicon but we are working on fixing it for future revisions" vs. "we don't give a s**t about these standards, the kernel must be inclusive". So please make up your mind on which direction you want to pursue. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
> On Apr 14, 2015, at 11:36 AM, Mark Rutland wrote: > > On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: >> On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: >>> This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm >>> SoCs. >>> >>> To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM >>> interfaces to >>> setup the boot/release addresses for the secondary CPUs. In addition we >>> need >>> a uniquie set of cpu ops. I'm aware the desired methods for booting >>> secondary >>> CPUs is either via spintable or PSCI. However, these SoCs are shipping >>> with a >>> firmware that does not support those methods. >> >> And the reason is? Some guesses: >> >> a) QC doesn't think boot interface (and cpuidle) standardisation is >> worth the effort (to put it nicely) >> b) The hardware was available before we even mentioned PSCI >> c) PSCI is not suitable for the QC's SCM interface >> d) Any combination of the above >> >> I strongly suspect it's point (a). Should we expect future QC hardware >> to do the same? >> >> You could argue the reason was (b), though we've been discussing PSCI >> for at least two years and, according to QC press releases, MSM8916 >> started sampling in 2014. >> >> The only valid reason is (c) and if that's the case, I would expect a >> proposal for a new firmware interface protocol (it could be PSCI-based), >> well documented, that can be shared with others that may encounter the >> same shortcomings. > > There's no need to even fork PSCI. The PSCI specification will evolve > over time as vendors request changes and we try to accomodate them. > > If there's something that PSCI doesn't do that you need it to, contact > ARM. Other vendors already have. But what is someone to do between the period of getting PSCI spec updated and needing to ship a product with firmware? The take still sounds like if you don’t implement an exact version of PSCI you are screwed from being supported in the upstream ARM64 kernel. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: > On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: > > This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm > > SoCs. > > > > To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM > > interfaces to > > setup the boot/release addresses for the secondary CPUs. In addition we > > need > > a uniquie set of cpu ops. I'm aware the desired methods for booting > > secondary > > CPUs is either via spintable or PSCI. However, these SoCs are shipping > > with a > > firmware that does not support those methods. > > And the reason is? Some guesses: > > a) QC doesn't think boot interface (and cpuidle) standardisation is >worth the effort (to put it nicely) > b) The hardware was available before we even mentioned PSCI > c) PSCI is not suitable for the QC's SCM interface > d) Any combination of the above > > I strongly suspect it's point (a). Should we expect future QC hardware > to do the same? > > You could argue the reason was (b), though we've been discussing PSCI > for at least two years and, according to QC press releases, MSM8916 > started sampling in 2014. > > The only valid reason is (c) and if that's the case, I would expect a > proposal for a new firmware interface protocol (it could be PSCI-based), > well documented, that can be shared with others that may encounter the > same shortcomings. There's no need to even fork PSCI. The PSCI specification will evolve over time as vendors request changes and we try to accomodate them. If there's something that PSCI doesn't do that you need it to, contact ARM. Other vendors already have. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 03:44:11PM +0100, Kumar Gala wrote:
>
> > On Apr 14, 2015, at 9:21 AM, Kumar Gala wrote:
> >
>
> So please come up with proper technical arguments rather than the kernel
> should take whatever SoC vendors dreamt of.
> >>>
> >>> There is no technical argument to be made. This is about the
> >>> community and you as maintainer wanting to accept code that complies
> >>> to your decision or not.
> >>
> >> If you are not willing to make technical arguments, I don't have to
> >> provide any further reasons in this thread. It's your choice. In the
> >> meantime, the short answer is NAK.
>
> I assume you would than NAK someone trying to get support for their
> Nexus 9 Tablet using a Tegra K1.
That would depend on how they try to boot secondary CPUs. It's
unfortunate that a product is shipping with an arbitrary implementation
specific SMP bringup mechanism, but its existence doesn't necessitate
that we support it.
People are currently working on PSCI support for 32-bit Tegra platforms
in U-Boot, and it's my understanding that a reasonable proportion of
that could should be possible to reuse for 64-bit. That may be
applicable to the Nexus 9.
Otherwise it's possible to have a shim which can place the secondaries
into a spin-table. It looks like that would be necessary anyway; there
seem to be some egregious boot protocol violations.
> It appears the shipping code for that device didn’t use PSCI (again guessing
> because it wasn’t available at the time).
>
> https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/mach-tegra/platsmp.c
Commit e790f1deb26a2e23 ("arm64: psci: add support for PSCI invocations
from the kernel") has been upstream since v3.9-rc1. It's even in the
(v3.10 derived) tree you link to:
https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/kernel/psci.c
As is spin-table:
https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/kernel/smp_spin_table.c
> If so, I find this counter to the Linux kernel communities normal desire to
> support the most hardware platforms.
Supporting hardware platforms doesn't mean that we must accept code
which we believe to be problematic.
We don't want implementation-specific SMP bringup mechanisms because
we've learnt from the lessons of the past. They're almost always
ill-defined, not reusable, and they're a maintenance burden for all
system software targeting ARM which gets worse over time.
If there are technical problems with the existing mechanisms, we're open
to solving them. Others have engaged with the kernel community and/or
ARM (in the case of PSCI) to do so, and all others upstream so far have
used common enable methods.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
> On Apr 14, 2015, at 9:21 AM, Kumar Gala wrote: > So please come up with proper technical arguments rather than the kernel should take whatever SoC vendors dreamt of. >>> >>> There is no technical argument to be made. This is about the >>> community and you as maintainer wanting to accept code that complies >>> to your decision or not. >> >> If you are not willing to make technical arguments, I don't have to >> provide any further reasons in this thread. It's your choice. In the >> meantime, the short answer is NAK. I assume you would than NAK someone trying to get support for their Nexus 9 Tablet using a Tegra K1. It appears the shipping code for that device didn’t use PSCI (again guessing because it wasn’t available at the time). https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/mach-tegra/platsmp.c If so, I find this counter to the Linux kernel communities normal desire to support the most hardware platforms. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
> On Apr 13, 2015, at 4:41 AM, Catalin Marinas wrote: > > On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote: >> On Apr 10, 2015, at 11:10 AM, Catalin Marinas >> wrote: >>> On Fri, Apr 10, 2015 at 10:24:46AM -0500, Kumar Gala wrote: On Apr 10, 2015, at 5:05 AM, Catalin Marinas wrote: > On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: >> This patch set adds support for SMP boot on the MSM8x16 family of >> Qualcomm SoCs. >> >> To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM >> interfaces to >> setup the boot/release addresses for the secondary CPUs. In addition we >> need >> a uniquie set of cpu ops. I'm aware the desired methods for booting >> secondary >> CPUs is either via spintable or PSCI. However, these SoCs are shipping >> with a >> firmware that does not support those methods. > > And the reason is? Some guesses: > > a) QC doesn't think boot interface (and cpuidle) standardisation is > worth the effort (to put it nicely) > b) The hardware was available before we even mentioned PSCI > c) PSCI is not suitable for the QC's SCM interface > d) Any combination of the above > > I strongly suspect it's point (a). Should we expect future QC hardware > to do the same? > > You could argue the reason was (b), though we've been discussing PSCI > for at least two years and, according to QC press releases, MSM8916 > started sampling in 2014. > > The only valid reason is (c) and if that's the case, I would expect a > proposal for a new firmware interface protocol (it could be PSCI-based), > well documented, that can be shared with others that may encounter the > same shortcomings. Does it matter? I’ve always felt the kernel was a place of inclusion. Qualcomm choose for whatever reason to not use PSCI or spin table. You don’t like it, I might not like it, but it is what it is. >>> >>> Yes, it matters, but only if Qualcomm wants the SoC support in mainline. >>> Just because Qualcomm Inc does not want to invest in implementing a >>> standard firmware interface is not a good enough reason to merge the >>> kernel code. >> >> The reason to merge the code upstream it expands functionality for a >> platform. > > This alone has never been a good enough reason. Code (both design and > style) needs to pass the review. You haven’t really made any comments about the code itself, other than just not liking the firmware interface. > There is nothing that says when someone licenses an ARM core that they >> must also implement this standard. > > Just to be perfectly clear: this has nothing to do with ARM Ltd nor the > ARM hardware licensing terms. ARM Ltd doesn't even require you to use > Linux, that's your choice. But when you make an OS choice, you have to > abide by its rules. But Linux has tended to support hardware as broadly as it can. Yes it tries to get firmware to improve but there are numerous devices with embedded firmware interfaces that Linux probably would love to change but deals with because they are fixed. > Qualcomm choose for whatever reasons to not implement it. There are >> examples on other architectures supporting non-standard platforms all >> the time (x86 supported Voyager and SGI VIS for a long time). As far >> as I can tell you are just wanting uniformity to impose this rule. > > Don't confuse non-standard hardware (which has always been acceptable on > ARM) with non-standard ways of entering the kernel from firmware, > whether it's a primary or secondary CPU. Just look at how many smp_ops > structures are defined on x86. When Voyager was supported it had a unique means for SMP bring up. In the 4.0 kernel MIPS supports 13 different means, PowerPC has 14 different means, ARM has 36 different means. >>> What if Qualcomm decides that it doesn't like DT, nor ACPI but comes up >>> with yet another way to describe hardware because that's what the >>> firmware provides? Should the kernel community take it? You could argue >>> that this is a significant change but it's about the principle. And each >>> SoC with its own non-standard boot protocol for no good reason is >>> significant. >> >> I wouldn’t argue that because we are talking about something that has >> an extremely small impact on the maintainability or changes to how the >> kernel actually functions. > > It's not about one particular case but about where to draw the line. > Just multiply this change by the number of SoC variants and you'll no > longer see this as "extremely small impact". Why would we accept it for > Qualcomm and reject it for others? It's either giving up trying to > standardise this altogether or enforcing rules. Since you only care > about Qualcomm hardware, you don't care about the overall picture. > > By your reasoning, Qualcomm may solely decide to change the booting for > the primary CPU
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. And the reason is? Some guesses: a) QC doesn't think boot interface (and cpuidle) standardisation is worth the effort (to put it nicely) b) The hardware was available before we even mentioned PSCI c) PSCI is not suitable for the QC's SCM interface d) Any combination of the above I strongly suspect it's point (a). Should we expect future QC hardware to do the same? You could argue the reason was (b), though we've been discussing PSCI for at least two years and, according to QC press releases, MSM8916 started sampling in 2014. The only valid reason is (c) and if that's the case, I would expect a proposal for a new firmware interface protocol (it could be PSCI-based), well documented, that can be shared with others that may encounter the same shortcomings. There's no need to even fork PSCI. The PSCI specification will evolve over time as vendors request changes and we try to accomodate them. If there's something that PSCI doesn't do that you need it to, contact ARM. Other vendors already have. Mark. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Apr 13, 2015, at 4:41 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote: On Apr 10, 2015, at 11:10 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Apr 10, 2015 at 10:24:46AM -0500, Kumar Gala wrote: On Apr 10, 2015, at 5:05 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. And the reason is? Some guesses: a) QC doesn't think boot interface (and cpuidle) standardisation is worth the effort (to put it nicely) b) The hardware was available before we even mentioned PSCI c) PSCI is not suitable for the QC's SCM interface d) Any combination of the above I strongly suspect it's point (a). Should we expect future QC hardware to do the same? You could argue the reason was (b), though we've been discussing PSCI for at least two years and, according to QC press releases, MSM8916 started sampling in 2014. The only valid reason is (c) and if that's the case, I would expect a proposal for a new firmware interface protocol (it could be PSCI-based), well documented, that can be shared with others that may encounter the same shortcomings. Does it matter? I’ve always felt the kernel was a place of inclusion. Qualcomm choose for whatever reason to not use PSCI or spin table. You don’t like it, I might not like it, but it is what it is. Yes, it matters, but only if Qualcomm wants the SoC support in mainline. Just because Qualcomm Inc does not want to invest in implementing a standard firmware interface is not a good enough reason to merge the kernel code. The reason to merge the code upstream it expands functionality for a platform. This alone has never been a good enough reason. Code (both design and style) needs to pass the review. You haven’t really made any comments about the code itself, other than just not liking the firmware interface. There is nothing that says when someone licenses an ARM core that they must also implement this standard. Just to be perfectly clear: this has nothing to do with ARM Ltd nor the ARM hardware licensing terms. ARM Ltd doesn't even require you to use Linux, that's your choice. But when you make an OS choice, you have to abide by its rules. But Linux has tended to support hardware as broadly as it can. Yes it tries to get firmware to improve but there are numerous devices with embedded firmware interfaces that Linux probably would love to change but deals with because they are fixed. Qualcomm choose for whatever reasons to not implement it. There are examples on other architectures supporting non-standard platforms all the time (x86 supported Voyager and SGI VIS for a long time). As far as I can tell you are just wanting uniformity to impose this rule. Don't confuse non-standard hardware (which has always been acceptable on ARM) with non-standard ways of entering the kernel from firmware, whether it's a primary or secondary CPU. Just look at how many smp_ops structures are defined on x86. When Voyager was supported it had a unique means for SMP bring up. In the 4.0 kernel MIPS supports 13 different means, PowerPC has 14 different means, ARM has 36 different means. What if Qualcomm decides that it doesn't like DT, nor ACPI but comes up with yet another way to describe hardware because that's what the firmware provides? Should the kernel community take it? You could argue that this is a significant change but it's about the principle. And each SoC with its own non-standard boot protocol for no good reason is significant. I wouldn’t argue that because we are talking about something that has an extremely small impact on the maintainability or changes to how the kernel actually functions. It's not about one particular case but about where to draw the line. Just multiply this change by the number of SoC variants and you'll no longer see this as extremely small impact. Why would we accept it for Qualcomm and reject it for others? It's either giving up trying to standardise this altogether or enforcing rules. Since you only care about Qualcomm hardware, you don't care about the overall picture. By your reasoning, Qualcomm may solely decide to change the booting for the primary CPU as well, ignore single Image requirements (well, why would Qualcomm care about other SoCs) and so on. The kernel community should just accept such changes without questioning because they expand platform functionality. I
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 03:44:11PM +0100, Kumar Gala wrote: On Apr 14, 2015, at 9:21 AM, Kumar Gala ga...@codeaurora.org wrote: So please come up with proper technical arguments rather than the kernel should take whatever SoC vendors dreamt of. There is no technical argument to be made. This is about the community and you as maintainer wanting to accept code that complies to your decision or not. If you are not willing to make technical arguments, I don't have to provide any further reasons in this thread. It's your choice. In the meantime, the short answer is NAK. I assume you would than NAK someone trying to get support for their Nexus 9 Tablet using a Tegra K1. That would depend on how they try to boot secondary CPUs. It's unfortunate that a product is shipping with an arbitrary implementation specific SMP bringup mechanism, but its existence doesn't necessitate that we support it. People are currently working on PSCI support for 32-bit Tegra platforms in U-Boot, and it's my understanding that a reasonable proportion of that could should be possible to reuse for 64-bit. That may be applicable to the Nexus 9. Otherwise it's possible to have a shim which can place the secondaries into a spin-table. It looks like that would be necessary anyway; there seem to be some egregious boot protocol violations. It appears the shipping code for that device didn’t use PSCI (again guessing because it wasn’t available at the time). https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/mach-tegra/platsmp.c Commit e790f1deb26a2e23 (arm64: psci: add support for PSCI invocations from the kernel) has been upstream since v3.9-rc1. It's even in the (v3.10 derived) tree you link to: https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/kernel/psci.c As is spin-table: https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/kernel/smp_spin_table.c If so, I find this counter to the Linux kernel communities normal desire to support the most hardware platforms. Supporting hardware platforms doesn't mean that we must accept code which we believe to be problematic. We don't want implementation-specific SMP bringup mechanisms because we've learnt from the lessons of the past. They're almost always ill-defined, not reusable, and they're a maintenance burden for all system software targeting ARM which gets worse over time. If there are technical problems with the existing mechanisms, we're open to solving them. Others have engaged with the kernel community and/or ARM (in the case of PSCI) to do so, and all others upstream so far have used common enable methods. Mark. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Apr 14, 2015, at 9:21 AM, Kumar Gala ga...@codeaurora.org wrote: So please come up with proper technical arguments rather than the kernel should take whatever SoC vendors dreamt of. There is no technical argument to be made. This is about the community and you as maintainer wanting to accept code that complies to your decision or not. If you are not willing to make technical arguments, I don't have to provide any further reasons in this thread. It's your choice. In the meantime, the short answer is NAK. I assume you would than NAK someone trying to get support for their Nexus 9 Tablet using a Tegra K1. It appears the shipping code for that device didn’t use PSCI (again guessing because it wasn’t available at the time). https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/arm64/mach-tegra/platsmp.c If so, I find this counter to the Linux kernel communities normal desire to support the most hardware platforms. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 5:17 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Apr 14, 2015 at 02:49:04PM -0500, Kumar Gala wrote: On Apr 14, 2015, at 11:36 AM, Mark Rutland mark.rutl...@arm.com wrote: On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. And the reason is? Some guesses: a) QC doesn't think boot interface (and cpuidle) standardisation is worth the effort (to put it nicely) b) The hardware was available before we even mentioned PSCI c) PSCI is not suitable for the QC's SCM interface d) Any combination of the above I strongly suspect it's point (a). Should we expect future QC hardware to do the same? You could argue the reason was (b), though we've been discussing PSCI for at least two years and, according to QC press releases, MSM8916 started sampling in 2014. The only valid reason is (c) and if that's the case, I would expect a proposal for a new firmware interface protocol (it could be PSCI-based), well documented, that can be shared with others that may encounter the same shortcomings. There's no need to even fork PSCI. The PSCI specification will evolve over time as vendors request changes and we try to accomodate them. If there's something that PSCI doesn't do that you need it to, contact ARM. Other vendors already have. Mostly yes but there may be valid reasons for not being able to use PSCI. The spin-table method is still a firmware interface, though not necessarily secure (a.k.a. SMC-based). The ACPI parking protocol is another and, who knows, maybe we define a way to park CPUs back to firmware without SMC calls (when EL3 is not available). But what is someone to do between the period of getting PSCI spec updated and needing to ship a product with firmware? The take still sounds like if you don’t implement an exact version of PSCI you are screwed from being supported in the upstream ARM64 kernel. These are silly arguments. There is a big difference between we couldn't get the firmware implementing the standard for the early silicon but we are working on fixing it for future revisions vs. we don't give a s**t about these standards, the kernel must be inclusive. So please make up your mind on which direction you want to pursue. Just speaking as an outsider to this topic, but seems like most/all tablets/phones/etc ship with signed firmware. Which means for most of the population, upgrading the firmware to a new version which did support the standard (assuming it existed), isn't really an option on our devices, any more than fixing buggy acpi tables is on our laptops.. BR, -R -- Catalin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Apr 14, 2015, at 11:36 AM, Mark Rutland mark.rutl...@arm.com wrote: On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. And the reason is? Some guesses: a) QC doesn't think boot interface (and cpuidle) standardisation is worth the effort (to put it nicely) b) The hardware was available before we even mentioned PSCI c) PSCI is not suitable for the QC's SCM interface d) Any combination of the above I strongly suspect it's point (a). Should we expect future QC hardware to do the same? You could argue the reason was (b), though we've been discussing PSCI for at least two years and, according to QC press releases, MSM8916 started sampling in 2014. The only valid reason is (c) and if that's the case, I would expect a proposal for a new firmware interface protocol (it could be PSCI-based), well documented, that can be shared with others that may encounter the same shortcomings. There's no need to even fork PSCI. The PSCI specification will evolve over time as vendors request changes and we try to accomodate them. If there's something that PSCI doesn't do that you need it to, contact ARM. Other vendors already have. But what is someone to do between the period of getting PSCI spec updated and needing to ship a product with firmware? The take still sounds like if you don’t implement an exact version of PSCI you are screwed from being supported in the upstream ARM64 kernel. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 03:21:17PM +0100, Kumar Gala wrote: [...] Looking beyond this set of patches, I can foresee that you won't care about the generic arm64 cpuidle driver either, or more precisely the separation between cpuidle subsystem+driver and the SoC-specific back-end (cpu_operations). That's probably true for what I guess are a number of reasons. I'm guessing the arm64 cpuidle driver expects PSCI. Wrap lines sensibly please. The arm64 cpuidle driver, that is now arm generic cpuidle driver does not expect anything apart from an enable-method (and you pulled part of its back-end implementation for arm32 Qualcomm platforms, FYI). It took years to consolidate it and the main reason was the lack of standard interfaces for power down/up sequences that this patchset of yours wants to promote in arm64 world. The lack of standard power interfaces may not have been an issue for you, who cares about Qualcomm code, it has been a sore issue for people trying to generalize things across ARM platforms in the kernel, which is the only sensible way forward. PSCI is a standard interface (and Qualcomm are already contributing to it, for the records) that can certainly be extended, and you are welcome to contribute to it, but certainly not ignored. Thanks, Lorenzo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Tue, Apr 14, 2015 at 02:49:04PM -0500, Kumar Gala wrote: On Apr 14, 2015, at 11:36 AM, Mark Rutland mark.rutl...@arm.com wrote: On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote: On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. And the reason is? Some guesses: a) QC doesn't think boot interface (and cpuidle) standardisation is worth the effort (to put it nicely) b) The hardware was available before we even mentioned PSCI c) PSCI is not suitable for the QC's SCM interface d) Any combination of the above I strongly suspect it's point (a). Should we expect future QC hardware to do the same? You could argue the reason was (b), though we've been discussing PSCI for at least two years and, according to QC press releases, MSM8916 started sampling in 2014. The only valid reason is (c) and if that's the case, I would expect a proposal for a new firmware interface protocol (it could be PSCI-based), well documented, that can be shared with others that may encounter the same shortcomings. There's no need to even fork PSCI. The PSCI specification will evolve over time as vendors request changes and we try to accomodate them. If there's something that PSCI doesn't do that you need it to, contact ARM. Other vendors already have. Mostly yes but there may be valid reasons for not being able to use PSCI. The spin-table method is still a firmware interface, though not necessarily secure (a.k.a. SMC-based). The ACPI parking protocol is another and, who knows, maybe we define a way to park CPUs back to firmware without SMC calls (when EL3 is not available). But what is someone to do between the period of getting PSCI spec updated and needing to ship a product with firmware? The take still sounds like if you don’t implement an exact version of PSCI you are screwed from being supported in the upstream ARM64 kernel. These are silly arguments. There is a big difference between we couldn't get the firmware implementing the standard for the early silicon but we are working on fixing it for future revisions vs. we don't give a s**t about these standards, the kernel must be inclusive. So please make up your mind on which direction you want to pursue. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote: > On Apr 10, 2015, at 11:10 AM, Catalin Marinas wrote: > > On Fri, Apr 10, 2015 at 10:24:46AM -0500, Kumar Gala wrote: > >> On Apr 10, 2015, at 5:05 AM, Catalin Marinas > >> wrote: > >>> On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: > This patch set adds support for SMP boot on the MSM8x16 family of > Qualcomm SoCs. > > To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM > interfaces to > setup the boot/release addresses for the secondary CPUs. In addition we > need > a uniquie set of cpu ops. I'm aware the desired methods for booting > secondary > CPUs is either via spintable or PSCI. However, these SoCs are shipping > with a > firmware that does not support those methods. > >>> > >>> And the reason is? Some guesses: > >>> > >>> a) QC doesn't think boot interface (and cpuidle) standardisation is > >>> worth the effort (to put it nicely) > >>> b) The hardware was available before we even mentioned PSCI > >>> c) PSCI is not suitable for the QC's SCM interface > >>> d) Any combination of the above > >>> > >>> I strongly suspect it's point (a). Should we expect future QC hardware > >>> to do the same? > >>> > >>> You could argue the reason was (b), though we've been discussing PSCI > >>> for at least two years and, according to QC press releases, MSM8916 > >>> started sampling in 2014. > >>> > >>> The only valid reason is (c) and if that's the case, I would expect a > >>> proposal for a new firmware interface protocol (it could be PSCI-based), > >>> well documented, that can be shared with others that may encounter the > >>> same shortcomings. > >> > >> Does it matter? I’ve always felt the kernel was a place of inclusion. > >> Qualcomm choose for whatever reason to not use PSCI or spin table. > >> You don’t like it, I might not like it, but it is what it is. > > > > Yes, it matters, but only if Qualcomm wants the SoC support in mainline. > > Just because Qualcomm Inc does not want to invest in implementing a > > standard firmware interface is not a good enough reason to merge the > > kernel code. > > The reason to merge the code upstream it expands functionality for a > platform. This alone has never been a good enough reason. Code (both design and style) needs to pass the review. > There is nothing that says when someone licenses an ARM core that they > must also implement this standard. Just to be perfectly clear: this has nothing to do with ARM Ltd nor the ARM hardware licensing terms. ARM Ltd doesn't even require you to use Linux, that's your choice. But when you make an OS choice, you have to abide by its rules. > Qualcomm choose for whatever reasons to not implement it. There are > examples on other architectures supporting non-standard platforms all > the time (x86 supported Voyager and SGI VIS for a long time). As far > as I can tell you are just wanting uniformity to impose this rule. Don't confuse non-standard hardware (which has always been acceptable on ARM) with non-standard ways of entering the kernel from firmware, whether it's a primary or secondary CPU. Just look at how many smp_ops structures are defined on x86. > > What if Qualcomm decides that it doesn't like DT, nor ACPI but comes up > > with yet another way to describe hardware because that's what the > > firmware provides? Should the kernel community take it? You could argue > > that this is a significant change but it's about the principle. And each > > SoC with its own non-standard boot protocol for no good reason is > > significant. > > I wouldn’t argue that because we are talking about something that has > an extremely small impact on the maintainability or changes to how the > kernel actually functions. It's not about one particular case but about where to draw the line. Just multiply this change by the number of SoC variants and you'll no longer see this as "extremely small impact". Why would we accept it for Qualcomm and reject it for others? It's either giving up trying to standardise this altogether or enforcing rules. Since you only care about Qualcomm hardware, you don't care about the overall picture. By your reasoning, Qualcomm may solely decide to change the booting for the primary CPU as well, ignore single Image requirements (well, why would Qualcomm care about other SoCs) and so on. The kernel community should just accept such changes without questioning because they expand platform functionality. I am not asking for *hardware* standardisation here, but common software interfaces. > Also, if Qualcomm did come up with some other means to replace DT or > ACPI and felt it was worth trying to get accepted upstream, I would > hope the upstream would look at it before just saying it was not using > some standard. We would still expect proper technical arguments. That's exactly what I'm asking here; is PSCI not suitable for Qualcomm? If not, can
Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote: On Apr 10, 2015, at 11:10 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Apr 10, 2015 at 10:24:46AM -0500, Kumar Gala wrote: On Apr 10, 2015, at 5:05 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. And the reason is? Some guesses: a) QC doesn't think boot interface (and cpuidle) standardisation is worth the effort (to put it nicely) b) The hardware was available before we even mentioned PSCI c) PSCI is not suitable for the QC's SCM interface d) Any combination of the above I strongly suspect it's point (a). Should we expect future QC hardware to do the same? You could argue the reason was (b), though we've been discussing PSCI for at least two years and, according to QC press releases, MSM8916 started sampling in 2014. The only valid reason is (c) and if that's the case, I would expect a proposal for a new firmware interface protocol (it could be PSCI-based), well documented, that can be shared with others that may encounter the same shortcomings. Does it matter? I’ve always felt the kernel was a place of inclusion. Qualcomm choose for whatever reason to not use PSCI or spin table. You don’t like it, I might not like it, but it is what it is. Yes, it matters, but only if Qualcomm wants the SoC support in mainline. Just because Qualcomm Inc does not want to invest in implementing a standard firmware interface is not a good enough reason to merge the kernel code. The reason to merge the code upstream it expands functionality for a platform. This alone has never been a good enough reason. Code (both design and style) needs to pass the review. There is nothing that says when someone licenses an ARM core that they must also implement this standard. Just to be perfectly clear: this has nothing to do with ARM Ltd nor the ARM hardware licensing terms. ARM Ltd doesn't even require you to use Linux, that's your choice. But when you make an OS choice, you have to abide by its rules. Qualcomm choose for whatever reasons to not implement it. There are examples on other architectures supporting non-standard platforms all the time (x86 supported Voyager and SGI VIS for a long time). As far as I can tell you are just wanting uniformity to impose this rule. Don't confuse non-standard hardware (which has always been acceptable on ARM) with non-standard ways of entering the kernel from firmware, whether it's a primary or secondary CPU. Just look at how many smp_ops structures are defined on x86. What if Qualcomm decides that it doesn't like DT, nor ACPI but comes up with yet another way to describe hardware because that's what the firmware provides? Should the kernel community take it? You could argue that this is a significant change but it's about the principle. And each SoC with its own non-standard boot protocol for no good reason is significant. I wouldn’t argue that because we are talking about something that has an extremely small impact on the maintainability or changes to how the kernel actually functions. It's not about one particular case but about where to draw the line. Just multiply this change by the number of SoC variants and you'll no longer see this as extremely small impact. Why would we accept it for Qualcomm and reject it for others? It's either giving up trying to standardise this altogether or enforcing rules. Since you only care about Qualcomm hardware, you don't care about the overall picture. By your reasoning, Qualcomm may solely decide to change the booting for the primary CPU as well, ignore single Image requirements (well, why would Qualcomm care about other SoCs) and so on. The kernel community should just accept such changes without questioning because they expand platform functionality. I am not asking for *hardware* standardisation here, but common software interfaces. Also, if Qualcomm did come up with some other means to replace DT or ACPI and felt it was worth trying to get accepted upstream, I would hope the upstream would look at it before just saying it was not using some standard. We would still expect proper technical arguments. That's exactly what I'm asking here; is PSCI not suitable for Qualcomm? If not, can it be improved? If you have completely different needs, can you come up with a standard firmware interface, which may only be used by Qualcomm for the time
[RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. v2: * Dropped introduction and use of CPU_METHOD_OF_DECLARE * Moved qcom cpu ops from drivers/soc/qcom to arch/arm64/kernel * Renamed msm to qcom in cpu ops code, minor cleans (remove dead defines/code) - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. v2: * Dropped introduction and use of CPU_METHOD_OF_DECLARE * Moved qcom cpu ops from drivers/soc/qcom to arch/arm64/kernel * Renamed msm to qcom in cpu ops code, minor cleans (remove dead defines/code) - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
