All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 14/15] ide: rework the code for selecting the best DMA transfer mode
Date: Fri, 20 Apr 2007 22:00:27 +0400	[thread overview]
Message-ID: <4628FFBB.2090900@ru.mvista.com> (raw)
In-Reply-To: <4628D64B.7080500@ru.mvista.com>

Hello, I wrote:

>>>> Index: b/drivers/ide/pci/hpt366.c
>>>> ===================================================================
>>>> --- a/drivers/ide/pci/hpt366.c
>>>> +++ b/drivers/ide/pci/hpt366.c
>>>> @@ -513,43 +513,31 @@ static int check_in_drive_list(ide_drive
>>>>      return 0;
>>>>  }
>>>>  
>>>> -static u8 hpt3xx_ratemask(ide_drive_t *drive)
>>>> -{
>>>> -    struct hpt_info *info    = pci_get_drvdata(HWIF(drive)->pci_dev);
>>>> -    u8 mode            = info->max_mode;
>>>> -
>>>> -    if (!eighty_ninty_three(drive) && mode)
>>>> -        mode = min(mode, (u8)1);
>>>> -    return mode;
>>>> -}
>>>> -
>>>>  /*
>>>>   *    Note for the future; the SATA hpt37x we must set
>>>>   *    either PIO or UDMA modes 0,4,5
>>>>   */
>>>> - -static u8 hpt3xx_ratefilter(ide_drive_t *drive, u8 speed)
>>>> +
>>>> +static u8 hpt3xx_udma_filter(ide_drive_t *drive)
>>>>  {
>>>>      struct hpt_info *info    = pci_get_drvdata(HWIF(drive)->pci_dev);
>>>>      u8 chip_type        = info->chip_type;
>>>> -    u8 mode            = hpt3xx_ratemask(drive);
>>>> -
>>>> -    if (drive->media != ide_disk)
>>>> -        return min(speed, (u8)XFER_PIO_4);
>>>> +    u8 mode            = info->max_mode;
>>>> +    u8 mask;
>>>>  
>>>>      switch (mode) {
>>>>          case 0x04:
>>>> -            speed = min_t(u8, speed, XFER_UDMA_6);
>>>> +            mask = 0x7f;
>>>>              break;
>>>>          case 0x03:
>>>> -            speed = min_t(u8, speed, XFER_UDMA_5);
>>>> +            mask = 0x3f;
>>>>              if (chip_type >= HPT374)
>>>>                  break;
>>>>              if (!check_in_drive_list(drive, bad_ata100_5))
>>>>                  goto check_bad_ata33;
>>>>              /* fall thru */
>>>>          case 0x02:
>>>> -            speed = min_t(u8, speed, XFER_UDMA_4);
>>>> +            mask = 0x1f;
>>>>  
>>>>              /*
>>>>               * CHECK ME, Does this need to be changed to HPT374 ??
>>>> @@ -560,13 +548,13 @@ static u8 hpt3xx_ratefilter(ide_drive_t 
>>>>                  !check_in_drive_list(drive, bad_ata66_4))
>>>>                  goto check_bad_ata33;
>>>>  
>>>> -            speed = min_t(u8, speed, XFER_UDMA_3);

  Hm, found a buglet in my former filtering rewrite -- the condition in the preceding if stmt should be a reverse one, and speed limitation to XFER_UDMA_3 should have been left under it.  With the current code, XFER_UDMA_2 limitation wouldn't have been applied if the same drive is not in both 'bad_ata66_4' and 'bad_ata66_3' lists -- this, however, actually is not the case since WDC AC310200R drive is in both these lists (maybe I wrote it this way because of this fact :-).

>>>> +            mask = 0x0f;
>>>>              if (HPT366_ALLOW_ATA66_3 &&
>>>>                  !check_in_drive_list(drive, bad_ata66_3))
>>>>                  goto check_bad_ata33;
>>>>              /* fall thru */
>>>>          case 0x01:
>>>> -            speed = min_t(u8, speed, XFER_UDMA_2);
>>>> +            mask = 0x07;
>>>>  
>>>>          check_bad_ata33:
>>>>              if (chip_type >= HPT370A)

>>>   This case 0x01 will *never* be hit for HPT370 chip with the new 
>>> code, therefore the filter won't get applied.

>>   Oh, and for HPT36x chips used with 40c cable too (unless they're 
>> artificaially reduced to UltraDMA/33 by the driver #define's).

>   It will still get applied since the code always resorts to looking up 
> the 'bad_ata33' list for HPT36x/370.
> I've got a bit muddled in my own code -- not sure if it got much clearer 
> after I'd untangled hpt3xx_ratemask() / hpt3xx_ratefilter() puzzle. :-)

  Yeah, I'm definitely having trouble understanding my own code after some months have passed... :-/

MBR, Sergei


  reply	other threads:[~2007-04-20 17:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-03 13:53 [PATCH 11/15] ide: make ide_hwif_t.ide_dma_{host_off,off_quietly} void Bartlomiej Zolnierkiewicz
2007-02-03 13:53 ` [PATCH 12/15] ide: make ide_hwif_t.ide_dma_host_on void Bartlomiej Zolnierkiewicz
2007-02-19 22:20   ` Olaf Hering
2007-02-19 23:21     ` Bartlomiej Zolnierkiewicz
2007-02-03 13:53 ` [PATCH 13/15] ide: fix UDMA/MWDMA/SWDMA masks Bartlomiej Zolnierkiewicz
2007-02-03 13:53 ` [PATCH 14/15] ide: rework the code for selecting the best DMA transfer mode Bartlomiej Zolnierkiewicz
2007-04-19 19:31   ` Sergei Shtylyov
2007-04-19 19:41     ` Sergei Shtylyov
2007-04-19 19:46       ` Sergei Shtylyov
2007-04-20 15:03       ` Sergei Shtylyov
2007-04-20 18:00         ` Sergei Shtylyov [this message]
2007-04-23 22:25           ` Bartlomiej Zolnierkiewicz
  -- strict thread matches above, loose matches on Subject: below --
2007-01-19  0:30 [PATCH 0/15] IDE quilt tree updated Bartlomiej Zolnierkiewicz
2007-01-19  0:32 ` [PATCH 14/15] ide: rework the code for selecting the best DMA transfer mode Bartlomiej Zolnierkiewicz
2007-01-22 19:48   ` Sergei Shtylyov
     [not found]     ` <58cb370e0702021207o435f39cdsf3abb0d55829fc45@mail.gmail.com>
2007-02-02 23:57       ` Bartlomiej Zolnierkiewicz

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=4628FFBB.2090900@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=bzolnier@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.