From: Albert Lee <albertcc@tw.ibm.com>
To: Tejun Heo <htejun@gmail.com>
Cc: jgarzik@pobox.com, alan@lxorguk.ukuu.org.uk, linux-ide@vger.kernel.org
Subject: Re: [PATCH 2/6] libata: add xfer_mask handling functions
Date: Tue, 07 Mar 2006 13:51:05 +0800 [thread overview]
Message-ID: <440D1F49.5040508@tw.ibm.com> (raw)
In-Reply-To: <11415871161635-git-send-email-htejun@gmail.com>
Tejun Heo wrote:
> Add ata_pack_xfermask(), ata_xfer_mask2mode(), ata_xfer_mode2mask(),
> ata_xfer_mode2shift() and ata_id_xfermask(). These functions will be
> used by following patches to simplify xfer_mask handling.
>
> Signed-off-by: Tejun Heo <htejun@gmail.com>
>
> (snip)
> +/**
> + * ata_id_xfermask - Compute xfermask from the given IDENTIFY data
> + * @id: IDENTIFY data to compute xfer mask from
> + *
> + * Compute the xfermask for this device. This is not as trivial
> + * as it seems if we must consider early devices correctly.
> + *
> + * FIXME: pre IDE drive timing (do we care ?).
> + *
> + * LOCKING:
> + * None.
> + *
> + * RETURNS:
> + * Computed xfermask
> + */
> +static unsigned int ata_id_xfermask(const u16 *id)
> +{
> + unsigned int pio_mask, mwdma_mask, udma_mask;
> +
> + /* Usual case. Word 53 indicates word 64 is valid */
> + if (id[ATA_ID_FIELD_VALID] & (1 << 1)) {
> + pio_mask = id[ATA_ID_PIO_MODES] & 0x03;
> + pio_mask <<= 3;
> + pio_mask |= 0x7;
> + } else {
> + /* If word 64 isn't valid then Word 51 high byte holds
> + * the PIO timing number for the maximum. Turn it into
> + * a mask.
> + */
> + pio_mask = (2 << (id[ATA_ID_OLD_PIO_MODES] & 0xFF)) - 1 ;
> +
> + /* But wait.. there's more. Design your standards by
> + * committee and you too can get a free iordy field to
> + * process. However its the speeds not the modes that
> + * are supported... Note drivers using the timing API
> + * will get this right anyway
> + */
> + }
> +
> + mwdma_mask = id[ATA_ID_MWDMA_MODES] & 0x07;
> + udma_mask = id[ATA_ID_UDMA_MODES] & 0xff;
> +
> + return ata_pack_xfermask(pio_mask, mwdma_mask, udma_mask);
> +}
> +
> /*
We have ap->pio_mask, ap->mwdma_mask and ap->udma_mask.
Just thinking what if we have these masks in ata_device?
Maybe we can save some bitwise operations and make the code more intuitive to read?
Ex. ata_id_xfermask() can store the calculated masks to dev->pio_mask, dev->mwdma_mask, etc.
Ex. ata_mode_string() can take mode (XFER_UDMA_7..) as parameter and translate the given mode to string.
Ex. to print out the max mode support by the device,
1. ata_id_xfermask() calculates and saves the masks to dev->pio_mask, etc.
2. Another function, say, ata_dev_max_mode() takes dev as parameter,
packs the mode by ata_pack_xfermask() internally,
find the max mode supported by the drive,
then use ata_xfer_mask2mode() to return the mode.
3. ata_mode_string() translates the mode, say XFER_UDMA_7, to string literal.
Albert
next prev parent reply other threads:[~2006-03-07 5:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-05 19:31 [PATCHSET] libata: improve transfer mode handling Tejun Heo
2006-03-05 19:31 ` [PATCH 3/6] libata: use ata_id_xfermask() in ata_dev_configure() Tejun Heo
2006-03-05 19:31 ` [PATCH 1/6] libata: improve xfer mask constants and update ata_mode_string() Tejun Heo
2006-03-12 0:03 ` Jeff Garzik
2006-03-05 19:31 ` [PATCH 2/6] libata: add xfer_mask handling functions Tejun Heo
2006-03-07 5:51 ` Albert Lee [this message]
2006-03-07 6:47 ` Tejun Heo
2006-03-12 0:01 ` Jeff Garzik
2006-03-12 3:34 ` [PATCH] libata: check Word 88 validity in ata_id_xfer_mask() Tejun Heo
2006-03-05 19:31 ` [PATCH 4/6] libata: use xfer_mask helpers in ata_dev_set_mode() Tejun Heo
2006-03-05 19:31 ` [PATCH 6/6] libata: kill unused xfer_mode functions Tejun Heo
2006-03-05 19:35 ` Tejun Heo
2006-03-05 19:31 ` [PATCH 5/6] libata: reimplement ata_set_mode() using xfer_mask helpers Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=440D1F49.5040508@tw.ibm.com \
--to=albertcc@tw.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertl@mail.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).