Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello. David Brownell wrote: ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all have it) but e.g. MUSB doesn't have the root hub registers... Only the OHCI registers have bit positions matching what the USB spec says for hub status bits. Oh, didn't know that. Everything else, including musb_hdrc, has the relevant status encoded in other bits. Yes, but I thought that if there are no multiple ports, having the hub is just pointless. I looked at the core and figured that USB core seems to use the root hub interface for port PM, etc. and expects it to bee present, so it seems unavoidable indeed... :-/ Or more fundamentally: for enumeration. "Unavoidable" is correct. ;) Not sure what you mean here but I guess having a root hub alows an uniform model of controlling the ports... anyway, USB specifies that it must be present in the host. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
On Wednesday 24 September 2008, Sergei Shtylyov wrote: > > >> ... then the root hub emulation is completely pointless. > >> > > > > It isn't. We always should emulate the root hub. The root hub > > is part and parcel of any USB Host. Even the one-port one. > > Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all > have it) but e.g. MUSB doesn't have the root hub registers... Only the OHCI registers have bit positions matching what the USB spec says for hub status bits. Everything else, including musb_hdrc, has the relevant status encoded in other bits. > I looked at the core and figured that USB core seems to use the root hub > interface for port PM, etc. and expects it to bee present, so it seems > unavoidable indeed... :-/ Or more fundamentally: for enumeration. "Unavoidable" is correct. ;) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello, I wrote: This controller does not integrate the root hub, so this driver also fakes one-port hub. External hub is required to support more than one device. ... Please, no. What exactly 'no'? ;-) No one-port hubs I guess -- they are pointless. Though e.g. MUSB driver creates one -- I guess to impersonate a transaction translating high-speed hub... ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all have it) but e.g. MUSB doesn't have the root hub registers... Oops, I stand corrected. Even USB 1.1 specifies that it must be a part the host... WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello. Anton Vorontsov wrote: This controller does not integrate the root hub, so this driver also fakes one-port hub. External hub is required to support more than one device. ... Please, no. What exactly 'no'? ;-) No one-port hubs I guess -- they are pointless. Though e.g. MUSB driver creates one -- I guess to impersonate a transaction translating high-speed hub... ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all have it) but e.g. MUSB doesn't have the root hub registers... I looked at the core and figured that USB core seems to use the root hub interface for port PM, etc. and expects it to bee present, so it seems unavoidable indeed... :-/ WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
On Wed, Sep 24, 2008 at 01:35:41AM +0400, Sergei Shtylyov wrote: [...] > This controller does not integrate the root hub, so this driver also > fakes one-port hub. External hub is required to support more than > one device. > > ... > > Please, no. >>> >>> What exactly 'no'? ;-) >>> >> >> No one-port hubs I guess -- they are pointless. Though e.g. MUSB >> driver creates one -- I guess to impersonate a transaction translating >> high-speed hub... >> > > ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello, I wrote: This patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Ah, it's not even high-speed? Quite a lot the hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on software's shoulders. I imagine that must be worse than MUSB... :-/ This controller does not integrate the root hub, so this driver also fakes one-port hub. External hub is required to support more than one device. ... Please, no. What exactly 'no'? ;-) No one-port hubs I guess -- they are pointless. Though e.g. MUSB driver creates one -- I guess to impersonate a transaction translating high-speed hub... ... then the root hub emulation is completely pointless. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello. Anton Vorontsov wrote: This patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Quite a lot the hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on software's shoulders. This controller does not integrate the root hub, so this driver also fakes one-port hub. External hub is required to support more than one device. ... Please, no. What exactly 'no'? ;-) No one-port hubs I guess -- they are pointless. Though e.g. MUSB driver creates one -- I guess to impersonate a transaction translating high-speed hub... WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
On Fri, Sep 19, 2008 at 04:23:24PM -0700, Andrew Morton wrote: > On Thu, 18 Sep 2008 19:17:46 +0400 > Anton Vorontsov <[EMAIL PROTECTED]> wrote: > > > This patch adds support for the FHCI USB controller, as found > > in the Freescale MPC836x and MPC832x processors. It can support > > Full or Low speed modes. > > > > Quite a lot the hardware is doing by itself (SOF generation, CRC > > generation and checking), though scheduling and retransmission is on > > software's shoulders. > > > > This controller does not integrate the root hub, so this driver also > > fakes one-port hub. External hub is required to support more than > > one device. > > > > ... > > > > Please, no. What exactly 'no'? ;-) > > new file mode 100644 > > index 000..23716fa > > --- /dev/null > > +++ b/drivers/usb/host/fhci-cq.c > > @@ -0,0 +1,105 @@ > > +/* > > + * Freescale QUICC Engine USB Host Controller Driver > > + * > > + * Copyright (c) Freescale Semicondutor, Inc. 2006. > > + * Shlomi Gridish <[EMAIL PROTECTED]> > > + * Jerry Huang <[EMAIL PROTECTED]> > > + * Copyright (c) Logic Product Development, Inc. 2007 > > + * Peter Barada <[EMAIL PROTECTED]> > > + * Copyright (c) MontaVista Software, Inc. 2008. > > + * Anton Vorontsov <[EMAIL PROTECTED]> > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License as published by the > > + * Free Software Foundation; either version 2 of the License, or (at your > > + * option) any later version. > > + */ > > + > > +/* circular queue structure */ > > Yet another private ringbuffer implementation. Sigh. Heh. I changed this to kfifo, though I don't quite like it, since it feels heavy to hold mere pointers... [...] > > +++ b/drivers/usb/host/fhci-hcd.c > > @@ -0,0 +1,798 @@ > > +/* > > + * Freescale QUICC Engine USB Host Controller Driver > > + * > > + * Copyright (c) Freescale Semicondutor, Inc. 2006. > > + * Shlomi Gridish <[EMAIL PROTECTED]> > > + * Jerry Huang <[EMAIL PROTECTED]> > > + * Copyright (c) Logic Product Development, Inc. 2007 > > + * Peter Barada <[EMAIL PROTECTED]> > > + * Copyright (c) MontaVista Software, Inc. 2008. > > + * Anton Vorontsov <[EMAIL PROTECTED]> > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License as published by the > > + * Free Software Foundation; either version 2 of the License, or (at your > > + * option) any later version. > > + */ > > + > > +#if defined(CONFIG_FHCI_DEBUG) && !defined(DEBUG) > > +#define DEBUG > > +#endif > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include "../core/hcd.h" > > +#include "fhci.h" > > +#include "fhci-hub.c" > > +#include "fhci-q.c" > > +#include "fhci-dbg.c" > > +#include "fhci-mem.c" > > +#include "fhci-cq.c" > > +#include "fhci-tds.c" > > +#include "fhci-sched.c" > > hack, gack, nack. > > We know that USB likes to prevertedly #include C files all over the > place, but this doesn't mean that it's a sane, tasteful or desirable > thing to do. Hm. I fixed this, but for lengthy drivers, where we want split the driver in multiple logical files, this sometimes makes sense (for example, we don't need externed functions. plus gcc automatically might inline some of them, etc). Thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
On Thu, 18 Sep 2008 19:17:46 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > This patch adds support for the FHCI USB controller, as found > in the Freescale MPC836x and MPC832x processors. It can support > Full or Low speed modes. > > Quite a lot the hardware is doing by itself (SOF generation, CRC > generation and checking), though scheduling and retransmission is on > software's shoulders. > > This controller does not integrate the root hub, so this driver also > fakes one-port hub. External hub is required to support more than > one device. > > ... > Please, no. > new file mode 100644 > index 000..23716fa > --- /dev/null > +++ b/drivers/usb/host/fhci-cq.c > @@ -0,0 +1,105 @@ > +/* > + * Freescale QUICC Engine USB Host Controller Driver > + * > + * Copyright (c) Freescale Semicondutor, Inc. 2006. > + * Shlomi Gridish <[EMAIL PROTECTED]> > + * Jerry Huang <[EMAIL PROTECTED]> > + * Copyright (c) Logic Product Development, Inc. 2007 > + * Peter Barada <[EMAIL PROTECTED]> > + * Copyright (c) MontaVista Software, Inc. 2008. > + * Anton Vorontsov <[EMAIL PROTECTED]> > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > + > +/* circular queue structure */ Yet another private ringbuffer implementation. Sigh. > +struct cir_q { > + int max; /* size of queue */ > + int max_in; /* max items in queue */ > + int first;/* index of first in queue */ > + int last; /* index after last in queue */ > + int read; /* current reading position */ > + void *table[1]; /* fake size */ > +}; > + > +/* circular queue handle */ > +static int cq_howmany(struct cir_q *cq) > +{ > + int l = cq->last; > + int f = cq->first; > + > + return l >= f ? l - f : l + cq->max - f; > +} > + > +static struct cir_q *cq_new(int size) > +{ > + struct cir_q *cq; > + > + cq = kzalloc((sizeof(*cq) + size * sizeof(void *)), GFP_KERNEL); > + if (cq) { > + cq->max = size; > + cq->first = 0; > + cq->last = 0; > + cq->read = 0; > + cq->max_in = 0; The above four statements are unneeded. > + } > + > + return cq; > +} > > ... > > +++ b/drivers/usb/host/fhci-hcd.c > @@ -0,0 +1,798 @@ > +/* > + * Freescale QUICC Engine USB Host Controller Driver > + * > + * Copyright (c) Freescale Semicondutor, Inc. 2006. > + * Shlomi Gridish <[EMAIL PROTECTED]> > + * Jerry Huang <[EMAIL PROTECTED]> > + * Copyright (c) Logic Product Development, Inc. 2007 > + * Peter Barada <[EMAIL PROTECTED]> > + * Copyright (c) MontaVista Software, Inc. 2008. > + * Anton Vorontsov <[EMAIL PROTECTED]> > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > + > +#if defined(CONFIG_FHCI_DEBUG) && !defined(DEBUG) > +#define DEBUG > +#endif > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "../core/hcd.h" > +#include "fhci.h" > +#include "fhci-hub.c" > +#include "fhci-q.c" > +#include "fhci-dbg.c" > +#include "fhci-mem.c" > +#include "fhci-cq.c" > +#include "fhci-tds.c" > +#include "fhci-sched.c" hack, gack, nack. We know that USB likes to prevertedly #include C files all over the place, but this doesn't mean that it's a sane, tasteful or desirable thing to do. I stopped looking there. Guys - get a grip :( ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev