On 02/10, Mark Brown wrote: > On Wed, Feb 10, 2016 at 11:04:36AM -0800, Stephen Boyd wrote: > > > I don't follow the rest of your mail though. Are you suggesting > > that in this case we put the regulator control into the PMIC > > regulator driver (qcom_spmi-regulator.c) and then use a > > syscon/regmap there to change the voltages inside the MMIO bus? > > That may work but we're going to need to update the binding for > > the SPMI regulator driver then. > > No, why would you want to do that? I'm saying that if the device has a > SPMI interface make that the primary interface for the driver. > Presumably the SPMI bus abstraction is capable of representing this > fairly directly. > > > I'm not really excited about the binding we have here either. > > We're going to have two places in DT where we've created a > > regulator for the same physical regulator. One will be a child of > > the SAW node on the MMIO bus, and another will be a child of the > > PMIC on the SPMI/SSBI bus. In the end, they're both the same > > regulator, so any constraints on one node will need to be applied > > to the other node as well. > > Are you saying that this is a problem with the driver that just got > merged? We got to v4 before I applied the driver... My understanding > was that this is a driver for a new regulator type not a duplicate > interface for existing regulator. Yeah I haven't had the time to properly review this patch. From what I can tell though, if this driver probes first and then the spm driver probes second, the CPU could go idle and then wakeup with a lower voltage than is required. The hardware works like this: there's a regulator on the PMIC that's dedicated to the CPU. Let's call this regulator S1. The PMIC is on the SPMI bus. There's an SPMI master controller inside the SoC. This controller can be used to perform SPMI transactions when software does MMIO read/writes or it can be perform transactions on the behalf of some hardware entity. The controller is called the "PMIC arbiter" because it's arbitrating access to the PMIC between all the sw entities (linux, modem, dsp, etc.) and the hw entities (various SAWs in the system). Typical control of an SPMI regulator can be seen in the qcom_spmi-regulator.c driver. That's a standard SPMI bus regulator driver. The SAWs are "hardwired" to a PMIC regulator based on some silicon configuration. In this example, the SAW would be configured to send commands to the PMIC for the S1 regulator. The SAW hardware will basically takes whatever voltage is written to it in the MMIO space and tacks on an address for S1 before handing that over to the PMIC arbiter to send it to the PMIC. One way to think of this is that each SAW has its own SPMI regulator driver for the one regulator it cares about, except we have to format the payload in the same way that the PMIC would expect it. Now this is all pretty much useless hardware if all we care about is to set voltages from software. Obviously we could just use the SPMI regulator driver that we already have. It's written for the bus that the hardware is actually on and it works! The problem there is that the SAW register is also used during idle/suspend when software isn't running. The CPU power down sequence usually turns off the regulator, but it may also change the voltage to something lower, depending on how deep of idle/suspend we're trying to achieve. This is all done without software intervention. When the CPU wakes up due to some interrupt, the SPM runs the CPU power on sequence which takes whatever is in the SAW register and sends it off to the PMIC to restore the CPU voltage. Again, this is all hardware doing this. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
