I've tried to get the 3503 driver to work in my case for quite some
time, but ultimately gave up. For me, playing around with the load
order was not enough to solve all issues. When you try to build a
permanent, clean solution for this, you should definitely also test
the case where the hub has alr
On 28 August 2013 00:14, Felipe Balbi wrote:
> On Tue, Aug 13, 2013 at 02:11:27PM +0530, Tushar Behera wrote:
>> On 12 July 2013 12:27, Felipe Balbi wrote:
>> > Hi,
>> >
>> > On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote:
>> >> Hi Felipe,
>> >>
>> >> This is intended to pull down
On Tue, Aug 13, 2013 at 02:11:27PM +0530, Tushar Behera wrote:
> On 12 July 2013 12:27, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote:
> >> Hi Felipe,
> >>
> >> This is intended to pull down a reset signal line, not to switch power
> >> to the de
On 12 July 2013 12:27, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote:
>> Hi Felipe,
>>
>> This is intended to pull down a reset signal line, not to switch power
>> to the device. I could implement that with the regulator framework
>> too, but I think t
Hi,
On Friday 12 of July 2013 09:48:54 Jingoo Han wrote:
> On Friday, July 12, 2013 6:46 AM, Julius Werner wrote:
> > Hi Jingoo,
> >
> > Yeah, I followed that discussion back then, but it seems to have
> > stalled a little (at least the HSIC patches haven't been picked up in
> > any kernel.org re
Hi,
On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote:
> Hi Felipe,
>
> This is intended to pull down a reset signal line, not to switch power
> to the device. I could implement that with the regulator framework
> too, but I think that would just be confusing and harder to understand
On Friday, July 12, 2013 6:46 AM, Julius Werner wrote:
>
> Hi Jingoo,
>
> Yeah, I followed that discussion back then, but it seems to have
> stalled a little (at least the HSIC patches haven't been picked up in
> any kernel.org repo yet to my knowledge).
>
> The problem is that I think these app
Hi Jingoo,
Yeah, I followed that discussion back then, but it seems to have
stalled a little (at least the HSIC patches haven't been picked up in
any kernel.org repo yet to my knowledge).
The problem is that I think these approaches cannot work reliably. I
agree that it would be nice to control t
Hi Julius,
On Wed, Jul 10, 2013 at 2:42 PM, Julius Werner wrote:
> Hi Felipe,
>
> This is intended to pull down a reset signal line, not to switch power
> to the device. I could implement that with the regulator framework
> too, but I think that would just be confusing and harder to understand
>
On Wednesday, July 10, 2013 9:34 AM, Julius Werner wrote:
>
> This patch adds support for a new 'samsung,hsic-reset-gpio' in the
> device tree, which will be interpreted as an active-low reset pin during
> PHY initialization when it exists. Useful for intergrated HSIC devices
> like an SMSC 3503 h
Hi Felipe,
This is intended to pull down a reset signal line, not to switch power
to the device. I could implement that with the regulator framework
too, but I think that would just be confusing and harder to understand
without providing any benefit. It's really just a plain old GPIO.
--
To unsubs
On Tue, Jul 09, 2013 at 05:34:15PM -0700, Julius Werner wrote:
> This patch adds support for a new 'samsung,hsic-reset-gpio' in the
> device tree, which will be interpreted as an active-low reset pin during
> PHY initialization when it exists. Useful for intergrated HSIC devices
> like an SMSC 3503
This patch adds support for a new 'samsung,hsic-reset-gpio' in the
device tree, which will be interpreted as an active-low reset pin during
PHY initialization when it exists. Useful for intergrated HSIC devices
like an SMSC 3503 hub. It is necessary to add this directly to the PHY
initialization to
13 matches
Mail list logo
