Hi,
On Mon, Oct 26, 2015 at 4:49 PM, Doug Anderson wrote:
> One note: the "full" PHY reset is actually not in the register map of
> the PHY. It is amazingly enough in the CRU (clock reset unit). So if
> we actually exposed the "full" reset through the PHY framework, the
> PHY would then turn
Rob,
On Mon, Oct 26, 2015 at 4:05 PM, Rob Herring wrote:
>>> A DT reset controller seems like a bit of an overkill here. I think this
>>> would be much more simple if we just add a phy reset hook to the phy
>>> subsystem.
>>
>> Adding a reset hook in the PHY subsystem does seem like a reasonable
On Sat, Oct 24, 2015 at 4:22 PM, Doug Anderson wrote:
> Rob,
>
> On Sat, Oct 24, 2015 at 11:10 AM, Rob Herring wrote:
>> On 10/23/2015 01:28 PM, Douglas Anderson wrote:
>>> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
>>> has a hardware errata that causes everything to
On Sat, Oct 24, 2015 at 4:22 PM, Doug Anderson wrote:
> Rob,
>
> On Sat, Oct 24, 2015 at 11:10 AM, Rob Herring wrote:
>> On 10/23/2015 01:28 PM, Douglas Anderson wrote:
>>> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
>>> has a
Rob,
On Mon, Oct 26, 2015 at 4:05 PM, Rob Herring wrote:
>>> A DT reset controller seems like a bit of an overkill here. I think this
>>> would be much more simple if we just add a phy reset hook to the phy
>>> subsystem.
>>
>> Adding a reset hook in the PHY subsystem does seem
Hi,
On Mon, Oct 26, 2015 at 4:49 PM, Doug Anderson wrote:
> One note: the "full" PHY reset is actually not in the register map of
> the PHY. It is amazingly enough in the CRU (clock reset unit). So if
> we actually exposed the "full" reset through the PHY framework, the
Rob,
On Sat, Oct 24, 2015 at 11:10 AM, Rob Herring wrote:
> On 10/23/2015 01:28 PM, Douglas Anderson wrote:
>> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
>> has a hardware errata that causes everything to get confused when we get
>> a remote wakeup. It appears that
On 10/23/2015 01:28 PM, Douglas Anderson wrote:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup. It appears that the "port reset" bit that's in the USB
> phy (located in the
Am Freitag, 23. Oktober 2015, 11:28:07 schrieb Douglas Anderson:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup. It appears that the "port reset" bit that's in the USB
> phy
On 10/23/2015 01:28 PM, Douglas Anderson wrote:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup. It appears that the "port reset" bit that's in the USB
> phy (located in the
Rob,
On Sat, Oct 24, 2015 at 11:10 AM, Rob Herring wrote:
> On 10/23/2015 01:28 PM, Douglas Anderson wrote:
>> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
>> has a hardware errata that causes everything to get confused when we get
>> a remote wakeup.
Am Freitag, 23. Oktober 2015, 11:28:07 schrieb Douglas Anderson:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup. It appears that the "port reset" bit that's in the USB
> phy
The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup. It appears that the "port reset" bit that's in the USB
phy (located in the rk3288 GRF) fixes things up and appears safe to do.
This
The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup. It appears that the "port reset" bit that's in the USB
phy (located in the rk3288 GRF) fixes things up and appears safe to do.
This
14 matches
Mail list logo