On 02/10, Mark Brown wrote: > On Wed, Feb 10, 2016 at 10:36:51AM -0800, Stephen Boyd wrote: > > On 02/10, Georgi Djakov wrote: > > > In some designs we have to talk to the PMIC with SPMI > > transactions to change the mode depending on the voltages. How do > > we plan to handle that case where the regulator control is split > > between two busses, SPMI and MMIO? > > Mixed control interfaces are in general a diaster with Linux, I'd > suggest remonstrating with your system designers about doing them but in > this case since it's a syscon presumably you could hang the device off > the SPMI bus in the cases where that's in use. Agreed about the mixed control interfaces, it's a total nightmare to deal with. Luckily this problem is going to go away in the future, but we're stuck with what we have for this generation of chips. 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. 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. A final note, 8064 is paired with a PMIC on the SSBI bus. We don't have an SSBI regulator driver upstream, so we would need some driver + binding for that regulator style if we want to do this for 8064. -- 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
