All of lore.kernel.org
 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 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.