linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch ide-dev 8/9] make ide_task_ioctl() use REQ_DRIVE_TASKFILE
Date: Tue, 1 Mar 2005 09:42:18 +0100	[thread overview]
Message-ID: <58cb370e05030100424d98c85c@mail.gmail.com> (raw)
In-Reply-To: <20050301042116.GA9001@htj.dyndns.org>

Hello,

On Tue, 1 Mar 2005 13:21:16 +0900, Tejun Heo <htejun@gmail.com> wrote:
> Hello, Bartlomiej.
> Hello, Jeff.
> 
> On Mon, Feb 28, 2005 at 05:14:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Monday 28 February 2005 16:24, Tejun Heo wrote:
> > > Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > Nope, it works just fine because REQ_DRIVE_TASK used only
> > > > no-data protocol, please check task_no_data_intr().
> > > >
> > >
> > >   Sorry, I missed that.  IDE really has a lot of ways to finish a
> > > command, doesn't it?  hdio.txt is gonna look ugly. :-)
> >
> > Yep but it was a lot more "fun" when there were three PIO codepaths. ;-)
> >
> > hdio.txt doesn't need to know about driver internals so no problem here.
> >
> 
>  I was talking about the TASKFILE ioctl IN register result.
> 
> > > >
> > > >> IMHO, this flag-to-get-result-registers thing is way too subtle.  How
> > > >>about keeping old behavior by just not copying out register outputs in
> > > >>ide_taskfile_ioctl() in applicable cases instead of not reading
> > > >>registers when ending commands?  That is, unless there's some
> > > >>noticeable performance impacts I'm not aware of.
> > > >
> > > >
> > > > This would miss whole point of not _reading_ these registers (IO is slow).
> > > > IMHO new flags denoting {in,out} registers should be added (to <linux/ata.h>
> > > > to share them with libata) so new code can be sane and old flags would map
> > > > on new flags when needed.
> > >
> > >   Please do it.
> > >
> > >   Or, let me know what you have in mind (added fields, flag names,
> > > etc...); then, I'll do it.  I think we also need to hear Jeff's opinion
> > > as things need to be added to ata.h.
> >
> > I was thinking about:
> >
> > * adding ATA_TFLAG_{IN,OUT}_xxx flags (there is enough free
> >   place for all flags in ->flags field of struct ata_taskfile)
> > * teaching flagged_taskfile() about these flags and mapping ->tf_out_flags
> >   onto ATA_TFLAG_OUT_xxx (simple mapping no need to move ->tf_out_flags
> >   to ide_taskfile_ioctl() etc. - no risk of breaking something)
> > * moving flagged taskfile writing to ide_tf_load_discrete() helper
> > * adding ide_tf_read_discrete() helper for use by ide_end_drive_cmd()
> >   and mapping ->tf_in_flags onto ATA_TFLAG_IN_xxx (ditto)
> >
> > If you like this plan feel free to implement it.
> > I'm also open for better ideas, comments etc.
> 
>  So, how do you like the following set of TFLAG's?
> 
> /* struct ata_taskfile flags */
> 
> /* The following six flags are used by IDE driver to control register IO. */
> ATA_TFLAG_OUT_LBA48             = (1 <<  0), /* enable 48-bit LBA and HOB out */

aggregate ATA_TFLAG_OUT_HOB_LBA{L,M,H}?

> ATA_TFLAG_OUT_ADDR              = (1 <<  1), /* enable out to nsect/lba regs */

not needed currently, add it {when,if} it is needed

> ATA_TFLAG_OUT_DEVICE            = (1 <<  2), /* enable out to device reg */
> ATA_TFLAG_IN_LBA48              = (1 <<  3), /* enable 48-bit LBA and HOB in */

aggregate ATA_TFLAG_IN_HOB_LBA_{L,M,H}?

> ATA_TFLAG_IN_ADDR               = (1 <<  4), /* enable in from nsect/lba regs */

not needed currently, add it {when,if} it is needed

> ATA_TFLAG_IN_DEVICE             = (1 <<  5), /* enable in from device reg */
> 
> /* These three aggregate flags are used by libata, as it doesn't
>    really need to optimize register INs */
> ATA_TFLAG_LBA48                 = (ATA_TFLAG_OUT_LBA48  | ATA_TFLAG_IN_LBA48),
> ATA_TFLAG_ISADDR                = (ATA_TFLAG_OUT_ADDR   | ATA_TFLAG_IN_ADDR),
> ATA_TFLAG_DEVICE                = (ATA_TFLAG_OUT_DEVICE | ATA_TFLAG_IN_DEVICE),
> 
> ATA_TFLAG_WRITE                 = (1 <<  6), /* data dir */
> 
> /* The rest of TFLAGs are only for implementing ioctl direct drive
>    commands in the IDE driver.  DO NOT use in other places. */
> ATA_TFLAG_IO_16BIT              = (1 << 11),
> 
> ATA_TFLAG_OUT_FEATURE           = (1 << 12),
> ATA_TFLAG_OUT_NSECT             = (1 << 13),
> ATA_TFLAG_OUT_LBAL              = (1 << 14),
> ATA_TFLAG_OUT_LBAM              = (1 << 15),
> ATA_TFLAG_OUT_LBAH              = (1 << 16),
> ATA_TFLAG_OUT_HOB_FEATURE       = (1 << 17),
> ATA_TFLAG_OUT_HOB_NSECT         = (1 << 18),
> ATA_TFLAG_OUT_HOB_LBAL          = (1 << 19),
> ATA_TFLAG_OUT_HOB_LBAM          = (1 << 20),
> ATA_TFLAG_OUT_HOB_LBAH          = (1 << 21),
> 
> ATA_TFLAG_IN_FEATURE            = (1 << 22),
> ATA_TFLAG_IN_NSECT              = (1 << 23),
> ATA_TFLAG_IN_LBAL               = (1 << 24),
> ATA_TFLAG_IN_LBAM               = (1 << 25),
> ATA_TFLAG_IN_LBAH               = (1 << 26),
> ATA_TFLAG_IN_HOB_FEATURE        = (1 << 27),
> ATA_TFLAG_IN_HOB_NSECT          = (1 << 28),
> ATA_TFLAG_IN_HOB_LBAL           = (1 << 29),
> ATA_TFLAG_IN_HOB_LBAM           = (1 << 30),
> ATA_TFLAG_IN_HOB_LBAH           = (1 << 31),

proposed changes will get rid of 4 bits

> ATA_TFLAG_OUT_MASK              = 0x007ff000,
> ATA_TFLAG_IN_MASK               = 0xffc00000,
> ATA_TFLAG_OUT_IN_MASK           = (ATA_TFLAG_OUT_MASK | ATA_TFLAG_IN_MASK),
> 
>  ATA_TFLAG_{OUT|IN}_{LBA48|ADDR|DEVICE} should provide enough
> granuality for fs/internal requests without much hassle, and
> individual IO/OUT flags will only be used to implement ioctls in
> separate IN/OUT functions, something like ide_{load|read}_ioctl_task().

They would be later used by IDE driver itself so names
like ide_discrete_tf_{load,read}() suits it better IMHO.

>  Would using more specific prefix for ioctl flags - like
> ATA_TFLAG_IOC_{IN|OUT}_* - be better?

Nope, they are not limited to ioctls by design.
 
>  libata will work as it works currently, but if optimizing out
> register INs can help, converting to use IN/OUT flags should be easy.
> 
>  Please let me know what you guys think.

It is fine with me.

Thanks,
Bartlomiej

  parent reply	other threads:[~2005-03-01  8:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-24 14:48 [patch ide-dev 8/9] make ide_task_ioctl() use REQ_DRIVE_TASKFILE Bartlomiej Zolnierkiewicz
2005-02-27  7:36 ` Tejun Heo
2005-02-27 16:31   ` Bartlomiej Zolnierkiewicz
2005-02-28 15:24     ` Tejun Heo
2005-02-28 16:14       ` Bartlomiej Zolnierkiewicz
2005-03-01  4:21         ` Tejun Heo
2005-03-01  5:29           ` Tejun Heo
2005-03-01  8:42           ` Bartlomiej Zolnierkiewicz [this message]
2005-03-01  9:29             ` Tejun Heo
2005-03-01  9:59               ` Bartlomiej Zolnierkiewicz
2005-03-02  6:08                 ` Jeff Garzik
2005-03-02 10:09                   ` Bartlomiej Zolnierkiewicz
2005-03-02 19:04                     ` Jeff Garzik
2005-03-02 14:20                   ` Mark Lord

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=58cb370e05030100424d98c85c@mail.gmail.com \
    --to=bzolnier@gmail.com \
    --cc=htejun@gmail.com \
    --cc=jgarzik@pobox.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 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).