From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: albertcc@tw.ibm.com, alan@lxorguk.ukuu.org.uk, linux-ide@vger.kernel.org
Subject: Re: [PATCH 3/4] libata: add per-dev pio/mwdma/udma_mask
Date: Mon, 20 Mar 2006 20:56:39 -0500 [thread overview]
Message-ID: <441F5D57.4050906@pobox.com> (raw)
In-Reply-To: <20060313102412.GA25706@htj.dyndns.org>
Tejun Heo wrote:
> On Mon, Mar 13, 2006 at 05:13:36AM -0500, Jeff Garzik wrote:
>
>>Tejun Heo wrote:
>>
>>>On Mon, Mar 13, 2006 at 04:52:28AM -0500, Jeff Garzik wrote:
>>>
>>>
>>>>Tejun Heo wrote:
>>>>
>>>>
>>>>>On Mon, Mar 13, 2006 at 03:29:24AM -0500, Jeff Garzik wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Tejun Heo wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Add per-dev pio/mwdma/udma_mask. All transfer mode limits used to be
>>>>>>>applied to ap->*_mask which unnecessarily restricted other devices
>>>>>>>sharing the port. This change will also benefit later EH speed down
>>>>>>>and hotplug.
>>>>>>>
>>>>>>>Signed-off-by: Tejun Heo <htejun@gmail.com>
>>>>>>
>>>>>>I don't see much value in the separation. Rather than 3 separate
>>>>>>masks, it seems like this patch would be simplified if you simply added
>>>>>>dev->xfer_mask.
>>>>>>
>>>>>
>>>>>
>>>>>The thing is that ap->*_mask's are separated the same way and all
>>>>>masking constants are defined as such. e.g.
>>>>>
>>>>> ap->udma_mask &= ATA_UDMA5;
>>>>>or
>>>>> ap->udma_mask &= ATA_UDMA_MASK_40C;
>>>>>
>>>>>Making dev->*_mask's the same enables share those constants and code
>>>>>convention. So, things to consider here are...
>>>>>
>>>>>1. Port xfer masks are defined as three separate masks.
>>>>>
>>>>>2. All the constants are defined according to that.
>>>>>
>>>>>3. Three separate masks are easier to deal with for LLDD's.
>>>>
>>>>Separate masks is better for the LLDD interface, but the packed version
>>>>seems superior for internal libata use.
>>>
>>>
>>>Yeah, dev->*_mask's will be used by LLDD's. Actually, in patch #4 of
>>>this series, sata_sil's ->dev_config() does exactly that. Also, mode
>>>mask filtering can be done by diddling dev->*_mask's.
>>>
>>>
>>>
>>>>No reason why ATA_UDMA_MASK_40C can't simply operate on a packed
>>>>xfer_mask variable, for example.
>>>
>>>
>>>Because it's used to filter ap->*_mask and to allow LLDD's use the
>>>same constants on dev->*_mask's.
>>>
>>>Do you think LLDD's shouldn't access dev->*_mask's?
>>
>>When I spoke of "LLDD API", I largely meant the pio_mask/etc. in
>>ata_port_info. That's the easiest way to present such information to
>>driver maintainers.
>>
>>OTOH, at runtime ->dev_config() and friends should probably just
>>manipulate dev->xfer_mask.
>
>
> I see.
>
> So, ata_port_info uses pio/mwdma/udma_mask and ata_port and ata_device
> use single xfer_mask and all the masking constants are converted to
> mask single xfer_mask. Sounds good to you?
Well, if I read him correctly, Alan seems to have weighted in on the
side of pio/mwdma/udma_mask.
Maybe we could go with your original patches' direction for now, and
then move to a consolidated xfer_mask internally later.
Jeff
next prev parent reply other threads:[~2006-03-21 1:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-12 7:02 [PATCHSET] libata: implement per-dev xfer masks Tejun Heo
2006-03-12 7:02 ` [PATCH 1/4] libata: implement ata_unpack_xfermask() Tejun Heo
2006-03-13 8:23 ` Jeff Garzik
2006-03-12 7:02 ` [PATCH 3/4] libata: add per-dev pio/mwdma/udma_mask Tejun Heo
2006-03-13 8:29 ` Jeff Garzik
2006-03-13 9:30 ` Tejun Heo
2006-03-13 9:52 ` Jeff Garzik
2006-03-13 10:09 ` Tejun Heo
2006-03-13 10:13 ` Jeff Garzik
2006-03-13 10:24 ` Tejun Heo
2006-03-21 1:56 ` Jeff Garzik [this message]
2006-03-21 10:25 ` Alan Cox
2006-03-12 7:02 ` [PATCH 2/4] libata: implement ata_dev_init() Tejun Heo
2006-03-13 6:19 ` Tejun Heo
2006-03-13 8:26 ` Jeff Garzik
2006-03-13 9:25 ` Tejun Heo
2006-03-12 7:02 ` [PATCH 4/4] libata: make per-dev transfer mode limits per-dev Tejun Heo
2006-03-13 8:30 ` Jeff Garzik
2006-03-13 9:33 ` Tejun Heo
2006-03-12 13:37 ` [PATCHSET] libata: implement per-dev xfer masks Alan Cox
2006-03-13 6:12 ` Tejun Heo
2006-03-13 11:41 ` Alan Cox
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=441F5D57.4050906@pobox.com \
--to=jgarzik@pobox.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertcc@tw.ibm.com \
--cc=htejun@gmail.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).