From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] IDE: Don't assume there are always two devices per bus
Date: Mon, 06 Sep 2010 08:45:46 +0200 [thread overview]
Message-ID: <4C848E1A.1070003@free.fr> (raw)
In-Reply-To: <20100906060557.793391506AA@gemini.denx.de>
Hi again Wolfgang,
Le 06/09/2010 08:05, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4C848200.7080401@free.fr> you wrote:
>>
>>> First, CONFIG_SYS_IDE_* is for "IDE" (aka "Integrated Drive
>>> Electronics"), now usually references as "Parallel ATA", as defined
>>> by the underlying AT Attachment (ATA) and AT Attachment Packet
>>> Interface (ATAPI) standards. It is my understanding that these
>>> standards allow for one or two devices on the bus. So if there was any
>>> CONFIG_SYS_IDE_MAXDEVICE_PER_BUS, it would have to be set to 2, which
>>> renders it useless.
>>
>> You're right, and actually this is an overlook on my part, as the
>> current set of port configs has _ATA_ in in addition to _IDE. Would the
>> name CONFIG_SYS_ATA_IDE_MAXDEVICEPERBUS make you be happier?
>
> No. See the AT Attachment (ATA) and AT Attachment Packe Interface
> (ATAPI) standards.
>
>>> happens if you want (or need) to setb the limit to 1, and I insert a
>>> PCI PATA controller card with 2 devices attached to a bus?
>>
>> Indeed; and additionally, who says you can only have two IDE busses? I
>> am facing the case right now with the MV88SX6081, which is an 8-ports
>> controller.
>
> But this is NOT an PATA controller, right?
Correct. It is a SATA controller with ATA, not PATA, compatibility.
>> I have thus started a patch where the CONFIG_SYS_ATA_IDE{0,1}_OFFSET are
>> replaced with a single one, CONFIG_SYS_ATA_IDE_OFFSETS, defined as an
>> open array of values, which allows as many ports as required. For e.g.
>> openrd_base, the config for ATA ports would change from:
>
> We should not use "IDE" code on non-IDE devices. If there are common
> code parts, these should be split off and generalized as needed
> (without reference to "ATA" or "IDE").
For IDE as such, I agree. However:
1) Some systems simply do not allow more that one IDE drive for
mechanical reasons. I suspect this is the reason behind the
CONFIG_SYS_IDE_MAXDEVICE option, which, as such, contradicts IDE since
it prevents cmd_ide to handle all 2*MAXBUS devices it could.
2) More generally, the "cmd_ide.c" actually uses ATA to communicate with
the devices it manages; thus I feel cmd_ide.c is rightly used when on
non-IDE-but-ATA-compatible devices, and that the issue is of naming only.
Besides, since cmd_ide's maximum bus feature is purely a design choice
not dictated by standards, I assume your rebuttal addresses maximum
devices per bus but not maximum busses, right? Would you agree at least
to the minimal idea of having more than two ATA-compatible busses
managed by cmd_ide?
>> /* OpenRD's two kirkwood busses are SATA: 1 device per bux max) */
>> #define CONFIG_SYS_ATA_IDE_CONFIG { \
>> { KW_SATA_PORT0_OFFSET, 1}, \
>> { KW_SATA_PORT1_OFFSET, 1} \
>
> No. It is inherently wrong to use "*IDE*" in combination with a SATA
> device.
How about this: we could remove "IDE" altogether from config options
which are not actually IDE related. This includes CONFIG_SYS_IDE_MAXBUS
which is neither IDE- or ATA-related but system-defined
We would then have:
#define CONFIG_SYS_ATA_CONFIG { \
>> { KW_SATA_PORT0_OFFSET, 1}, \
>> { KW_SATA_PORT1_OFFSET, 1} \
We would also remove ATA from non-ATA related symbols used in cmd_ide,
but so far the only one I see is CONFIG_SYS_IDE_MAXDEVICE, which is
purely a hack to accommodate system limitations; and in my proposal, it
would disappear from config files because it equals the sum of the "max
device" fields in the struct.
Is this proposal better?
Amicalement,
--
Albert.
next prev parent reply other threads:[~2010-09-06 6:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-14 10:41 [U-Boot] IDE_BUS unconditionally expects 2 devices per bus Rogan Dawes
2010-08-14 10:46 ` Rogan Dawes
2010-08-14 11:45 ` Albert ARIBAUD
2010-08-15 20:35 ` [U-Boot] [PATCH] IDE: Don't assume there are always two " Rogan Dawes
2010-08-15 21:30 ` Wolfgang Denk
2010-08-16 5:47 ` [U-Boot] [PATCH v2] " Rogan Dawes
2010-08-16 5:47 ` [U-Boot] [PATCH] " Rogan Dawes
2010-08-26 13:16 ` Rogan Dawes
2010-09-04 8:22 ` Albert ARIBAUD
2010-09-04 9:07 ` Albert ARIBAUD
2010-09-05 21:23 ` Rogan Dawes
2010-09-05 22:19 ` Wolfgang Denk
2010-09-06 5:54 ` Albert ARIBAUD
2010-09-06 6:03 ` Rogan Dawes
2010-09-06 6:05 ` Wolfgang Denk
2010-09-06 6:45 ` Albert ARIBAUD [this message]
2010-09-06 8:18 ` Wolfgang Denk
2010-09-06 11:32 ` Albert ARIBAUD
2010-09-06 12:50 ` Wolfgang Denk
2010-09-06 17:15 ` Albert ARIBAUD
2010-09-06 19:35 ` Wolfgang Denk
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=4C848E1A.1070003@free.fr \
--to=albert.aribaud@free.fr \
--cc=u-boot@lists.denx.de \
/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