Re: [PATCH] ARM: DRA7-evm: Enable SATA PHY and USB PHY power supplies

[Roger Quadros]

On 06/30/2014 10:55 AM, Roger Quadros wrote:
> On 06/26/2014 06:06 PM, Tero Kristo wrote:
>> On 06/26/2014 05:22 PM, Roger Quadros wrote:
>>> +Tero
>>>
>>> On 06/26/2014 12:36 PM, Roger Quadros wrote:
>>>> On 06/26/2014 10:31 AM, Tony Lindgren wrote:
>>>>> * Nishanth Menon <nm@xxxxxx> [140625 15:29]:
>>>>>> On 06/25/2014 07:56 AM, Roger Quadros wrote:
>>>>>>> The SATA and USB PHYs need the 1.8V and 3.3V supplies.
>>>>>>> The PHY drivers/framework don't yet support regulator
>>>>>>> supply so we have to keep these regulators always-on till
>>>>>>> then.
>>>>>>>
>>>>>>> Signed-off-by: Roger Quadros <rogerq@xxxxxx>
>>>>>>> ---
>>>>>>>   arch/arm/boot/dts/dra7-evm.dts | 2 ++
>>>>>>>   1 file changed, 2 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>>>>>>> index 4adc280..99a1f79 100644
>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>>>>> @@ -241,6 +241,7 @@
>>>>>>>                       regulator-min-microvolt = <1800000>;
>>>>>>>                       regulator-max-microvolt = <1800000>;
>>>>>>>                       regulator-boot-on;
>>>>>>> +                    regulator-always-on;

There was a confirmation from the TI hardware team that this 1.8V regulator can't be powered down while the SoC is Active. So we need to have regulator-always-on here.

>>>>>>>                   };
>>>>>>>
>>>>>>>                   ldo9_reg: ldo9 {
>>>>>>> @@ -266,6 +267,7 @@
>>>>>>>                       regulator-min-microvolt = <3300000>;
>>>>>>>                       regulator-max-microvolt = <3300000>;
>>>>>>>                       regulator-boot-on;
>>>>>>> +                    regulator-always-on;

This ldousb_reg 3.3V regulator can be turned off when the PHY is not in use. The PHY driver will manage this.

cheers,
-roger

>>>>>>>                   };
>>>>>>>               };
>>>>>>>           };
>>>>>>>
>>>>>>
>>>>>> Why not fix phy driver/framework as needed? the trouble is people
>>>>>> always forget to remove always-on... who actually audits old logs and
>>>>>> fixes stuff back up?
>>>>>
>>>>> Yes I agree let's not play with the regulator-always-on unless
>>>>> absolutely necessary.
>>>>>
>>>> Agreed. PHY framework must deal with this. Till then USB, SATA and most likely PCIe as well will not work on DRA7-evm.
>>>>
>>>
>>> I tried the below patch to enable the relevant regulators in the PHY drivers but still couldn't manage to get USB to work. The same 1.8V regulator is used to supply 3 pins
>>> -vdda_usb1: DPLL_USB and HS_USB1 analog supply
>>> -vdda_usb2: HS_USB2 analog supply
>>> -vdda_usb3: DPLL_USB_OTG_SS and USB3.0 Rx/Tx analog supply
>>>
>>> It seems that the regulator auto disable kicks in before the phy driver enables the regulator thus causing some kind of malfunction. I'm not sure whether this is due to DPLL_USB supply glitch or HS_USB1 analog supply glitch.
>>>
>>> In any case, the DPLL_USB (clock driver?) needs to enable the 1.8V regulator in addition to the HS_USB PHY driver to prevent this supply glitch.
>>>
>>> Tero, any suggestions about this? If we are not concerned about disabling DPLL_USB anytime then the regulator might just as well be always-on. Alternatively can we place a regulator_get(), regulator_enable() in drivers/clk/ti/dpll.c?
>>
>> I believe dpll_usb needs to go down for the core to idle. Also, we are working on getting suspend-resume working on this platform, so having the regulator always on is a no-no.
>>
>> Also, I am heavily against adding regulator tweaks within the clock driver, there needs to be another way.
> 
> Fair enough. There is not much information about controlling the power on vdda_usbx pins except the power-up and power-down sequence diagrams in Fig. 3.1 and 3.2 in the Data Manual (DRA75x_74x_ES1.1_DM_Early_Preliminary_vJ.pdf).
> 
> Can the regulator be dealt with in the OMAP PM core driver, along with the vdd_mpu and vdd_core stuff?
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/