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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox