Hi Sascha,
On Wed, March 11, 2015 4:46 pm, Sascha Hauer wrote:
> On Wed, Mar 11, 2015 at 04:05:31PM +0100, Bas Vermeulen wrote:
>>
>> On Wed, March 11, 2015 4:01 pm, Sascha Hauer wrote:
>> > On Wed, Mar 11, 2015 at 03:52:53PM +0100, Bas Vermeulen wrote:
>> >> Hello,
>> >>
>> >> On Wed, March 11, 2015 2:51 pm, Sascha Hauer wrote:
>> >> > This driver normally is not used with device tree. Without
>> additional
>> >> > kernel changes the chipidea driver is used instead.
>> >>
>> >> I'm just forward-porting a patch I made for 2.6.31.14 to workaround
>> >> an issue we found. I'm unsure where to fit this in in the chipidea
>> >> driver.
>> >>
>> >> However, if you read the errata for the i.mx35, you will see the
>> problem
>> >> and the fix proposed. I have been unable to find that errata for
>> other
>> >> soc's in the family (but some google fu found somewhat similar issues
>> >> for
>> >> i.mx25 and i.mx51).
>> >>
>> >> I would still like to get this patch incorporated into the ehci-mxc
>> >> driver, as it might make it easier to find for people with the same
>> >> problem.
>> >
>> > If you start your board with device tree the ehci-mxc driver will
>> never
>> > be started, because noone ever registers the device. When you start
>> > without device tree (but instead with board file)
>> > of_machine_is_compatible("fsl,imx35") will always return false because
>> > there is no device tree. To trigger your fixup one would have to start
>> > the kernel via device tree and additionally create a board file which
>> > registers the ehci-mxc device. A rather unusual case.
>>
>> What should I use instead? I'm fine changing the patch, I'm just not
>> sure
>> what to use to make it conditional.
>
> A question is whether it should be conditional at all. We are currently
> hunting a very hard to trigger bug on the i.MX53 which could be this
> one. We are testing it and Michael will can send a (tested) patch later.
> However, this will probably take some weeks because as said the bugs
> takes very long to trigger.
Try communicating over two usb interfaces at the same time.
The problem is triggered by the AHB being interrupted by a higher priority
target while transferring with SINGLE transfers.
Our scenario uses a cdc-acm connection to a modem, and a different
connection to a tablet. The (short) communication with the modem (data
connection using ppp) hangs up relatively fast on the i.mx35.
Bas Vermeulen
--
Blackstar Embedded Services
Hoofdweg 128 * 9626AJ * Schildwolde * The Netherlands
T: +31 598 423928 * F: +31 598 423991 * M: +31 6 45622453
E-mail: bas.vermeulen@xxxxxxxxxxxx
KvK: 01163970 * BTW-nummer: NL142605608B01
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
