Re: [PATCH] 2.5.15 IDE 62

benh
2002-05-13T18:12:37Z

>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.