Hi Mark, On 04/06/20 13:07, Mark Brown wrote: > On Wed, Jun 03, 2020 at 10:03:16PM +0200, Luca Ceresoli wrote: > >> I suspect the only solution that allows to configure the EN_PIN_CTRLn bits >> correctly in all the possible hardware setups would be to tell in device >> tree / board info whether each enable pin is connected or not (which is a >> hardware _fact_) and which ENx pin should control which regulator output >> (which is a policy). But it would make this simple driver considerably more >> complex. > >> Any suggestion about the correct way to handle this situation would be >> greatly appreciated. > > We can tell if we've got a software controlled GPIO connected, if we > have then we should ensure that it continues to take effect. Ideally yes, but it would be made more complex by the chip flexibility: it's possible to choose which enable pin should drive each output. For example this configuration is supported by the chip: - BUCK0 is on if EN_BUCK0 high AND pin EN0 is active - BUCK1 is on if EN_BUCK1 high AND pin EN0 is active - BUCK2 is on if EN_BUCK2 high AND pin EN1 is active - BUCK3 is on if EN_BUCK3 high (no pin used) - pin EN2 is used as a GPIO (LP875xx acts as an I2C GPIO expander) So it would be absolutely OK to describe in DT that EN0 and EN1 connect the SoC to the LP875xx and that EN2 is connected to something else. But describing in DT the association between enable pins and buck outputs would be more a configuration than hardware description IMO. And I'm not even considering the case where the enable pins are be connected to something else, out of the SoC control, but still meant to be used to control the buck output. > That > should just be a single register write at startup from the sounds of it. Exactly, each buck output has a register containing the bits involved in this discussion. > Otherwise yeah, just ignoring that there's a possibility of a GPIO we > don't know about seems sensible. Thanks, -- Luca
