Messages in this thread | | | Date | Tue, 14 May 2002 10:48:14 +0200 | From | Martin Dalecki <> | Subject | Re: [PATCH] 2.5.15 IDE 62 |
| |
Uz.ytkownik benh@kernel.crashing.org napisa?: >>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.
The problem is that not all setup register file access is localized to the particular host chip driver. Go look for rz1000 - it does not export any correposponding function. And we have therefore to deal with it on the generic level.
> 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 ?
See above.
- 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/
| |