Hi David,
basically, I like the idea of shared HCI code.
If you want you can see my patches as a step in that direction.
I would expect a common architecture in Kernel 2.5.
But first a short history:
a lot of the changes of the m8xxhci driver I have done in
november and december. I had a serious unknown hardware problem
with the MPC850 until January,
until I have found the right errata sheet.
This means that everything worked somehow but
there was strange errors.
So I did not feel confortable to make any patches at all at this time.
>From that short history you should see that the development of your
ehci was at about the same timeframe.
The architecture of the MPC8xx HC is poorly documented and
let say not very easy. Brads HCD code/architecture basically works but
there
was/are some bugs with bulk transfers and he uses a root-hub process
like
the early UHCI drivers.
When I got a little bit lost in Brads code,
my intention was to take the building blocks of the OHCI driver because
I know them
and also they are smaller/simpler. If we keep that code is another
question
but it helped me to make it work.
Well, all of the HCDs share my virtual root-hub code
(except ehci just indirectly).
I have written the OHCI and usb-uhci virtual roothubs and the patch for
m8xxhci.
The uhci virtual root hub is based on the usb-uhci one.
(if this is wrong please correct me)
They do not share code directly but they have the same
structure/codebase
(copy and paste).
Now, it should be easy in a next step to also let them share code.
(e.g. the version you use in ehci or something like that)
Also the other building blocks should converge as much as it is
possible.
- Roman
David Brownell wrote:
>
> Roman,
>
> Thanks for posting that!
>
> > Patch 2: replaces the 'old fashioned' roothub process with a
> > virtual root hub and also uses the bus wires to detect new devices
> > (this makes it more conform with how other Linux USB-host-driver
> > like OHCI and UHCI manages the root-hub
> > and the detection of devices is more USB spec. conform)
>
> This is interesting. So by my count we now have five publicly
> available USB Host Controller Drivers (hcds) in various stages,
> not sharing much code at all:
>
> - ohci (and patches for at least ARM/PPC)
> - 2 uhci drivers
> - mpc823/850
> - ehci (early usb 2.0 support, limps; [1])
>
> I don't know how much you looked at the "hcd" layer in my
> EHCI code, but as I recall you liked the basic premise of
> sharing more code. Basically, more sharing means fewer
> places that hcd-specific behaviors (bugs) can happen, and
> better testing/tuning/reliability in the shared code.
>
> Have you looked at using the root hub code in that framework?
> I think you're not going to care about the pci support, but that's
> optional anyway. The root hub code is based on yours, but it
> it's split into generic vs hcd-specific parts and doesn't provide
> analogues for "hub.h" or "usb.h" already handle.
>
> I'd like to see the new host controller drivers sharing as
> much code as possible. Do you agree? If so, got any
> suggestions about how to move forward? One idea is
> to have a development tree in cvs at sourceforge. Or
> just to add a new "linux/drivers/usb/hcd.c" that could be
> used by newer drivers; maybe it could just provide more
> functionality in an enlarged "usb_bus" layer rather than
> creating an more functional version of the same abstraction.
>
> - Dave
>
> [1] http://marc.theaimsgroup.com/?l=linux-usb-devel&m=98384579217143&w=2
>
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
