Messages in this thread | | | From | <> | Subject | Re: [PATCH] 2.5.15 IDE 62 | Date | Mon, 13 May 2002 20:13:07 +0100 |
| |
>Just to clarify it... From the host view it's not the chipset >it's a channel we have to deal with. And there are typically two >channels on a host. For the serialized parts, we have to >possiblities: > >1. Preserve the current behaviour of using additionally a global >lock. > >2. "Cheat" and reuse the lock from the primary channel during >the initialization of the secondary channel. > >Hmmm.... Thinking a bit about it I'm now conviced that 2. is more >elegant then 1. And finally this will >just allow us to make the hwgroup_t go entierly away.
I would do things differently. From the common point of view, what we deal with is
controller / \ channel x, channel y, ....
That is an _arbitrary_ number of channels. So the host driver should just register individual "channels" to the IDE layer, each one has it's queue lock, period.
Now, if for any reason, the host specific code has to synchronize between several of it's channels when dealing with things like chipset configuration, it's up to that host driver to know about it and deal with it; which make perfect sense to be done with a third lock specific to protecting those specific registers that are shared and that is completely internal to the host chipset driver.
The only case I see where the host may have to additionally go and grab the other channel's locks (the queue lock or whatever you call it) is if the actual setting change on one channel has side effect on a currently transferring other channel.
But that is completely internal to the host, and yes, I agree that reusing the other channel's lock is probably the best solution.
But in cases where you just have 2 bitfields in the same register that need serialized access from both channels, a simple lock protecting only that register seems to be plenty enough.
What did I miss ?
Ben.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |