Re: [PATCH] 2.5.15 IDE 62

[Martin Dalecki]

Uz.ytkownik [e-mail] 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.