Proposed changes for libata speed handling

Proposed changes for libata speed handling

[Alan]

I'm currently hacking on the speed handling code a bit

I'd like to do the following unless anyone has any objections

- Remove post_set_mode and make drivers wrap the guts of the existing
set_mode() function. This allows a driver to wrap and see success/failure
while removing a callback, and also to add pre-mode code. (ie you'd do

foo_set_mode() {
    ata_default_set_mode()
    my_fiddling();
}

- Fix the ->set_mode method FIXMEs in the current tree [DONE]

- Add set_specific_mode, with a default behaviour that works for most
controllers. Those using a private ->set_mode might need a private
->set_specific_mode, in some cases like it8212 simply to error the request

- Hook set_specific_mode to the ata command parser so that instead of
erroring set_features commands we snoop them and force the mode change
desired on the controller (if valid)

- Send the command to set the speed before setting the controller speed,
so that we send them at the right rate.

Any comments ?

Alan

Re: Proposed changes for libata speed handling

[Tejun Heo]

Alan wrote:
> I'm currently hacking on the speed handling code a bit
> 
> I'd like to do the following unless anyone has any objections
> 
> - Remove post_set_mode and make drivers wrap the guts of the existing
> set_mode() function. This allows a driver to wrap and see success/failure
> while removing a callback, and also to add pre-mode code. (ie you'd do
> 
> foo_set_mode() {
>     ata_default_set_mode()
>     my_fiddling();
> }
> 
> - Fix the ->set_mode method FIXMEs in the current tree [DONE]
> 
> - Add set_specific_mode, with a default behaviour that works for most
> controllers. Those using a private ->set_mode might need a private
> ->set_specific_mode, in some cases like it8212 simply to error the request
> 
> - Hook set_specific_mode to the ata command parser so that instead of
> erroring set_features commands we snoop them and force the mode change
> desired on the controller (if valid)
> 
> - Send the command to set the speed before setting the controller speed,
> so that we send them at the right rate.
> 
> Any comments ?

Wouldn't it be better to have ->determine_xfer_mask() and
->set_specific_mode() than having two somewhat overlapping callbacks?
Or is there some problem that can't be handled that way?

Thanks.

-- 
tejun

Re: Proposed changes for libata speed handling

[Alan]

O> Wouldn't it be better to have ->determine_xfer_mask() and
> ->set_specific_mode() than having two somewhat overlapping callbacks?
> Or is there some problem that can't be handled that way?

I'm not sure I follow what you are suggesting - can you explain further.

Right now ->set_mode does all the policy management with regards to
picking the right modes which is sometimes done by the usual ATA rules
and sometimes by card specific code.

->set_specific_mode does no policy work but merely sets up a mode.

The default behaviour of ->set_mode() is the ATA mode selection by best
mode available, and this function is normally not provided by a driver.

The default behaviour of ->set_specific_mode() is to verify the mode is
valid then issue ->set_pio|dma_mode() (for both devices in case a timing
change on both is triggered). This function is overridable because of
things like IT821x where the IDE mode is imaginary.

Alan

Re: Proposed changes for libata speed handling

[Tejun Heo]

Alan wrote:
> O> Wouldn't it be better to have ->determine_xfer_mask() and
>> ->set_specific_mode() than having two somewhat overlapping callbacks?
>> Or is there some problem that can't be handled that way?
> 
> I'm not sure I follow what you are suggesting - can you explain further.
> 
> Right now ->set_mode does all the policy management with regards to
> picking the right modes which is sometimes done by the usual ATA rules
> and sometimes by card specific code.
> 
> ->set_specific_mode does no policy work but merely sets up a mode.
> 
> The default behaviour of ->set_mode() is the ATA mode selection by best
> mode available, and this function is normally not provided by a driver.
> 
> The default behaviour of ->set_specific_mode() is to verify the mode is
> valid then issue ->set_pio|dma_mode() (for both devices in case a timing
> change on both is triggered). This function is overridable because of
> things like IT821x where the IDE mode is imaginary.

What I was thinking about was something like the following.

* ops

	unsigned int (*determine_xfer_mask)(struct ata_device *dev);
	int (*set_specific_mode)(struct ata_device *dev,
				unsigned int xfer_mode);

* during init and EH

	if (init) {
		ap->xfer_mask &= ops->determine_xfer_mask(dev);
		DETERMINE best_mode;
	}

	if (ap->ehi.target_mode && valid)
		mode = ap->ehi.target_mode;
	else
		mode = best_mode;

	rc = ops->set_specific_mode(dev, mode);

* when the user issues SET_XFERMODE, in the issue path

	if (command is SET_XFERMODE) {
		if (mode is invalid)
			fail;
		ap->ehi.target_mode = user_specified_mode;
		ata_port_schedule_eh(ap);
		done;
	}

To sum up,

1. separate supported mode detection and mode programming such that we
can use the same programming path for both init and handling user-issued
SET_XFERMODE.

2. group all mode programming callbacks (->set_piomode, ->set_dmamode
and ->post_set_mode into ->set_specific_mode) into ->set_specific_mode
to allow more flexibility and replace ->set_mode.

3. make sure all xfer mode programming is done in EH.  this will ease
support for weird controllers (e.g. cross-port synchronization).

Thanks.

-- 
tejun

Re: Proposed changes for libata speed handling

[Jeff Garzik]

BTW, for a solution to be complete, we need to halt all work on all 
other ports, when issuing SET FEATURES - XFER MODE.  On SiI and Promise 
controllers, possibly others, the command is snooped and side effects 
such as register setting occur.

Long standing to-do.  Currently we hack around this by serializing the 
bus probe, and preventing people from issuing SET FEATURES - XFER MODE 
from userspace.

	Jeff