[PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Adding phy calibrate callback, which facilitates setting certain PHY settings post initialization of the PHY controller. Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which the Loss-of-Signal (LOS) Detector Threshold Level as well as Tx-Vboost-Level should be controlled for Super-Speed operations. Additionally set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam --- drivers/phy/phy-exynos5-usbdrd.c | 185 ++ 1 file changed, 170 insertions(+), 15 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 47f47fe..85742b0 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK (0x3f << 1) #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27) #define EXYNOS5_DRD_PHYUTMI0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE0x0c #define EXYNOS5_DRD_PHYCLKRST 0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) #define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23) - #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) #define PHYCLKRST_SSC_RANGE(_x)((_x) << 21) - #define PHYCLKRST_SSC_EN BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2 BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x32 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d << 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) #define PHYCLKRST_FSEL(_x) ((_x) << 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) - #define PHYCLKRST_PORTRESETBIT(1) #define PHYCLKRST_COMMONONNBIT(0) #define EXYNOS5_DRD_PHYREG00x14 +#define PHYREG0_SSC_REF_CLK_SELBIT(21) +#define PHYREG0_SSC_RANGE BIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READBIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) +#define PHYREG0_CR_CAP_DATABIT(1) +#define PHYREG0_CR_CAP_ADDRBIT(0) + #define EXYNOS5_DRD_PHYREG10x18 +#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM0 0x1c - #define PHYPARAM0_REF_USE_PAD BIT(31) #define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26) #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) #define EXYNOS5_DRD_PHYPARAM1 0x20 - #define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0) #define PHYPARAM1_PCS_TXDEEMPH (0x1c) #define EXYNOS5_DRD_PHYTERM0x24 #define EXYNOS5_DRD_PHYTEST0x28 - #define PHYTEST_POWERDOWN_SSP BIT(3) #define PHYTEST_POWERDOWN_HSP BIT(2) #define EXYNOS5_DRD_PHYADP 0x2c #define EXYNOS5_DRD_PHYUTMICLKSEL 0x30 - #define PHYUTMICLKSEL_UTMI_CLKSEL
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi Felipe, On Tue, Sep 2, 2014 at 8:04 PM, Felipe Balbi wrote: > Hi, > > On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: >> Adding phy calibrate callback, which facilitates setting certain >> PHY settings post initialization of the PHY controller. >> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which >> the Loss-of-Signal (LOS) Detector Threshold Level as well as >> Tx-Vboost-Level should be controlled for Super-Speed operations. >> >> Additionally set proper time to wait for RxDetect measurement, >> for desired PHY reference clock, so as to solve issue with enumeration >> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive >> on the controller. >> We are using CR_port for this purpose to send required data >> to override the LOS values. >> >> On testing with USB 3.0 devices on USB 3.0 port present on >> SMDK5420, and peach-pit boards should see following message: >> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd >> >> and without this patch, should see below shown message: >> usb 1-1: new high-speed USB device number 2 using xhci-hcd >> >> [Also removed unnecessary extra lines in the register macro definitions] >> >> Signed-off-by: Vivek Gautam >> --- >> drivers/phy/phy-exynos5-usbdrd.c | 185 >> ++ >> 1 file changed, 170 insertions(+), 15 deletions(-) >> >> diff --git a/drivers/phy/phy-exynos5-usbdrd.c >> b/drivers/phy/phy-exynos5-usbdrd.c >> index 47f47fe..85742b0 100644 >> --- a/drivers/phy/phy-exynos5-usbdrd.c >> +++ b/drivers/phy/phy-exynos5-usbdrd.c >> @@ -37,13 +37,11 @@ >> >> /* EXYNOS5: USB 3.0 DRD PHY registers */ >> #define EXYNOS5_DRD_LINKSYSTEM 0x04 >> - >> #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) >> #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) >> #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) >> >> #define EXYNOS5_DRD_PHYUTMI 0x08 >> - >> #define PHYUTMI_OTGDISABLE BIT(6) >> #define PHYUTMI_FORCESUSPEND BIT(1) >> #define PHYUTMI_FORCESLEEP BIT(0) >> @@ -51,26 +49,20 @@ >> #define EXYNOS5_DRD_PHYPIPE 0x0c >> >> #define EXYNOS5_DRD_PHYCLKRST0x10 >> - >> #define PHYCLKRST_EN_UTMISUSPEND BIT(31) >> - >> #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) >> #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) >> - >> #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) >> #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) >> - >> #define PHYCLKRST_SSC_EN BIT(20) >> #define PHYCLKRST_REF_SSP_EN BIT(19) >> #define PHYCLKRST_REF_CLKDIV2BIT(18) >> - >> #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) >> #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) >> - >> #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) >> #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) >> #define PHYCLKRST_FSEL(_x) ((_x) << 5) >> @@ -78,46 +70,68 @@ >> #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) >> #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) >> #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) >> - >> #define PHYCLKRST_RETENABLEN BIT(4) >> - >> #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) >> #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) >> #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) >> - >> #define PHYCLKRST_PORTRESET BIT(1) >> #define PHYCLKRST_COMMONONN BIT(0) >> >> #define EXYNOS5_DRD_PHYREG0 0x14 >> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) >> +#define PHYREG0_SSC_RANGEBIT(20) >> +#define PHYREG0_CR_WRITE BIT(19) >> +#define PHYREG0_CR_READ BIT(18) >> +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) >> +#define PHYREG0_CR_CAP_DATA BIT(1) >> +#define PHYREG0_CR_CAP_ADDR BIT(0) >> + >> #define EXYNOS5_DRD_PHYREG1 0x18 >> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) >> +#define PHYREG1_CR_ACK BIT(0) >> >> #define EXYNOS5_DRD_PHYPARAM00x1c >> - >> #define PHYPARAM0_REF_USE_PADBIT(31) >> #define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26) >> #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) >> >> #define EXYNOS5_DRD_PHYPARAM10x20 >> - >> #define PHYPARAM1_PCS_TXDEEMPH_
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Wed, Sep 03, 2014 at 12:59:27PM +0530, Vivek Gautam wrote: > > On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: > >> Adding phy calibrate callback, which facilitates setting certain > >> PHY settings post initialization of the PHY controller. > >> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which > >> the Loss-of-Signal (LOS) Detector Threshold Level as well as > >> Tx-Vboost-Level should be controlled for Super-Speed operations. > >> > >> Additionally set proper time to wait for RxDetect measurement, > >> for desired PHY reference clock, so as to solve issue with enumeration > >> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive > >> on the controller. > >> We are using CR_port for this purpose to send required data > >> to override the LOS values. > >> > >> On testing with USB 3.0 devices on USB 3.0 port present on > >> SMDK5420, and peach-pit boards should see following message: > >> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd > >> > >> and without this patch, should see below shown message: > >> usb 1-1: new high-speed USB device number 2 using xhci-hcd > >> > >> [Also removed unnecessary extra lines in the register macro definitions] > >> > >> Signed-off-by: Vivek Gautam > >> --- > >> drivers/phy/phy-exynos5-usbdrd.c | 185 > >> ++ > >> 1 file changed, 170 insertions(+), 15 deletions(-) > >> > >> diff --git a/drivers/phy/phy-exynos5-usbdrd.c > >> b/drivers/phy/phy-exynos5-usbdrd.c > >> index 47f47fe..85742b0 100644 > >> --- a/drivers/phy/phy-exynos5-usbdrd.c > >> +++ b/drivers/phy/phy-exynos5-usbdrd.c > >> @@ -37,13 +37,11 @@ > >> > >> /* EXYNOS5: USB 3.0 DRD PHY registers */ > >> #define EXYNOS5_DRD_LINKSYSTEM 0x04 > >> - > >> #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) > >> #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) > >> #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) > >> > >> #define EXYNOS5_DRD_PHYUTMI 0x08 > >> - > >> #define PHYUTMI_OTGDISABLE BIT(6) > >> #define PHYUTMI_FORCESUSPEND BIT(1) > >> #define PHYUTMI_FORCESLEEP BIT(0) > >> @@ -51,26 +49,20 @@ > >> #define EXYNOS5_DRD_PHYPIPE 0x0c > >> > >> #define EXYNOS5_DRD_PHYCLKRST0x10 > >> - > >> #define PHYCLKRST_EN_UTMISUSPEND BIT(31) > >> - > >> #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) > >> #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) > >> - > >> #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) > >> #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) > >> - > >> #define PHYCLKRST_SSC_EN BIT(20) > >> #define PHYCLKRST_REF_SSP_EN BIT(19) > >> #define PHYCLKRST_REF_CLKDIV2BIT(18) > >> - > >> #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) > >> #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) > >> - > >> #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) > >> #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) > >> #define PHYCLKRST_FSEL(_x) ((_x) << 5) > >> @@ -78,46 +70,68 @@ > >> #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) > >> #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) > >> #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) > >> - > >> #define PHYCLKRST_RETENABLEN BIT(4) > >> - > >> #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) > >> #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) > >> #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) > >> - > >> #define PHYCLKRST_PORTRESET BIT(1) > >> #define PHYCLKRST_COMMONONN BIT(0) > >> > >> #define EXYNOS5_DRD_PHYREG0 0x14 > >> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) > >> +#define PHYREG0_SSC_RANGEBIT(20) > >> +#define PHYREG0_CR_WRITE BIT(19) > >> +#define PHYREG0_CR_READ BIT(18) > >> +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) > >> +#define PHYREG0_CR_CAP_DATA BIT(1) > >> +#define PHYREG0_CR_CAP_ADDR BIT(0) > >> + > >> #define EXYNOS5_DRD_PHYREG1 0x18 > >> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) > >> +#define PHYREG1_CR_ACK BIT(0) > >> > >> #define EXYNOS5_DRD_PHYPARAM00x1c > >> - > >> #define PHYPARAM0_REF_USE_PADBIT(31) > >> #define PHYPARAM0_REF_LOSLE
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Wed, Sep 3, 2014 at 8:12 PM, Felipe Balbi wrote: > Hi, > > On Wed, Sep 03, 2014 at 12:59:27PM +0530, Vivek Gautam wrote: >> > On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: >> >> Adding phy calibrate callback, which facilitates setting certain >> >> PHY settings post initialization of the PHY controller. >> >> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which >> >> the Loss-of-Signal (LOS) Detector Threshold Level as well as >> >> Tx-Vboost-Level should be controlled for Super-Speed operations. >> >> >> >> Additionally set proper time to wait for RxDetect measurement, >> >> for desired PHY reference clock, so as to solve issue with enumeration >> >> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive >> >> on the controller. >> >> We are using CR_port for this purpose to send required data >> >> to override the LOS values. >> >> >> >> On testing with USB 3.0 devices on USB 3.0 port present on >> >> SMDK5420, and peach-pit boards should see following message: >> >> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd >> >> >> >> and without this patch, should see below shown message: >> >> usb 1-1: new high-speed USB device number 2 using xhci-hcd >> >> >> >> [Also removed unnecessary extra lines in the register macro definitions] >> >> >> >> Signed-off-by: Vivek Gautam >> >> --- >> >> drivers/phy/phy-exynos5-usbdrd.c | 185 >> >> ++ >> >> 1 file changed, 170 insertions(+), 15 deletions(-) >> >> >> >> diff --git a/drivers/phy/phy-exynos5-usbdrd.c >> >> b/drivers/phy/phy-exynos5-usbdrd.c >> >> index 47f47fe..85742b0 100644 >> >> --- a/drivers/phy/phy-exynos5-usbdrd.c >> >> +++ b/drivers/phy/phy-exynos5-usbdrd.c >> >> @@ -37,13 +37,11 @@ >> >> >> >> /* EXYNOS5: USB 3.0 DRD PHY registers */ >> >> #define EXYNOS5_DRD_LINKSYSTEM 0x04 >> >> - >> >> #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) >> >> #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) >> >> #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) >> >> >> >> #define EXYNOS5_DRD_PHYUTMI 0x08 >> >> - >> >> #define PHYUTMI_OTGDISABLE BIT(6) >> >> #define PHYUTMI_FORCESUSPEND BIT(1) >> >> #define PHYUTMI_FORCESLEEP BIT(0) >> >> @@ -51,26 +49,20 @@ >> >> #define EXYNOS5_DRD_PHYPIPE 0x0c >> >> >> >> #define EXYNOS5_DRD_PHYCLKRST0x10 >> >> - >> >> #define PHYCLKRST_EN_UTMISUSPEND BIT(31) >> >> - >> >> #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) >> >> #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) >> >> - >> >> #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) >> >> #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) >> >> - >> >> #define PHYCLKRST_SSC_EN BIT(20) >> >> #define PHYCLKRST_REF_SSP_EN BIT(19) >> >> #define PHYCLKRST_REF_CLKDIV2BIT(18) >> >> - >> >> #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) >> >> #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) >> >> - >> >> #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) >> >> #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) >> >> #define PHYCLKRST_FSEL(_x) ((_x) << 5) >> >> @@ -78,46 +70,68 @@ >> >> #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) >> >> #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) >> >> #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) >> >> - >> >> #define PHYCLKRST_RETENABLEN BIT(4) >> >> - >> >> #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) >> >> #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) >> >> #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) >> >> - >> >> #define PHYCLKRST_PORTRESET BIT(1) >> >> #define PHYCLKRST_COMMONONN BIT(0) >> >> >> >> #define EXYNOS5_DRD_PHYREG0 0x14 >> >> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) >> >> +#define PHYREG0_SSC_RANGEBIT(20) >> >> +#define PHYREG0_CR_WRITE BIT(19) >> >> +#define PHYREG0_CR_READ BIT(18) >> >> +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) >> >> +#define PHYREG0_CR_CAP_DATA BIT(1) >> >> +#define PHYREG0_CR_CAP_ADDR BIT(0) >> >> + >> >> #define EXYNOS5_DRD_PHYREG1 0x18 >> >> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) >> >> +#define PHYREG1_CR_ACK BIT(0) >> >> >> >> #def
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: > > Don't we have phy_power_on() > > for that ? It looks like you could just as well do this from > > phy_power_on() ? > > No, unfortunately keeping these calibration settings in phy_power_on() > doesn't help, since we need to do this after XHCI reset has happened. teach xHCI about PHYs ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote: > Adding phy calibrate callback, which facilitates setting certain > PHY settings post initialization of the PHY controller. > Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which > the Loss-of-Signal (LOS) Detector Threshold Level as well as > Tx-Vboost-Level should be controlled for Super-Speed operations. > > Additionally set proper time to wait for RxDetect measurement, > for desired PHY reference clock, so as to solve issue with enumeration > of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive > on the controller. > We are using CR_port for this purpose to send required data > to override the LOS values. > > On testing with USB 3.0 devices on USB 3.0 port present on > SMDK5420, and peach-pit boards should see following message: > usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd > > and without this patch, should see below shown message: > usb 1-1: new high-speed USB device number 2 using xhci-hcd > > [Also removed unnecessary extra lines in the register macro definitions] > > Signed-off-by: Vivek Gautam > --- > drivers/phy/phy-exynos5-usbdrd.c | 185 > ++ > 1 file changed, 170 insertions(+), 15 deletions(-) > > diff --git a/drivers/phy/phy-exynos5-usbdrd.c > b/drivers/phy/phy-exynos5-usbdrd.c > index 47f47fe..85742b0 100644 > --- a/drivers/phy/phy-exynos5-usbdrd.c > +++ b/drivers/phy/phy-exynos5-usbdrd.c > @@ -37,13 +37,11 @@ > > /* EXYNOS5: USB 3.0 DRD PHY registers */ > #define EXYNOS5_DRD_LINKSYSTEM 0x04 > - > #define LINKSYSTEM_FLADJ_MASK(0x3f << 1) > #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) > #define LINKSYSTEM_XHCI_VERSION_CONTROL BIT(27) > > #define EXYNOS5_DRD_PHYUTMI 0x08 > - > #define PHYUTMI_OTGDISABLE BIT(6) > #define PHYUTMI_FORCESUSPEND BIT(1) > #define PHYUTMI_FORCESLEEP BIT(0) > @@ -51,26 +49,20 @@ > #define EXYNOS5_DRD_PHYPIPE 0x0c > > #define EXYNOS5_DRD_PHYCLKRST0x10 > - > #define PHYCLKRST_EN_UTMISUSPEND BIT(31) > - > #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) > #define PHYCLKRST_SSC_REFCLKSEL(_x) ((_x) << 23) > - > #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) > #define PHYCLKRST_SSC_RANGE(_x) ((_x) << 21) > - > #define PHYCLKRST_SSC_EN BIT(20) > #define PHYCLKRST_REF_SSP_EN BIT(19) > #define PHYCLKRST_REF_CLKDIV2BIT(18) > - > #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF (0x68 << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF (0x7d << 11) > #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) > - > #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) > #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) > #define PHYCLKRST_FSEL(_x) ((_x) << 5) > @@ -78,46 +70,68 @@ > #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) > #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) > #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) > - > #define PHYCLKRST_RETENABLEN BIT(4) > - > #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) > #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) > #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) > - > #define PHYCLKRST_PORTRESET BIT(1) > #define PHYCLKRST_COMMONONN BIT(0) > > #define EXYNOS5_DRD_PHYREG0 0x14 > +#define PHYREG0_SSC_REF_CLK_SEL BIT(21) > +#define PHYREG0_SSC_RANGEBIT(20) > +#define PHYREG0_CR_WRITE BIT(19) > +#define PHYREG0_CR_READ BIT(18) > +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) > +#define PHYREG0_CR_CAP_DATA BIT(1) > +#define PHYREG0_CR_CAP_ADDR BIT(0) > + > #define EXYNOS5_DRD_PHYREG1 0x18 > +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1) > +#define PHYREG1_CR_ACK BIT(0) > > #define EXYNOS5_DRD_PHYPARAM00x1c > - > #define PHYPARAM0_REF_USE_PADBIT(31) > #define PHYPARAM0_REF_LOSLEVEL_MASK (0x1f << 26) > #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) > > #define EXYNOS5_DRD_PHYPARAM10x20 > - > #define PHYPARAM1_PCS_TXDEEMPH_MASK (0x1f << 0) > #define PHYPARAM1_PCS_TXDEEMPH (0x1c) > > #define EXYNOS5_DRD_PHYTERM 0x24 > > #define EX
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
>> right, use that to call phy_init() at the right time, then you need to >> add a new ->calibrate() method which, likely, will only be used by you >> ;-) > so you mean, the xhci should itself call phy_init() at a time suitable, > so that ->calibrate() is not required at all ? I'm not sure if that's a good idea because it would require phy_init() and calibrate() to always mean the same thing. The calibrate() for Exynos5420 needs to be called both during boot and after system resume, but there might be other platforms that don't want to completely shutdown and reinit their PHYs during suspend/resume with the same functions used for boot. For example, Tegra5 (proposed driver at http://www.spinics.net/lists/linux-usb/msg113093.html) can power-gate the PHY during suspend, but that's not running the same code as in the phy_init()/phy_shutdown() methods (the posted patch doesn't contain all power-gating code yet, but you can get an idea about how it has to work from https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.10/drivers/usb/host/xhci-tegra.c). It would also mean that the initial phy_init() call must always come after the XHCI reset, and I am not sure if that would fit nicely with all platforms. > right, and what's more generic than adding the support for PHYs straight into > xHCI ? Well, if we are going to have a calibrate() method (as in "stuff the PHY does after every controller reset if it needs to"), we have to add it either to the XHCI stack or the USB core. I thought the USB core would be more generic, because in theory it's possible that e.g. an EHCI controller might have a similar requirement. (Also, we have the gen_phy pointer in a USB core structure (struct usb_hcd), so I thought making this feature generic to the USB core and thus available to all kinds of host controllers would be more natural.) -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Thursday, September 11, 2014 1:52 AM, "Julius Werner" wrote right, use that to call phy_init() at the right time, then you need to add a new ->calibrate() method which, likely, will only be used by you ;-) so you mean, the xhci should itself call phy_init() at a time suitable, so that ->calibrate() is not required at all ? I'm not sure if that's a good idea because it would require phy_init() and calibrate() to always mean the same thing. The calibrate() for Exynos5420 needs to be called both during boot and after system resume, but there might be other platforms that don't want to completely shutdown and reinit their PHYs during suspend/resume with the same functions used for boot. For example, Tegra5 (proposed driver at http://www.spinics.net/lists/linux-usb/msg113093.html) can power-gate the PHY during suspend, but that's not running the same code as in the phy_init()/phy_shutdown() methods (the posted patch doesn't contain all power-gating code yet, but you can get an idea about how it has to work from https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.10/drivers/usb/host/xhci-tegra.c). It would also mean that the initial phy_init() call must always come after the XHCI reset, and I am not sure if that would fit nicely with all platforms. right, and what's more generic than adding the support for PHYs straight into xHCI ? Well, if we are going to have a calibrate() method (as in "stuff the PHY does after every controller reset if it needs to"), we have to add it either to the XHCI stack or the USB core. I thought the USB core would be more generic, because in theory it's possible that e.g. an EHCI controller might have a similar requirement. Atleast on Exynos systems I can see that unless PHY is initialized the controller fails to reset. So taking a path wherein we initialize the PHYs after controller resets is not going to help us generically across all controllers. With XHCI though things are OK while resetting, and we can initialize the PHYs after controller reset happens but here too DWC3 is already initializing the PHYs for exynos systems too, so it may not be very wise to do that initialization stuff once again. Plus the PHY core prevents multiple initialization anyways. (Also, we have the gen_phy pointer in a USB core structure (struct usb_hcd), so I thought making this feature generic to the USB core and thus available to all kinds of host controllers would be more natural.) -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Wednesday 10 September 2014 01:26 PM, Vivek Gautam wrote: > On Wed, Sep 10, 2014 at 10:53 AM, Vivek Gautam > wrote: >> On Wed, Sep 10, 2014 at 10:23 AM, Felipe Balbi wrote: >>> On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote: On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam wrote: > adding Julius here, i think i had missed adding Julius for this entire series :-( I should be more careful with the CC list in future. Added his chromium id, since that seems to be more active. > > > On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi wrote: >> On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: >>> Hi, >>> >>> >>> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: Hi, On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: > On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: >> On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: Don't we have phy_power_on() for that ? It looks like you could just as well do this from phy_power_on() ? >>> >>> No, unfortunately keeping these calibration settings in >>> phy_power_on() >>> doesn't help, since we need to do this after XHCI reset has >>> happened. >> >> teach xHCI about PHYs ? > > sorry i couldn't understand you here. > Aren't we trying to do the same with Heikki's patch about dwc3 : > [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci > > and the 2nd patch in this series : > [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds > > Is there something else that is expected ? right, use that to call phy_init() at the right time, then you need to add a new ->calibrate() method which, likely, will only be used by you ;-) >>> >>> so you mean, the xhci should itself call phy_init() at a time suitable, >>> so that ->calibrate() is not required at all ? > > but wait, dwc3 does a phy_init() already, then how xhci will be able to > do that again. We can't do phy_init() multiple times right ? right. I think we should split and do phy ops separately for dwc3 host and gadget? Thanks Kishon -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Thu, Sep 11, 2014 at 09:10:21PM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Wednesday 10 September 2014 01:26 PM, Vivek Gautam wrote: > > On Wed, Sep 10, 2014 at 10:53 AM, Vivek Gautam > > wrote: > >> On Wed, Sep 10, 2014 at 10:23 AM, Felipe Balbi wrote: > >>> On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote: > On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam > wrote: > > adding Julius here, > > i think i had missed adding Julius for this entire series :-( > I should be more careful with the CC list in future. > Added his chromium id, since that seems to be more active. > > > > > > > On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi wrote: > >> On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: > >>> Hi, > >>> > >>> > >>> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: > Hi, > > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: > > On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: > >> On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: > Don't we have phy_power_on() > for that ? It looks like you could just as well do this from > phy_power_on() ? > >>> > >>> No, unfortunately keeping these calibration settings in > >>> phy_power_on() > >>> doesn't help, since we need to do this after XHCI reset has > >>> happened. > >> > >> teach xHCI about PHYs ? > > > > sorry i couldn't understand you here. > > Aren't we trying to do the same with Heikki's patch about dwc3 : > > [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci > > > > and the 2nd patch in this series : > > [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds > > > > Is there something else that is expected ? > > right, use that to call phy_init() at the right time, then you need > to > add a new ->calibrate() method which, likely, will only be used by > you > ;-) > >>> > >>> so you mean, the xhci should itself call phy_init() at a time > >>> suitable, > >>> so that ->calibrate() is not required at all ? > > > > but wait, dwc3 does a phy_init() already, then how xhci will be able to > > do that again. We can't do phy_init() multiple times right ? > > right. I think we should split and do phy ops separately for dwc3 host > and gadget? no, don't do that. We need a better way of handling this. As of now we don't support dual-role, so we can just reinitialize the PHY once we reach xhci. Once we start supporting dual-role, we will need more inteligence in the algorithm. -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >> > Don't we have phy_power_on() >> > for that ? It looks like you could just as well do this from >> > phy_power_on() ? >> >> No, unfortunately keeping these calibration settings in phy_power_on() >> doesn't help, since we need to do this after XHCI reset has happened. > > teach xHCI about PHYs ? sorry i couldn't understand you here. Aren't we trying to do the same with Heikki's patch about dwc3 : [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci and the 2nd patch in this series : [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds Is there something else that is expected ? -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: > On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: > > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: > >> > Don't we have phy_power_on() > >> > for that ? It looks like you could just as well do this from > >> > phy_power_on() ? > >> > >> No, unfortunately keeping these calibration settings in phy_power_on() > >> doesn't help, since we need to do this after XHCI reset has happened. > > > > teach xHCI about PHYs ? > > sorry i couldn't understand you here. > Aren't we trying to do the same with Heikki's patch about dwc3 : > [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci > > and the 2nd patch in this series : > [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds > > Is there something else that is expected ? right, use that to call phy_init() at the right time, then you need to add a new ->calibrate() method which, likely, will only be used by you ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Hi, On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: > Hi, > > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >> >> > Don't we have phy_power_on() >> >> > for that ? It looks like you could just as well do this from >> >> > phy_power_on() ? >> >> >> >> No, unfortunately keeping these calibration settings in phy_power_on() >> >> doesn't help, since we need to do this after XHCI reset has happened. >> > >> > teach xHCI about PHYs ? >> >> sorry i couldn't understand you here. >> Aren't we trying to do the same with Heikki's patch about dwc3 : >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci >> >> and the 2nd patch in this series : >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds >> >> Is there something else that is expected ? > > right, use that to call phy_init() at the right time, then you need to > add a new ->calibrate() method which, likely, will only be used by you > ;-) so you mean, the xhci should itself call phy_init() at a time suitable, so that ->calibrate() is not required at all ? i think you meant there - "then you __do not__ need to > add a new ->calibrate() method which, likely, will only be used by you", is it ? -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: > Hi, > > > On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: > >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: > >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: > >> >> > Don't we have phy_power_on() > >> >> > for that ? It looks like you could just as well do this from > >> >> > phy_power_on() ? > >> >> > >> >> No, unfortunately keeping these calibration settings in phy_power_on() > >> >> doesn't help, since we need to do this after XHCI reset has happened. > >> > > >> > teach xHCI about PHYs ? > >> > >> sorry i couldn't understand you here. > >> Aren't we trying to do the same with Heikki's patch about dwc3 : > >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci > >> > >> and the 2nd patch in this series : > >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds > >> > >> Is there something else that is expected ? > > > > right, use that to call phy_init() at the right time, then you need to > > add a new ->calibrate() method which, likely, will only be used by you > > ;-) > > so you mean, the xhci should itself call phy_init() at a time suitable, > so that ->calibrate() is not required at all ? > > i think you meant there - "then you __do not__ need to right :-) > > add a new ->calibrate() method which, likely, > will only be used by you", is it ? yup -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
adding Julius here, On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi wrote: > On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: >> Hi, >> >> >> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: >> > Hi, >> > >> > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: >> >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: >> >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >> >> >> > Don't we have phy_power_on() >> >> >> > for that ? It looks like you could just as well do this from >> >> >> > phy_power_on() ? >> >> >> >> >> >> No, unfortunately keeping these calibration settings in phy_power_on() >> >> >> doesn't help, since we need to do this after XHCI reset has happened. >> >> > >> >> > teach xHCI about PHYs ? >> >> >> >> sorry i couldn't understand you here. >> >> Aren't we trying to do the same with Heikki's patch about dwc3 : >> >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci >> >> >> >> and the 2nd patch in this series : >> >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds >> >> >> >> Is there something else that is expected ? >> > >> > right, use that to call phy_init() at the right time, then you need to >> > add a new ->calibrate() method which, likely, will only be used by you >> > ;-) >> >> so you mean, the xhci should itself call phy_init() at a time suitable, >> so that ->calibrate() is not required at all ? >> >> i think you meant there - "then you __do not__ need to > > right :-) alright, i will prepare a patch for the suggested change. But AFAI remember we had discussion for this patch in earlier version, and Julius suggested to use a generic approach for such change wherein other users in future may be able to use the facility. Julius any thoughts about the change suggested by Felipe. [snip] -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam wrote: > adding Julius here, i think i had missed adding Julius for this entire series :-( I should be more careful with the CC list in future. Added his chromium id, since that seems to be more active. > > > On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi wrote: >> On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: >>> Hi, >>> >>> >>> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: >>> > Hi, >>> > >>> > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: >>> >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: >>> >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >>> >> >> > Don't we have phy_power_on() >>> >> >> > for that ? It looks like you could just as well do this from >>> >> >> > phy_power_on() ? >>> >> >> >>> >> >> No, unfortunately keeping these calibration settings in phy_power_on() >>> >> >> doesn't help, since we need to do this after XHCI reset has happened. >>> >> > >>> >> > teach xHCI about PHYs ? >>> >> >>> >> sorry i couldn't understand you here. >>> >> Aren't we trying to do the same with Heikki's patch about dwc3 : >>> >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci >>> >> >>> >> and the 2nd patch in this series : >>> >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds >>> >> >>> >> Is there something else that is expected ? >>> > >>> > right, use that to call phy_init() at the right time, then you need to >>> > add a new ->calibrate() method which, likely, will only be used by you >>> > ;-) >>> >>> so you mean, the xhci should itself call phy_init() at a time suitable, >>> so that ->calibrate() is not required at all ? >>> >>> i think you meant there - "then you __do not__ need to >> >> right :-) > > alright, i will prepare a patch for the suggested change. > > But AFAI remember we had discussion for this patch in earlier version, > and Julius suggested to use a generic approach for such > change wherein other users in future may be able to use the > facility. > Julius any thoughts about the change suggested by Felipe. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote: > On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam > wrote: > > adding Julius here, > > i think i had missed adding Julius for this entire series :-( > I should be more careful with the CC list in future. > Added his chromium id, since that seems to be more active. > > > > > > > On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi wrote: > >> On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: > >>> Hi, > >>> > >>> > >>> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: > >>> > Hi, > >>> > > >>> > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: > >>> >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: > >>> >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: > >>> >> >> > Don't we have phy_power_on() > >>> >> >> > for that ? It looks like you could just as well do this from > >>> >> >> > phy_power_on() ? > >>> >> >> > >>> >> >> No, unfortunately keeping these calibration settings in > >>> >> >> phy_power_on() > >>> >> >> doesn't help, since we need to do this after XHCI reset has > >>> >> >> happened. > >>> >> > > >>> >> > teach xHCI about PHYs ? > >>> >> > >>> >> sorry i couldn't understand you here. > >>> >> Aren't we trying to do the same with Heikki's patch about dwc3 : > >>> >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci > >>> >> > >>> >> and the 2nd patch in this series : > >>> >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds > >>> >> > >>> >> Is there something else that is expected ? > >>> > > >>> > right, use that to call phy_init() at the right time, then you need to > >>> > add a new ->calibrate() method which, likely, will only be used by you > >>> > ;-) > >>> > >>> so you mean, the xhci should itself call phy_init() at a time suitable, > >>> so that ->calibrate() is not required at all ? > >>> > >>> i think you meant there - "then you __do not__ need to > >> > >> right :-) > > > > alright, i will prepare a patch for the suggested change. > > > > But AFAI remember we had discussion for this patch in earlier > > version, and Julius suggested to use a generic approach for such > > change wherein other users in future may be able to use the > > facility. right, and what's more generic than adding the support for PHYs straight into xHCI ? What I fear is that we end up opening the doors for every odd platform-specific operation to be added to the framework without really considering what needs to be done. That would defeat the idea of having a generic framework altogether. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Wed, Sep 10, 2014 at 10:23 AM, Felipe Balbi wrote: > On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote: >> On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam >> wrote: >> > adding Julius here, >> >> i think i had missed adding Julius for this entire series :-( >> I should be more careful with the CC list in future. >> Added his chromium id, since that seems to be more active. >> >> > >> > >> > On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi wrote: >> >> On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: >> >>> Hi, >> >>> >> >>> >> >>> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: >> >>> > Hi, >> >>> > >> >>> > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: >> >>> >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: >> >>> >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >> >>> >> >> > Don't we have phy_power_on() >> >>> >> >> > for that ? It looks like you could just as well do this from >> >>> >> >> > phy_power_on() ? >> >>> >> >> >> >>> >> >> No, unfortunately keeping these calibration settings in >> >>> >> >> phy_power_on() >> >>> >> >> doesn't help, since we need to do this after XHCI reset has >> >>> >> >> happened. >> >>> >> > >> >>> >> > teach xHCI about PHYs ? >> >>> >> >> >>> >> sorry i couldn't understand you here. >> >>> >> Aren't we trying to do the same with Heikki's patch about dwc3 : >> >>> >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci >> >>> >> >> >>> >> and the 2nd patch in this series : >> >>> >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds >> >>> >> >> >>> >> Is there something else that is expected ? >> >>> > >> >>> > right, use that to call phy_init() at the right time, then you need to >> >>> > add a new ->calibrate() method which, likely, will only be used by you >> >>> > ;-) >> >>> >> >>> so you mean, the xhci should itself call phy_init() at a time suitable, >> >>> so that ->calibrate() is not required at all ? >> >>> >> >>> i think you meant there - "then you __do not__ need to >> >> >> >> right :-) >> > >> > alright, i will prepare a patch for the suggested change. >> > >> > But AFAI remember we had discussion for this patch in earlier >> > version, and Julius suggested to use a generic approach for such >> > change wherein other users in future may be able to use the >> > facility. > > right, and what's more generic than adding the support for PHYs straight > into xHCI ? > > What I fear is that we end up opening the doors for every odd > platform-specific operation to be added to the framework without really > considering what needs to be done. That would defeat the idea of having > a generic framework altogether. Ok, i will prepare the patch series as suggested and post it to gather opinion from you. :-) > > cheers > > -- > balbi -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Wed, Sep 10, 2014 at 10:53 AM, Vivek Gautam wrote: > On Wed, Sep 10, 2014 at 10:23 AM, Felipe Balbi wrote: >> On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote: >>> On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam >>> wrote: >>> > adding Julius here, >>> >>> i think i had missed adding Julius for this entire series :-( >>> I should be more careful with the CC list in future. >>> Added his chromium id, since that seems to be more active. >>> >>> > >>> > >>> > On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi wrote: >>> >> On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: >>> >>> Hi, >>> >>> >>> >>> >>> >>> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi wrote: >>> >>> > Hi, >>> >>> > >>> >>> > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: >>> >>> >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: >>> >>> >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >>> >>> >> >> > Don't we have phy_power_on() >>> >>> >> >> > for that ? It looks like you could just as well do this from >>> >>> >> >> > phy_power_on() ? >>> >>> >> >> >>> >>> >> >> No, unfortunately keeping these calibration settings in >>> >>> >> >> phy_power_on() >>> >>> >> >> doesn't help, since we need to do this after XHCI reset has >>> >>> >> >> happened. >>> >>> >> > >>> >>> >> > teach xHCI about PHYs ? >>> >>> >> >>> >>> >> sorry i couldn't understand you here. >>> >>> >> Aren't we trying to do the same with Heikki's patch about dwc3 : >>> >>> >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci >>> >>> >> >>> >>> >> and the 2nd patch in this series : >>> >>> >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds >>> >>> >> >>> >>> >> Is there something else that is expected ? >>> >>> > >>> >>> > right, use that to call phy_init() at the right time, then you need to >>> >>> > add a new ->calibrate() method which, likely, will only be used by you >>> >>> > ;-) >>> >>> >>> >>> so you mean, the xhci should itself call phy_init() at a time suitable, >>> >>> so that ->calibrate() is not required at all ? but wait, dwc3 does a phy_init() already, then how xhci will be able to do that again. We can't do phy_init() multiple times right ? >>> >>> >>> >>> i think you meant there - "then you __do not__ need to >>> >> >>> >> right :-) >>> > >>> > alright, i will prepare a patch for the suggested change. >>> > >>> > But AFAI remember we had discussion for this patch in earlier >>> > version, and Julius suggested to use a generic approach for such >>> > change wherein other users in future may be able to use the >>> > facility. >> >> right, and what's more generic than adding the support for PHYs straight >> into xHCI ? >> >> What I fear is that we end up opening the doors for every odd >> platform-specific operation to be added to the framework without really >> considering what needs to be done. That would defeat the idea of having >> a generic framework altogether. > > Ok, i will prepare the patch series as suggested and post it > to gather opinion from you. :-) > >> >> cheers >> >> -- >> balbi > > > > -- > Best Regards > Vivek Gautam > Samsung R&D Institute, Bangalore > India -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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/
