From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH 2/2] hpt366: UltraDMA filtering for SATA cards
Date: Sat, 01 Sep 2007 18:36:33 +0400 [thread overview]
Message-ID: <46D978F1.7030903@ru.mvista.com> (raw)
In-Reply-To: <200708271922.35546.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz wrote:
>>>>The Marvell bridge chips used on HighPoint SATA cards do not seem to support
>>>>the UltraDMA modes 1, 2, and 3 (as well as any MWDMA modes), so the driver
>>>>needs to account for this in the udma_filter() method. In order to achieve
>>>>that, do the following changes:
>>>>- install the method for all chips, not only HPT36x/370 (improve code formatting
>>>> by killing an extra tabs while at it);
>>>>- add to the end of the 'switch' statement in hpt3xx_udma_filter() case for
>>>> HPT372[AN] and HPT374 chips upon which the SATA cards are based and check
>>>> there whether we're dealing with SATA drive (by looking at words 80 and 93
>>>> of the drive's identify data), reorder HPT370[A] cases for consistency...
>>>>Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>>[...]
>>>Also now that ->udma_filter is always present the initial hwif->ultra_mask
>> Aha, so this method's semantics intended to *completely override* the
>>ultra_mask field?! Wouldn't it be better to make the code behave more
>>consistent, i.e. in ide_get_mode_mask() do:
>> unsigned int mask = 0;
>>
>> switch(base) {
>> case XFER_UDMA_0:
>> if ((id->field_valid & 4) == 0)
>> break;
>>
>> if (hwif->udma_filter)
>> mask = hwif->udma_filter(drive);
>> else
>> mask = hwif->ultra_mask;
>>
>> mask &= id->dma_ultra;
>> if ((mask & 0x78) && (eighty_ninty_three(drive) == 0))
>> mask &= 0x07;
>> break;
>> case XFER_MW_DMA_0:
>> if ((id->field_valid & 2) == 0)
>> break;
>>
>> if (hwif->mdma_filter)
>> mask = hwif->mdma_filter(drive);
>> else
>> mask = hwif->mwdma_mask;
>> mask &= id->dma_mword;
>> break;
>>to avoid the further confusion? ;-)
> Fine with me but you forgot to attach a patch. ;)
That was only a trial ball. ;-)
> Bart
MBR, Sergei
prev parent reply other threads:[~2007-09-01 14:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-05 20:08 [PATCH 2/2] hpt366: UltraDMA filtering for SATA cards Sergei Shtylyov
2007-08-08 22:08 ` Bartlomiej Zolnierkiewicz
2007-08-10 18:12 ` Sergei Shtylyov
2007-08-10 21:16 ` Bartlomiej Zolnierkiewicz
2007-08-11 15:45 ` Sergei Shtylyov
2007-08-11 16:30 ` Bartlomiej Zolnierkiewicz
2007-08-11 18:59 ` Sergei Shtylyov
2007-08-18 19:18 ` Bartlomiej Zolnierkiewicz
2007-08-19 14:21 ` Sergei Shtylyov
2007-08-25 20:49 ` Sergei Shtylyov
2007-08-11 17:28 ` Sergei Shtylyov
2007-08-11 18:03 ` Bartlomiej Zolnierkiewicz
2007-08-11 19:23 ` Sergei Shtylyov
2007-08-25 17:13 ` Sergei Shtylyov
[not found] ` <200708271922.35546.bzolnier@gmail.com>
2007-09-01 14:36 ` Sergei Shtylyov [this message]
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=46D978F1.7030903@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=bzolnier@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).