From: Sergei Shtylyov <sshtylyov@mvista.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-ide <linux-ide@vger.kernel.org>,
Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: [PATCH 0/2] fix libata-sff and pata_cmd64x to not crash on boot on parisc
Date: Wed, 20 Apr 2011 18:54:41 +0400 [thread overview]
Message-ID: <4DAEF3B1.6020304@ru.mvista.com> (raw)
In-Reply-To: <1303309698.2587.10.camel@mulgrave.site>
Hello.
On 20-04-2011 18:28, James Bottomley wrote:
>>> + dev_printk(KERN_NOTICE,&pdev->dev, "Mobility Bridge detected, ignoring CNTRL port enable/disable\n");
>>> + /* 643 and 646 no UDMA, primary port always enabled */
>>> + if (port_ok&& id->driver_data> 1&& !(reg& CNTRL_PRIMARY)) {
This should probably be:
if (port_ok && !(id->driver_data == 0 || id->driver_data == 1 &&
pdev->revision < 3) && !(reg & CNTRL_PRIMARY)) {
>> PCI0646U and later revisions on PCI0646 do have the primary port enable
>> bit. The same about UltraDMA -- PCI0646U2 has it. Look at what cmd64x does in
>> cmd64x_init_one()...
> Where? All I see in drivers/ide/cmd64x.c is that it only ignores the
> primary for the id->driver_data == 0 case, which is what I originally
> coded.
Hm, are we looking at the same driver?
static const struct ide_port_info cmd64x_chipsets[] __devinitdata = {
{ /* 0: CMD643 */
.name = DRV_NAME,
.init_chipset = init_chipset_cmd64x,
.enablebits = {{0x00,0x00,0x00}, {0x51,0x08,0x08}},
.port_ops = &cmd64x_port_ops,
.host_flags = IDE_HFLAG_CLEAR_SIMPLEX |
IDE_HFLAG_ABUSE_PREFETCH |
IDE_HFLAG_SERIALIZE,
.pio_mask = ATA_PIO5,
.mwdma_mask = ATA_MWDMA2,
.udma_mask = 0x00, /* no udma */
},
{ /* 1: CMD646 */
.name = DRV_NAME,
.init_chipset = init_chipset_cmd64x,
.enablebits = {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
.port_ops = &cmd648_port_ops,
.host_flags = IDE_HFLAG_ABUSE_PREFETCH |
IDE_HFLAG_SERIALIZE,
.pio_mask = ATA_PIO5,
.mwdma_mask = ATA_MWDMA2,
.udma_mask = ATA_UDMA2,
},
{ /* 2: CMD648 */
.name = DRV_NAME,
.init_chipset = init_chipset_cmd64x,
.enablebits = {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
.port_ops = &cmd648_port_ops,
.host_flags = IDE_HFLAG_ABUSE_PREFETCH,
.pio_mask = ATA_PIO5,
.mwdma_mask = ATA_MWDMA2,
.udma_mask = ATA_UDMA4,
},
{ /* 3: CMD649 */
.name = DRV_NAME,
.init_chipset = init_chipset_cmd64x,
.enablebits = {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
.port_ops = &cmd648_port_ops,
.host_flags = IDE_HFLAG_ABUSE_PREFETCH,
.pio_mask = ATA_PIO5,
.mwdma_mask = ATA_MWDMA2,
.udma_mask = ATA_UDMA5,
}
};
static int __devinit cmd64x_init_one(struct pci_dev *dev, const struct
pci_device_id *id)
{
struct ide_port_info d;
u8 idx = id->driver_data;
d = cmd64x_chipsets[idx];
if (idx == 1) {
/*
* UltraDMA only supported on PCI646U and PCI646U2, which
* correspond to revisions 0x03, 0x05 and 0x07 respectively.
* Actually, although the CMD tech support people won't
* tell me the details, the 0x03 revision cannot support
* UDMA correctly without hardware modifications, and even
* then it only works with Quantum disks due to some
* hold time assumptions in the 646U part which are fixed
* in the 646U2.
*
* So we only do UltraDMA on revision 0x05 and 0x07 chipsets.
*/
if (dev->revision < 5) {
d.udma_mask = 0x00;
/*
* The original PCI0646 didn't have the primary
* channel enable bit, it appeared starting with
* PCI0646U (i.e. revision ID 3).
*/
if (dev->revision < 3) {
d.enablebits[0].reg = 0;
d.port_ops = &cmd64x_port_ops;
if (dev->revision == 1)
d.dma_ops = &cmd646_rev1_dma_ops;
}
}
}
return ide_pci_init_one(dev, &d, NULL);
}
static const struct pci_device_id cmd64x_pci_tbl[] = {
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_643), 0 },
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_646), 1 },
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_648), 2 },
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_649), 3 },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, cmd64x_pci_tbl);
"ïdx == 1" corresponds to PCI0646. See this "dev->revision < 3" check
(this is true for the original PCI0646), where it then zeroes the 'reg' field
of 'enablebits' to disable its checking?
> James
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sshtylyov@mvista.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-ide <linux-ide@vger.kernel.org>,
Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: [PATCH 0/2] fix libata-sff and pata_cmd64x to not crash on boot on parisc
Date: Wed, 20 Apr 2011 18:54:41 +0400 [thread overview]
Message-ID: <4DAEF3B1.6020304@ru.mvista.com> (raw)
In-Reply-To: <1303309698.2587.10.camel@mulgrave.site>
Hello.
On 20-04-2011 18:28, James Bottomley wrote:
>>> + dev_printk(KERN_NOTICE,&pdev->dev, "Mobility Bridge detected, ig=
noring CNTRL port enable/disable\n");
>>> + /* 643 and 646 no UDMA, primary port always enabled */
>>> + if (port_ok&& id->driver_data> 1&& !(reg& CNTRL_PRIMARY)) {
This should probably be:
if (port_ok && !(id->driver_data =3D=3D 0 || id->driver_data =3D=3D 1 =
&&
pdev->revision < 3) && !(reg & CNTRL_PRIMARY)) {
>> PCI0646U and later revisions on PCI0646 do have the primary por=
t enable
>> bit. The same about UltraDMA -- PCI0646U2 has it. Look at what cmd64=
x does in
>> cmd64x_init_one()...
> Where? All I see in drivers/ide/cmd64x.c is that it only ignores the
> primary for the id->driver_data =3D=3D 0 case, which is what I origin=
ally
> coded.
Hm, are we looking at the same driver?
static const struct ide_port_info cmd64x_chipsets[] __devinitdata =3D {
{ /* 0: CMD643 */
.name =3D DRV_NAME,
.init_chipset =3D init_chipset_cmd64x,
.enablebits =3D {{0x00,0x00,0x00}, {0x51,0x08,0x08}},
.port_ops =3D &cmd64x_port_ops,
.host_flags =3D IDE_HFLAG_CLEAR_SIMPLEX |
IDE_HFLAG_ABUSE_PREFETCH |
IDE_HFLAG_SERIALIZE,
.pio_mask =3D ATA_PIO5,
.mwdma_mask =3D ATA_MWDMA2,
.udma_mask =3D 0x00, /* no udma */
},
{ /* 1: CMD646 */
.name =3D DRV_NAME,
.init_chipset =3D init_chipset_cmd64x,
.enablebits =3D {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
.port_ops =3D &cmd648_port_ops,
.host_flags =3D IDE_HFLAG_ABUSE_PREFETCH |
IDE_HFLAG_SERIALIZE,
.pio_mask =3D ATA_PIO5,
.mwdma_mask =3D ATA_MWDMA2,
.udma_mask =3D ATA_UDMA2,
},
{ /* 2: CMD648 */
.name =3D DRV_NAME,
.init_chipset =3D init_chipset_cmd64x,
.enablebits =3D {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
.port_ops =3D &cmd648_port_ops,
.host_flags =3D IDE_HFLAG_ABUSE_PREFETCH,
.pio_mask =3D ATA_PIO5,
.mwdma_mask =3D ATA_MWDMA2,
.udma_mask =3D ATA_UDMA4,
},
{ /* 3: CMD649 */
.name =3D DRV_NAME,
.init_chipset =3D init_chipset_cmd64x,
.enablebits =3D {{0x51,0x04,0x04}, {0x51,0x08,0x08}},
.port_ops =3D &cmd648_port_ops,
.host_flags =3D IDE_HFLAG_ABUSE_PREFETCH,
.pio_mask =3D ATA_PIO5,
.mwdma_mask =3D ATA_MWDMA2,
.udma_mask =3D ATA_UDMA5,
}
};
static int __devinit cmd64x_init_one(struct pci_dev *dev, const struct=20
pci_device_id *id)
{
struct ide_port_info d;
u8 idx =3D id->driver_data;
d =3D cmd64x_chipsets[idx];
if (idx =3D=3D 1) {
/*
* UltraDMA only supported on PCI646U and PCI646U2, which
* correspond to revisions 0x03, 0x05 and 0x07 respectively.
* Actually, although the CMD tech support people won't
* tell me the details, the 0x03 revision cannot support
* UDMA correctly without hardware modifications, and even
* then it only works with Quantum disks due to some
* hold time assumptions in the 646U part which are fixed
* in the 646U2.
*
* So we only do UltraDMA on revision 0x05 and 0x07 chipsets.
*/
if (dev->revision < 5) {
d.udma_mask =3D 0x00;
/*
* The original PCI0646 didn't have the primary
* channel enable bit, it appeared starting with
* PCI0646U (i.e. revision ID 3).
*/
if (dev->revision < 3) {
d.enablebits[0].reg =3D 0;
d.port_ops =3D &cmd64x_port_ops;
if (dev->revision =3D=3D 1)
d.dma_ops =3D &cmd646_rev1_dma_ops;
}
}
}
return ide_pci_init_one(dev, &d, NULL);
}
static const struct pci_device_id cmd64x_pci_tbl[] =3D {
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_643), 0 },
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_646), 1 },
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_648), 2 },
{ PCI_VDEVICE(CMD, PCI_DEVICE_ID_CMD_649), 3 },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, cmd64x_pci_tbl);
"=C3=AFdx =3D=3D 1" corresponds to PCI0646. See this "dev->revision=
< 3" check=20
(this is true for the original PCI0646), where it then zeroes the 'reg'=
field=20
of 'enablebits' to disable its checking?
> James
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-04-20 14:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 18:42 [PATCH 0/2] fix libata-sff and pata_cmd64x to not crash on boot on parisc James Bottomley
2011-04-18 18:44 ` [PATCH 1/2] libata-sff: remove hardcoded requirement for two ports James Bottomley
2011-04-18 18:45 ` [PATCH 2/2] pata_cmd64x: fix crash on boot with disabled secondary port James Bottomley
2011-04-19 20:48 ` Sergei Shtylyov
2011-04-18 19:52 ` [PATCH 0/2] fix libata-sff and pata_cmd64x to not crash on boot on parisc Alan Cox
2011-04-18 20:08 ` James Bottomley
2011-04-18 20:14 ` David Miller
2011-04-18 21:09 ` Alan Cox
2011-04-18 20:50 ` James Bottomley
2011-04-18 21:20 ` Alan Cox
2011-04-19 13:54 ` James Bottomley
2011-04-19 14:36 ` Alan Cox
2011-04-19 15:02 ` James Bottomley
2011-04-19 15:58 ` Alan Cox
2011-04-19 20:59 ` Sergei Shtylyov
2011-04-19 21:19 ` Alan Cox
2011-04-19 21:22 ` Sergei Shtylyov
2011-04-19 21:28 ` Alan Cox
2011-04-19 23:11 ` James Bottomley
2011-04-20 9:35 ` Alan Cox
2011-04-20 10:04 ` Sergei Shtylyov
2011-04-20 14:28 ` James Bottomley
2011-04-20 14:52 ` James Bottomley
2011-04-20 14:54 ` Sergei Shtylyov [this message]
2011-04-20 14:54 ` Sergei Shtylyov
2011-04-20 14:56 ` Matthew Wilcox
2011-04-21 14:24 ` Jeff Garzik
2011-04-19 20:53 ` Sergei Shtylyov
-- strict thread matches above, loose matches on Subject: below --
2011-04-24 19:28 James Bottomley
2011-05-13 17:01 ` James Bottomley
2011-05-14 19:01 ` Jeff Garzik
2011-07-15 15:45 ` Sergei Shtylyov
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=4DAEF3B1.6020304@ru.mvista.com \
--to=sshtylyov@mvista.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=linux-parisc@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.