why multiple controllers for multiple speeds? - Hardware

This is a discussion on why multiple controllers for multiple speeds? - Hardware ; Why does USB have to have multiple controllers for multiple speeds? I could understand that for newer higher speeds, significant redesign could be necesssary (it might not be enough to just up the clock speed in things like serializers). This ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: why multiple controllers for multiple speeds?

  1. why multiple controllers for multiple speeds?

    Why does USB have to have multiple controllers for multiple speeds?

    I could understand that for newer higher speeds, significant redesign could
    be necesssary (it might not be enough to just up the clock speed in things
    like serializers). This may even require changing the way a driver works
    with the controller because the slower speed's original design might be too
    inefficient for success at the higher rates given the core bus speed (such
    as PCI).

    But what I see is that things like a USB controller that has both 1.1 and
    2.0 versions actually has two distinct controllers that can apparently
    switch in and out as needed.

    Why can't a new controller that handles higher speeds just simply be able
    to handle he slower speeds as well, with the very same driver for both,
    in addition to _maybe_ having a compatibility mode for older drivers that
    only know the previous driver-to-hardware interface?

    In general it does seem to me that a great many hardware devices do seem
    to have poorly designed interfaces for their OS drivers. They change them
    with new versions of the hardware, and even sometimes with minor revision
    changes. And they change it not just adding features, but even to the
    extreme of total incompatibility with the older driver with only older
    feature support (which tells me they determined the older interface was
    really inadequate).

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-06-01-2100@ipal.net |
    |------------------------------------/-------------------------------------|

  2. Re: why multiple controllers for multiple speeds?

    phil-news-nospam@ipal.net wrote:
    > Why does USB have to have multiple controllers for multiple speeds?


    It doesn't have to; most USB controllers handle all three speeds.

    > I could understand that for newer higher speeds, significant redesign could
    > be necesssary (it might not be enough to just up the clock speed in things
    > like serializers). This may even require changing the way a driver works
    > with the controller because the slower speed's original design might be too
    > inefficient for success at the higher rates given the core bus speed (such
    > as PCI).
    >
    > But what I see is that things like a USB controller that has both 1.1 and
    > 2.0 versions actually has two distinct controllers that can apparently
    > switch in and out as needed.


    When Intel designed their EHCI controller, the part for handling full/
    low speed devices was so buggy that the only way to meet the release
    date was to add a plain old UHCI controller and a simple switch to
    connect the ports to either the high speed or a full/low speed
    controller.

    BTW: When Intel designed the UHCI specification, they forgot to
    include a mechanism to tell the driver about how many ports the
    hardware has, so the driver has to assume that every UHCI has exactly
    two ports for compatibility reasons. Therefore, a modern controller
    that has more than two ports must pretend to be multiple UHCI
    controllers with two ports each.


    Regards,
    Clemens

  3. Re: why multiple controllers for multiple speeds?

    On Mon, 4 Jun 2007 14:31:37 +0200 Clemens Ladisch wrote:
    | phil-news-nospam@ipal.net wrote:
    |> Why does USB have to have multiple controllers for multiple speeds?
    |
    | It doesn't have to; most USB controllers handle all three speeds.
    |
    |> I could understand that for newer higher speeds, significant redesign could
    |> be necesssary (it might not be enough to just up the clock speed in things
    |> like serializers). This may even require changing the way a driver works
    |> with the controller because the slower speed's original design might be too
    |> inefficient for success at the higher rates given the core bus speed (such
    |> as PCI).
    |>
    |> But what I see is that things like a USB controller that has both 1.1 and
    |> 2.0 versions actually has two distinct controllers that can apparently
    |> switch in and out as needed.
    |
    | When Intel designed their EHCI controller, the part for handling full/
    | low speed devices was so buggy that the only way to meet the release
    | date was to add a plain old UHCI controller and a simple switch to
    | connect the ports to either the high speed or a full/low speed
    | controller.
    |
    | BTW: When Intel designed the UHCI specification, they forgot to
    | include a mechanism to tell the driver about how many ports the
    | hardware has, so the driver has to assume that every UHCI has exactly
    | two ports for compatibility reasons. Therefore, a modern controller
    | that has more than two ports must pretend to be multiple UHCI
    | controllers with two ports each.

    Sounds to me like we should not be allowing hardware manufacturers to be
    designing the interfaces between hardware and drivers. Instead of having
    drivers do designs to match (broken) hardware, how about we reverse the
    model and require hardware designers to match the software :-)

    FYI, at that point I'd design a generic DMA BUS message passing scheme for
    all classes of devices.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-06-07-2206@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: why multiple controllers for multiple speeds?

    phil-news-nospam@ipal.net wrote:

    > On Mon, 4 Jun 2007 14:31:37 +0200 Clemens Ladisch
    > wrote:
    > | phil-news-nospam@ipal.net wrote:
    > |> Why does USB have to have multiple controllers for multiple speeds?
    > |
    > | It doesn't have to; most USB controllers handle all three speeds.
    > |
    > |> I could understand that for newer higher speeds, significant redesign
    > |> could be necesssary (it might not be enough to just up the clock speed
    > |> in things
    > |> like serializers). This may even require changing the way a driver
    > |> works with the controller because the slower speed's original design
    > |> might be too inefficient for success at the higher rates given the core
    > |> bus speed (such as PCI).
    > |>
    > |> But what I see is that things like a USB controller that has both 1.1
    > |> and 2.0 versions actually has two distinct controllers that can
    > |> apparently switch in and out as needed.
    > |
    > | When Intel designed their EHCI controller, the part for handling full/
    > | low speed devices was so buggy that the only way to meet the release
    > | date was to add a plain old UHCI controller and a simple switch to
    > | connect the ports to either the high speed or a full/low speed
    > | controller.
    > |
    > | BTW: When Intel designed the UHCI specification, they forgot to
    > | include a mechanism to tell the driver about how many ports the
    > | hardware has, so the driver has to assume that every UHCI has exactly
    > | two ports for compatibility reasons. Therefore, a modern controller
    > | that has more than two ports must pretend to be multiple UHCI
    > | controllers with two ports each.
    >
    > Sounds to me like we should not be allowing hardware manufacturers to be
    > designing the interfaces between hardware and drivers. Instead of having
    > drivers do designs to match (broken) hardware, how about we reverse the
    > model and require hardware designers to match the software :-)
    >
    > FYI, at that point I'd design a generic DMA BUS message passing scheme for
    > all classes of devices.
    >

    Isn't that called infiniband or myrinet or something like that?
    --
    JosephKK
    Gegen dummheit kampfen die Gotter Selbst, vergebens.**
    --Schiller

+ Reply to Thread