From: Thomas Dahlmann <dahlmann.thomas@arcor.de>
To: Vadim Lobanov <vlobanov@speakeasy.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: amd5536udc interrupts bug
Date: Sat, 10 Jan 2009 21:28:20 +0100 [thread overview]
Message-ID: <496904E4.2000701@arcor.de> (raw)
In-Reply-To: <200901091440.15888.vlobanov@speakeasy.net>
Vadim Lobanov schrieb:
> On Friday 09 January 2009 03:41:21 Thomas Dahlmann wrote:
>
>> Vadim Lobanov schrieb:
>>
>>> Alas, the hardware doesn't work. When I try plugging in the other end of
>>> the USB cable, absolutely nothing happens. Not even an interrupt:
>>> /proc/interrupts for the amd5536udc line stays at zero. Any thoughts on
>>> possible ways to tackle this / what could be going wrong / etc?
>>>
>
> Just realized that I forgot to mention that I do also have g_zero sitting on
> top of amd5536udc, so there should at least be a dummy USB device to
> enumerate.
>
>
Right, g_zero should enumerate. It also provides data sink/source and
loopback functionality.
If you want to test data traffic then g_file_storage would be a good
choice as it behaves as a mass storage
device.
Example:
dd bs=1M count=64 if=/dev/zero of=/tmp/image_file
modrobe g_file_storage file=/tmp/image_file
(create partition and file system from host side)
>> Is there any output in the kernel messages on the host side complaining
>> about that device is
>> not answering? If not than USB device port is probably not connected to
>> UDC PHY. Please
>> check in BIOS setup that port 4 is assigned to UDC.
>>
>
> Nope, nothing at all shows up in the logs or the interrupt counts when the
> cable is plugged, neither for the host drivers nor the device drivers. (The
> quickest test I have is to hook the device up to itself - one A port and one B
> port.)
>
> The BIOS is configured "correctly" if the manuals are to be trusted. Here are
> the relevant settings
> OHCI: Enabled
> EHCI: Enabled
> UDC: Enabled
> UOC: Disabled
> Overcurrent reporting: Disabled
> Port 4 assignment: Device
>
UOC has to be enabled. This controller switches the UDC PHY to port 4
and owns the mentioned
PAD_EN and APU bits. These bits live in the memory mapped register space
of UOC. I use a
company intern tools to look at memory spaces of PCI devices. Lets
forget these bits so far as I am
pretty sure that enabling UOC fixes the problem.
Thomas
next prev parent reply other threads:[~2009-01-10 20:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49661E83.2070703@arcor.de>
2009-01-08 16:40 ` amd5536udc interrupts bug Thomas Dahlmann
2009-01-08 18:27 ` Vadim Lobanov
2009-01-09 2:02 ` Vadim Lobanov
2009-01-09 11:41 ` Thomas Dahlmann
2009-01-09 22:40 ` Vadim Lobanov
2009-01-10 20:28 ` Thomas Dahlmann [this message]
2009-01-12 19:02 ` Vadim Lobanov
2009-01-13 19:19 ` Vadim Lobanov
2009-01-14 12:43 ` Thomas Dahlmann
2009-01-14 22:49 ` Vadim Lobanov
2009-01-15 9:26 ` Thomas Dahlmann
2009-01-17 0:17 ` Vadim Lobanov
2009-01-19 12:23 ` Thomas Dahlmann
2009-01-07 23:10 Vadim Lobanov
2009-01-08 2:32 ` Robert Hancock
2009-01-08 3:30 ` Vadim Lobanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496904E4.2000701@arcor.de \
--to=dahlmann.thomas@arcor.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vlobanov@speakeasy.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.