On Wed, May 15, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > My response was that you're focus for the driver was wrong. You should > > be targeting for a working system, not a buggy one. > > Which, as I repeatedly explained, WAS exactly the target. > Not a fact you wanted to hear, I can tell. Really hearing it > would have helped avoid much noise.
Read linux-kernel for a while and you'll see the precedent that has been set. > > We can [ ... make all kinds of changes to resemble uhci ...] > > Let's not and say we didn't. I did observe how you do that > stuff in "uhci.c" and see no reason to change. It's different > hardware, different problems ... different solutions. Different problems? I just explained how they are similar and how there's an extremely easy solution. This is what I'm talking about you ignoring the points I make. Just because you ignore doesn't mean it doesn't matter. > > I spent some time trying to keep the conversations on topic and if that > > meant focusing on the real topic at hand, then I did. > > That is, the subtopic you wanted to talk about ... rather than > a different aspect of the original problem. In terms of resolving > issues, that was no help at all. The reference counting change was absolutely necessary to be resolved before anything could be definitively discussed about this topic. This is because the semantics of memory management are radically different between the two. With the change you made, all memory needed to be deallocated immediately. However, since the reference counting doesn't work that way anymore, so do the requirements. All of the talk before that was premature. > > > Could you give a point of yours that I've _ignored_ rather than > > > just not agreeing with? (I know I've pointed out this one issue more > > > than once, including your non-responses.) > > > > This whole thread for instance. You keep arguing that sohci_free_dev > > should be that complicated. > > I did not. Certainly that's your phrasing, not mine, and I don't > thank you for blaming it on me. If I justified anything, it was > the current code (ohci-hcd), which is already much simpler. Right. You justified by saying "It's different hardware, different problems ... different solutions" when I've already explained it's similar problem with a solution. However, since you refuse to listen, I'll finish making the patch and send it to Greg without your blessing. > I started by reminding you that the bus->deallocate() may block, > and has been allowed for several years now, though you kept > claiming otherwise. Your refcount changes caused trouble > in that area, which was not an issue in the 2.5.15 code. Actually it hasn't. Try to make it block in 2.4 and you'll find a surprise called an "Oops". It may work most of the time, but it's definately not guaranteed. Once again, I refer you to the actual code in 2.4. Go read it, please. How do I know it's not guaranteed? Because I wrote the reference counting code for 2.4 and it was designed that way. I'm really at a loss why you're even debating this point. There's nothing to debate about it, it's FACT. > Now, at some point you evidently absorbed the fact that you > were wrong about that, then decided that rather than say so, > you would instead change the topic ...attacking that reality as > if it were a bug. Only a very few recent messages made up > the changed topic, "this whole thread", from what I can tell. Wrong about it? Hah. Go read the code. Seriously, go. > Perhaps I should have noticed that's what was going on, but > my l33t mind-reading skillz aren't that strong. But considering > that you only went down that track recently, and I _did_ reply > to it, you can't really believe I ignored what you said. You read what I said, but you keep ignoring the content. It's not guaranteed, at all. > > However I keep pointing to uhci.c since it has pretty much the same > > problems. It's an example of how you can do this better. > > It's nothing but biased opinion to say "better" here. So less code with less paths is not better? Perhaps you could enlighten us how that's not better and perhaps what your definition of better is. > You want to make tradeoffs one way, for hardware that is much > less involved in maintaining endpoint state, which may be fine for > that hardware (UHCI). But the identical reasoning cannot apply > when the hardware is more involved (EHCI and OHCI). You need > to at least admit that there are differences, despite the surface > similarities which I had identified to you. Sure they are different, but when you get to the root of the problem, it's the same. The root problem is that you can't free the memory until the hardware is done with it. Both OHCI and UHCI have the same problem. That's why the same solution works for both of them. > I see it as you wanting to simplify one thing by making others > more complex ... and by making fairly significant changes to > the policy for managing endpoint state, including data toggles > (which are maintained in hardware except for UHCI) and for > handling the inevitable faults. Nope. I'm simplifying things by using the infrastructure that's already there. You already cleanup asynchronously, why not tie the memory management into instead of making it complicated like sohci_free_dev does? > There'd be a performance impact to be that aggressive about > taking the endpoint data (ED/QH) off the hardware schedules, > since it'd mean waiting extra intervals (frames/microframes) for > the endpoint unlinks to complete ... slowing down things like bulk > data requeuing speed. Perhaps you should go back and reread my original proposal and explicitily point out where the performance issues are. I didn't change when or how ED's get unlinked. That happens exactly the same way. > > I haven't seen very many arguments refuting it, you just keep saying > > things like "QH != dev", which are patently obvious and don't actually > > address the fact I've solved the problems with uhci.c. > > Patently obvious, but clearly not reflected in your original comment. > You were advocating a QH management policy that could only work > for devices... or so it seemed. (Maybe you were just omitting 90% > of what you were thinking.) Could you elaborate on this point a little bit more? I don't think I fully understand what you were saying. > > Anyway, all of this boils down to, been there, done that. > > I think you got carried away by the similarities I pointed out when > explaining some of this to you. There are also noteworthy > differences. The problem you solved was different. Ok, then do me the favor of explaining why it won't work. In the mean time, I'll be implementing it and proving it does work. JE _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
