LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Proposed changes for libata speed handling
@ 2007-01-12 13:53 Alan
  2007-01-13  2:02 ` Tejun Heo
  0 siblings, 1 reply; 5+ messages in thread
From: Alan @ 2007-01-12 13:53 UTC (permalink / raw)
  To: linux-ide, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Proposed changes for libata speed handling
  2007-01-12 13:53 Proposed changes for libata speed handling Alan
@ 2007-01-13  2:02 ` Tejun Heo
  2007-01-13 10:01   ` Alan
  0 siblings, 1 reply; 5+ messages in thread
From: Tejun Heo @ 2007-01-13  2:02 UTC (permalink / raw)
  To: Alan; +Cc: linux-ide, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Proposed changes for libata speed handling
  2007-01-13  2:02 ` Tejun Heo
@ 2007-01-13 10:01   ` Alan
  2007-01-15  3:09     ` Tejun Heo
  0 siblings, 1 reply; 5+ messages in thread
From: Alan @ 2007-01-13 10:01 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-ide, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Proposed changes for libata speed handling
  2007-01-13 10:01   ` Alan
@ 2007-01-15  3:09     ` Tejun Heo
  2007-01-15 13:52       ` Jeff Garzik
  0 siblings, 1 reply; 5+ messages in thread
From: Tejun Heo @ 2007-01-15  3:09 UTC (permalink / raw)
  To: Alan; +Cc: linux-ide, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Proposed changes for libata speed handling
  2007-01-15  3:09     ` Tejun Heo
@ 2007-01-15 13:52       ` Jeff Garzik
  0 siblings, 0 replies; 5+ messages in thread
From: Jeff Garzik @ 2007-01-15 13:52 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Alan, linux-ide, linux-kernel

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-01-15 13:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-12 13:53 Proposed changes for libata speed handling Alan
2007-01-13  2:02 ` Tejun Heo
2007-01-13 10:01   ` Alan
2007-01-15  3:09     ` Tejun Heo
2007-01-15 13:52       ` Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).