linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* regarding xfer mode representation in dev, ap and other places
@ 2006-02-15 12:53 Tejun Heo
  2006-02-16 14:09 ` [PATCH 1/3] libata: fix sata_sil24 mwdma_mask setting Tejun Heo
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Tejun Heo @ 2006-02-15 12:53 UTC (permalink / raw)
  To: Jeff Garzik, Albert Lee, Alan Cox, Bartlomiej Zolnierkiewicz,
	Linux-ide

Hello, all.

Now that new reset mechanism is in tree and configuration changes are 
submitted, I'm about to send out transfer mode setting changes.  Two 
major goals of the changes are...

* Give upper layer the power to determine whether devices/ports go 
offline or not.

* Add per-device xfermode limit mask such that EH can limit transfer 
mode later.

One thing that bothers me is various representations of xfermode in 
ata_device, ata_port and other places.

* In ata_device, the current pio and dma transfer mode are recorded in 
->pio_mode and ->dma_mode using SETFEATURES XFERMODE constants.  Of the 
two, currently active mode is copied in ->xfer_mode and ->xfer_shift 
indicates which one is copied.

* In ata_port, supported transfer modes are recorded in three unsigned 
int fields, ->pio_mask, ->mwdma_mask and ->udma_mask.

* Yet another representation is used for printing supported transfer 
mode.  This is a combined mask of ->pio_mask, ->mwdma_mask and 
->udma_mask shifted by respective ATA_SHIFT_XXX.

IMHO, storing SETFEATURES XFERMODE constants and ATA_SHIFT_xxx isn't a 
very good idea.  Except for writing directly to the device, this value 
is just cumbersome to deal with.  e.g. we currently have awkward code 
involving base_from_shift() and offset arithmetics to reverse map and 
print configured transfer mode in ata_dev_set_mode().  Logical transfer 
mode -> constants is easy, the other way around, not.  Also, multiple 
transfer modes cannot be represented in this way.

Of the left two representations, IMHO, the packed one is easier to deal 
with.  It can be easily passed, returned and masked.  Storing as a 
single mask and unpacking when needed is much more convenient then 
carrying around three values, and it isn't like we're gonna need more 
than 32 bits in any foreseeable future; also, we always have u64.

So, I'm proposing to convert all transfer mode representations to one 
packed bit mask which would be u32 for now.  How does it sound?

Thanks.

-- 
tejun

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

end of thread, other threads:[~2006-02-16 15:02 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-15 12:53 regarding xfer mode representation in dev, ap and other places Tejun Heo
2006-02-16 14:09 ` [PATCH 1/3] libata: fix sata_sil24 mwdma_mask setting Tejun Heo
2006-02-16 14:09 ` [PATCHSET] libata: use single unsigned int xfer_mask Tejun Heo
2006-02-16 14:27   ` Tejun Heo
2006-02-16 14:46     ` Alan Cox
2006-02-16 14:09 ` [PATCH 3/3] libata: make ata_port_info and ata_probe_ent use xfer_mask Tejun Heo
2006-02-16 14:09 ` [PATCH 2/3] libata: make ata_device and ata_port use unsigned int xfer_mask Tejun Heo
2006-02-16 14:32   ` Alan Cox
2006-02-16 15:01     ` Tejun Heo

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