GTSYS -
Unit A01, 24/F Gold King Industrial Building,
35-41 Tai Lin Pai Road, Kwai Chung,
Hong Kong
新界葵涌大連排道35-41號金基工業大廈24樓A01室
On Thursday, April 24, 2014 01:07 PM, Peter Chen wrote:
This patch can cover both ULPI DT support version in future and
current version (can fix sasche's problem),
On Fri, Apr 25, 2014 at 02:07:35AM +, Peter Chen wrote:
>
> >
> > On Wed, Apr 23, 2014 at 01:30:43PM +0800, Peter Chen wrote:
> > > For internal PHY (like UTMI), the phy clock may from internal pll, it
> > > is on/off on the fly, the access PORTSC.PTS will hang without phy
> > > clock. So, t
>
> On Wed, Apr 23, 2014 at 01:30:43PM +0800, Peter Chen wrote:
> > For internal PHY (like UTMI), the phy clock may from internal pll, it
> > is on/off on the fly, the access PORTSC.PTS will hang without phy
> > clock. So, the usb_phy_init which will open phy clock needs to be
> > called before
On Wed, Apr 23, 2014 at 01:30:43PM +0800, Peter Chen wrote:
> For internal PHY (like UTMI), the phy clock may from internal pll,
> it is on/off on the fly, the access PORTSC.PTS will hang without
> phy clock. So, the usb_phy_init which will open phy clock needs to
> be called before hw_phymode_conf
> >
> >> This patch can cover both ULPI DT support version in future and
> >> current version (can fix sasche's problem), in order to add something
> >> again in future, I choose to use a new patch.
> > Will be there a ULPI DT driver version? Isn't it what generic phy nop
> > driver already does?
On Thursday, April 24, 2014 10:14 AM, Fabio Estevam wrote:
On Wed, Apr 23, 2014 at 10:58 PM, Peter Chen wrote:
This patch can cover both ULPI DT support version in future and current version
(can fix sasche's problem), in order to add something again in future, I choose
to use a new patch.
Wi
On Wed, Apr 23, 2014 at 10:58 PM, Peter Chen wrote:
> This patch can cover both ULPI DT support version in future and current
> version
> (can fix sasche's problem), in order to add something again in future, I
> choose
> to use a new patch.
Will be there a ULPI DT driver version? Isn't it wha
>
> On Wed, Apr 23, 2014 at 9:15 PM, Peter Chen
> wrote:
> > For internal PHY (like UTMI), the phy clock may from internal pll, it
> > is on/off on the fly, the access PORTSC.PTS will hang without phy
> > clock. So, the usb_phy_init which will open phy clock needs to be
> > called before hw_phy
On Wed, Apr 23, 2014 at 9:15 PM, Peter Chen wrote:
> For internal PHY (like UTMI), the phy clock may from internal pll,
> it is on/off on the fly, the access PORTSC.PTS will hang without
> phy clock. So, the usb_phy_init which will open phy clock needs to
> be called before hw_phymode_configure.
>
For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w
For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w
For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w
12 matches
Mail list logo
