From: "Markus Klotzbücher" <mk@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH 2/3] Added USB PCI-OHCI chips support, interrupt pipe support and usb event poll support.
Date: Tue, 15 May 2007 08:27:36 +0000 [thread overview]
Message-ID: <874pme330n.fsf@denx.de> (raw)
In-Reply-To: <46B96294322F7D458F9648B60E15112C234179@zch01exm26.fsl.freescale.net> (Zhang Wei-r's message of "Tue, 15 May 2007 10:35:08 +0800")
Hi Zhang Wei,
Thanks for your comments.
"Zhang Wei-r63237" <Wei.Zhang@freescale.com> writes:
> <...>
>> >
>> > -#define readl(a) (*((vu_long *)(a)))
>> > -#define writel(a, b) (*((vu_long *)(b)) = ((vu_long)a))
>> > +#define readl(a) m32_swap(*((vu_long *)(a)))
>> > +#define writel(a, b) (*((vu_long *)(b)) = m32_swap((vu_long)a))
>>
>> Can you explain why this is needed? I'm well aware that the
> endianness
>> handling in the USB Code has become pretty awfull, so I'm trying to
> at
>> least understand why what is needed.
>>
>
> Yes, the endian is a really awfull problem. :) If you do not swap the
> value, you will get or put a wrong endian data in big-endian boards,
> such as most powerpc boards. I've printed the debug information with
> the register value by using readl() in our MPC8641HPCN board
> (big-endian), no swap, the register value is endianness different than
> linux kernel usb-driver. It can not work. So, in x86 or the other
> little-endian platforms, the swap is no need, but in big-endian
> platforms, the swap is must be.
So this BE CPU and LE Controller again. The only problem I see with your
fix is that because you _always_ do byteswapping for register accesses
on BE CPUs, this would break support for the case BE CPU and BE OHCI
Controller (but which doesn't exist in U-Boot so far).
No need to change this now, because I'm going to clean this up soon, but
I'd appreciate your help in testing once this is done.
>
>> > #define min_t(type,x,y) ({ type __x = (x); type __y = (y);
>> __x < __y
>> > ? __x: __y; })
>> >
>> > -#undef DEBUG
>> > +#ifdef CONFIG_PCI_OHCI
>> > +static struct pci_device_id ohci_pci_ids[] = {
>> > + {0x10b9, 0x5237}, /* ULI1575 PCI OHCI module ids */
>> > + /* Please add supported PCI OHCI controller ids here */
>> > + {0, 0}
>> > +};
>> > +#endif
>> > +
>> > #ifdef DEBUG
>> > #define dbg(format, arg...) printf("DEBUG: " format "\n", ## arg)
>> > #else
>> > @@ -114,15 +130,11 @@ struct ohci_hcca ghcca[1];
>> > struct ohci_hcca *phcca;
>> > /* this allocates EDs for all possible endpoints */
>> > struct ohci_device ohci_dev;
>> > -/* urb_priv */
>> > -urb_priv_t urb_priv;
>> > /* RHSC flag */
>> > int got_rhsc;
>> > /* device which was disconnected */
>> > struct usb_device *devgone;
>> >
>> > -/* flag guarding URB transation */
>> > -int urb_finished = 0;
>>
>> Can you explain why this flag is not needed anymore? We had a
>> discussion
>> about this some time ago and agreed that is should not be
>> removed unless
>> we understand exactly why it was put there.
>>
>
> You misunderstands it. :) I do not remove it. I just move it to the
> individual urb structure.
> I'll explain it. If no interrupt pipe support, a global urb_finished
> flag is ok, only one urb should be processed in the same time. But if
> the interrupt pipe support is added, it's difference. The interrupt
> pipe is an 'endless' urb, there are more than one urb should be
> processed in the same time. When the interrupt pipe is in processing,
> the other urb such as ctrl urb is also should be processed. So I move
> the urb_finished flag to individual urb structure: urb->finished.
>
> Such as below:
>
>> > /* we're about to begin a new transaction here so mark the URB
>> > unfinished */
>> > - urb_finished = 0;
>> > + urb->finished = 0;
>> >
>> > /* every endpoint has a ed, locate and fill it */
>> > - if (!(ed = ep_add_ed (dev, pipe))) {
>> > + if (!(ed = ep_add_ed (dev, pipe, interval, 1))) {
>> > err("sohci_submit_job: ENOMEM");
>> > return -1;
I get it, thanks for explaining.
Best regards
Markus
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2007-05-15 8:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 3:48 [U-Boot-Users] [PATCH 2/3] Added USB PCI-OHCI chips support, interrupt pipe support and usb event poll support Zhang Wei
2007-05-14 14:47 ` Markus Klotzbücher
2007-05-15 2:35 ` Zhang Wei-r63237
2007-05-15 8:27 ` Markus Klotzbücher [this message]
2007-05-15 9:02 ` Zhang Wei-r63237
2007-05-15 10:01 ` Markus Klotzbücher
2007-05-16 2:05 ` Zhang Wei-r63237
2007-05-21 2:39 ` Zhang Wei-r63237
2007-05-22 9:06 ` Markus Klotzbücher
2007-06-06 10:52 ` Markus Klotzbücher
2007-06-06 19:31 ` Jon Loeliger
2007-06-07 9:12 ` Zhang Wei-r63237
2007-06-11 13:28 ` Markus Klotzbücher
2007-07-03 8:25 ` Robert Delien
2007-07-03 9:01 ` Zhang Wei-r63237
2007-07-03 10:13 ` Robert Delien
2007-07-03 10:39 ` Zhang Wei-r63237
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=874pme330n.fsf@denx.de \
--to=mk@denx.de \
--cc=u-boot@lists.denx.de \
/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.