From: Shem Multinymous <multinymous@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
Jeff Garzik <jgarzik@pobox.com>, Rovert Love <rlove@rlove.org>,
Jens Axboe <axboe@suse.de>,
linux-ide@vger.kernel.org
Subject: Re: tp_smapi conflict with IDE, hdaps
Date: Tue, 13 Dec 2005 18:04:37 +0200 [thread overview]
Message-ID: <41840b750512130804s32fe543xa11933f681973281@mail.gmail.com> (raw)
In-Reply-To: <1134488305.11732.74.camel@localhost.localdomain>
Hi,
On 12/13/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Sounds like it needs someone with an ATA bus analyser, or of course
> someone from IBM to be helpful
(I wonder which is more implausible...)
> > > Trying to arbitrate libata access with unknown bios behaviour isn't going to have a
> > > sane resolution.
> >
> > Why? BTW, isn't this similar to the queue freeze functionality needed
> > by the disk park part of the ThinkPad HDAPS?
>
> What else does that code do, what else might it confuse, what rules and
> locking are hidden in the windows driver that are unknown. Want to risk
> everyones data for that ?
We already take that risk to some degree, since the SMAPI BIOS is also
invoked by the ACPI DSDT and by external events.
> HDAPS doesn't need it btw.
It's not implemented yet, but I gather it's necessary for preventing
the disk from spinning back up as the laptop slides off the table.
Maybe I missed some subsequent discussion?
> > We don't understand the controller interface sufficiently well to
> > fully abstract it (no specs, and the two conflicting drivers do things
> > somewhat differently), so for now the low-level driver may only handle
> > locking... Is there an easier way to just share a mutex?
>
> Yes but that isn't neccessarily the right thing to do. You want the
> abstraction for the resource ownership and expansion. Can you summarize
> the two drivers interaction with the ports ?
You write "command" values into IO ports 0x1610 and 0x161F and, in
some cases, read some results from ports 0x1610-0x161F. Throughout
that, you inspect various bits (whose meaning we don't understand) in
the status port 0x1604. The details of the commands, scheduling and
status bits differ between the drivers. I don't think a full-blown
ownership and expansion infrastructure is necessary, or even possible
without better understanding.
> One large scale example is the i2c bus code which has to deal with
> multiple devices on multiple busses all being used by multiple people at
> the same time.
>
> Another is I2O where the I2O core code owns the I2O controller and the
> detail for it and is used by various device drivers on top. That one is
> fairly high level however and not exactly minimal.
>
> It may well be that in your case the 'core' module can only identify the
> ports, claim them, release them on unload and provide 'lock' and
> 'unlock' functions and the base address.
Thanks for the pointers. I guess the minimal approach is probably
ideal here; are there any such dumb drivers lying around?
Shem
next prev parent reply other threads:[~2005-12-13 16:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-13 14:35 tp_smapi conflict with IDE, hdaps Shem Multinymous
2005-12-13 14:43 ` Shem Multinymous
2005-12-13 15:03 ` Alan Cox
2005-12-13 15:29 ` Shem Multinymous
2005-12-13 15:38 ` Alan Cox
2005-12-13 16:04 ` Shem Multinymous [this message]
2005-12-13 16:16 ` Alan Cox
2005-12-14 16:32 ` Shem Multinymous
2005-12-13 18:41 ` Shem Multinymous
2005-12-13 19:18 ` Alan Cox
2005-12-14 15:03 ` Shem Multinymous
2005-12-15 3:05 ` Mark Lord
2005-12-13 15:14 ` Robert Love
2005-12-13 15:43 ` Shem Multinymous
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=41840b750512130804s32fe543xa11933f681973281@mail.gmail.com \
--to=multinymous@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rlove@rlove.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.