Some IDE issues with 2.6.28 on PC-Engines ALIX2

Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Karl Auerbach]

I've found what I believe are some problems with the IDE drivers on the 
2.6.8 kernel on
the PC-Engines ALIX2 platform.

There are two points in particular:

1. The ide_generic driver no longer finds the IDE drive (an EXT3
formatted compact flash on an IDE channel on an AMD CS5536 controller)
unless the kernel is given the ide_generic.probe_mask=0x## command
line parameter.  (I'll get to the values of ## later.)

2. The cs5535 ide driver doesn't seem to be able to recognize the
newer CS5536 controller for IDE.

I will provide more details below.

I'd submit these directly into the bugzilla but as I'm not familar
with the process and conventions I thought I'd begin with this email.

Thanks,
                 --karl--
                 Karl Auerbach (Santa Cruz, CA)
                 karl@cavebear.com

=================================================

Here's the scripts/ver_linux output:

[root@board-1 linux-2.6.28]# sh scripts/ver_linux If some fields are
empty or look unusual you may have an old version.  Compare to the
current minimal requirements in Documentation/Changes.

Linux board-1.cavebear.com 2.6.28-ALIX2 #1 Fri Jan 2 16:58:36 PST 2009 
i586 unknown

Gnu C                  4.2.4
Gnu make               3.81
binutils               2.19
util-linux             fdformat: unrecognized option `--version'
BusyBox v1.13.1 (2009-01-02 17:00:22 PST) multi-call binary

Usage: fdformat [-n] DEVICE

Format floppy disk

Options:
         -n      Don't verify after format

mount                  (rw
(rw,errors=continue,data=ordered
(rw
(rw
(rw,size=1024k,mode=755
(rw
(rw,gid=5,mode=620
(rw
(rw,size=32768k
(ro,noatime,nodiratime,errors=continue,data=ordered
(rw,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nointr,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=192.203.17.130
module-init-tools      found
e2fsprogs              1.41.3
Linux C Library        2.6.1
Dynamic linker (ldd)   2.6.1
Procps                 `--version'
Kbd                    78:
Sh-utils               --v
Modules Loaded         ebtable_filter ebtables x_tables bridge stp llc 
geodewdt cs5535_gpio geode_rng

=================================================

I. The ide_generic issue:

[1.] One line summary of the problem:

ide_generic driver under 2.6.28 no longer finds IDE drives on
PC-Engines ALIX2.

[2.] Full description of the problem/report:

The PC-Engines ALIX2 platform uses an AMD Geode LX processor with the
AMD CS5536 companion chip for things like IDE support.  The IDE drive
is a compact flash.

On the 2.6.27.8 kernel the ide_generic driver found the IDE and
compact flash without the need for any kernel command line parameters.

On the 2.6.28 kernel the ide_generic driver no longer finds the IDE
drive unless a ide_generic.probe_mask=0x## command line parameter is
given to the kernel.

I've tried several values for ##, I have not yet found one that
exactly replicates the behaviour of the 2.6.27.8 kernel.

However, values 0x3f, 0x31, and 0x11 all seem to work, although the
last of these (0x11 has the closest behaviour to the 2.6.27.8 kernel.)

Here's the relevant kernel output when using the 0x11 value in the
following kernel command line.  (The 0x31 value gives the same
results.  The 0x3f value finds several more IDE items.)

Kernel command line: console=ttyS0,38400 root=/dev/hda2 
ramdisk_size=16384 initrd=/initrd.gz rw ide_generic.probe_mask=0x11 
BOOT_IMAGE=/linux

Uniform Multi-Platform E-IDE driver
ide_generic: enforcing probing of I/O ports upon user request
hda: TRANSCEND, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x1e0-0x1e7,0x3e6 on irq 8
ide2 at 0x160-0x167,0x366 on irq 12
ide-gd driver 1.18
hda: max request size: 128KiB
hda: 3915072 sectors (2004 MB) w/1KiB Cache, CHS=3884/16/63
  hda: hda1 hda2 hda3
Driver 'sd' needs updating - please use bus_type methods

When the ide_generic.probe_mask=0x11 is not given no ide items are
found under 2.6.28 (although they were found under 2.6.27.8)

[3.] Keywords (i.e., modules, networking, kernel):

ide_generic, ALIX2

[4.] Kernel version (from /proc/version):

2.6.28


[7.7.] Other information that might be relevant to the problem
        (please look in /proc and include all information that you
        think to be relevant):

I can provide kernel .config files if you want.

=================================================

II. The cs5536 controller issue.

[1.] One line summary of the problem:

The cs5535 ide driver doesn't seem to recognize the AMD CS5536
controller.

[2.] Full description of the problem/report

The old AMD Geode used the CS5535 companion chipset for several
purposes including IDE.

The newer AMD Geode LX uses the CS5536 companion chipset.

It is not clear that the cs5535 ide kernel driver is supposed to
handle the newer chipset.  But in any event, it seems that the cs5535
driver, when it is looking for the hardware, is not seeing anything it
recognizes.

There is some ambiguity created becaause at least one "cs5535" driver
works on the The CS5536: cs5535_gpio

This is not a particularly signifcant issue - the ide_generic driver
handles the CS5536 IDE just fine (modulo the command line issue I
reported above.)  But it would be nice if any ambiguity about what the
cs5535 driver supports and what it does not support were clarified.


	Thanks,
		--karl--

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Martin K. Petersen]

>>>>> "Karl" == Karl Auerbach <karl@iwl.com> writes:

Karl> 2. The cs5535 ide driver doesn't seem to be able to recognize the
Karl> newer CS5536 controller for IDE.

The IDE interface of the Geode CS5536 companion chip is a completely
different beast.  It's a more or less standard AMD 8111 PCI IDE device
with slightly different timings.  There's a dedicated driver called
pata_cs5536.c (CONFIG_PATA_CS5536).

The driver was developed on a Soekris net5501.  To my knowledge it's
working fine on ALIX boards.  If that's not the case there may be a
problem with the ALIX BIOS VSA PCI config space emulation.  In that case
you can load the driver with msr=1 to force it to program the IDE
function using machine specific registers instead of relying on PCI.

Let me know how it goes.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

> 2. The cs5535 ide driver doesn't seem to be able to recognize the
> newer CS5536 controller for IDE.

Switch to libata as most distributions have already done and enable the
pata_cs5536 driver, which is designed for this hardware.

Alan

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Karl Auerbach wrote:

> I've found what I believe are some problems with the IDE drivers on 
> the 2.6.8 kernel on
> the PC-Engines ALIX2 platform.
>
> There are two points in particular:
>
> 1. The ide_generic driver no longer finds the IDE drive (an EXT3
> formatted compact flash on an IDE channel on an AMD CS5536 controller)
> unless the kernel is given the ide_generic.probe_mask=0x## command
> line parameter.  (I'll get to the values of ## later.)

   The probing behavior was changes on purpose, IIRC.

> 2. The cs5535 ide driver doesn't seem to be able to recognize the
> newer CS5536 controller for IDE.

   No wonder, it's even impossible to determine CS5536 IDE controller's 
device ID from the datasheet; include/linux/pci_ids.h tells me that the 
device ID is 0x209A, so adding another ID to the 'cs5535' driver's ID 
table shouldn't be an issue -- if they are indeed compatible. Looking at 
the datasheets, they are not -- bad luck, we need a new driver... BTW, 
libata seems to already have support for this chipset.

> I will provide more details below.
>
> I'd submit these directly into the bugzilla but as I'm not familar
> with the process and conventions I thought I'd begin with this email.

   I don't think these are bugs.

> I. The ide_generic issue:
>
> [1.] One line summary of the problem:
>
> ide_generic driver under 2.6.28 no longer finds IDE drives on
> PC-Engines ALIX2.
>
> [2.] Full description of the problem/report:
>
> The PC-Engines ALIX2 platform uses an AMD Geode LX processor with the
> AMD CS5536 companion chip for things like IDE support.  The IDE drive
> is a compact flash.
>
> On the 2.6.27.8 kernel the ide_generic driver found the IDE and
> compact flash without the need for any kernel command line parameters.
>
> On the 2.6.28 kernel the ide_generic driver no longer finds the IDE
> drive unless a ide_generic.probe_mask=0x## command line parameter is
> given to the kernel.

   Because ide-generic now avoids IDE ports already known to belong to 
the PCI controllers.

> I've tried several values for ##, I have not yet found one that
> exactly replicates the behaviour of the 2.6.27.8 kernel.
>
> However, values 0x3f, 0x31, and 0x11 all seem to work, although the
> last of these (0x11 has the closest behaviour to the 2.6.27.8 kernel.)

   Hm, doesn't plain 1 also work?

> Here's the relevant kernel output when using the 0x11 value in the
> following kernel command line.  (The 0x31 value gives the same
> results.  The 0x3f value finds several more IDE items.)
>
> Kernel command line: console=ttyS0,38400 root=/dev/hda2 
> ramdisk_size=16384 initrd=/initrd.gz rw ide_generic.probe_mask=0x11 
> BOOT_IMAGE=/linux
>
> Uniform Multi-Platform E-IDE driver
> ide_generic: enforcing probing of I/O ports upon user request
> hda: TRANSCEND, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x1e0-0x1e7,0x3e6 on irq 8
> ide2 at 0x160-0x167,0x366 on irq 12

   But this rather matches 0x31 mask.

> ide-gd driver 1.18
> hda: max request size: 128KiB
> hda: 3915072 sectors (2004 MB) w/1KiB Cache, CHS=3884/16/63
>  hda: hda1 hda2 hda3
> Driver 'sd' needs updating - please use bus_type methods

   Hm, why are you using 'sd' driver at all?

> II. The cs5536 controller issue.
>
> [1.] One line summary of the problem:
>
> The cs5535 ide driver doesn't seem to recognize the AMD CS5536
> controller.

  And it shouldn't -- the controllers are incompatible.

> [2.] Full description of the problem/report
>
> The old AMD Geode used the CS5535 companion chipset for several
> purposes including IDE.
>
> The newer AMD Geode LX uses the CS5536 companion chipset.
>
> It is not clear that the cs5535 ide kernel driver is supposed to
> handle the newer chipset.  But in any event, it seems that the cs5535
> driver, when it is looking for the hardware, is not seeing anything it
> recognizes.
>
> There is some ambiguity created becaause at least one "cs5535" driver
> works on the The CS5536: cs5535_gpio

   That only means that *some* fucntins of CS5536 are compatible with 
CS5535.

> This is not a particularly signifcant issue - the ide_generic driver
> handles the CS5536 IDE just fine (modulo the command line issue I
> reported above.)  But it would be nice if any ambiguity about what the
> cs5535 driver supports and what it does not support were clarified.

   Hopefully, it's clarified now. :-)

>     Thanks,
>         --karl--

MBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Martin K. Petersen wrote:

>>>>>> "Karl" == Karl Auerbach <karl@iwl.com> writes:
>>>>>>             
>
> Karl> 2. The cs5535 ide driver doesn't seem to be able to recognize the
> Karl> newer CS5536 controller for IDE.
>
> The IDE interface of the Geode CS5536 companion chip is a completely
> different beast.  It's a more or less standard AMD 8111 PCI IDE device
> with slightly different timings.

   I'm not sure I uderstand the passage about "slightly different 
timings"...

> There's a dedicated driver called pata_cs5536.c (CONFIG_PATA_CS5536).
>   

   I must note thst using libata for driving (presumably PIO only) CF 
seems an overkill (if not a slowdown).

> The driver was developed on a Soekris net5501.  To my knowledge it's
> working fine on ALIX boards.  If that's not the case there may be a
> problem with the ALIX BIOS VSA PCI config space emulation.  In that case
> you can load the driver with msr=1 to force it to program the IDE
> function using machine specific registers instead of relying on PCI.
>   

   It's stange that the driver is using CPI config. space by default 
which not even documented in the datasheet. I guess the MSR accesses are 
also somewhat faster because one doesn't have to access the address/data 
register pair at ports 0xcf8/0xcfc...

MBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

> > The IDE interface of the Geode CS5536 companion chip is a completely
> > different beast.  It's a more or less standard AMD 8111 PCI IDE device
> > with slightly different timings.
> 
>    I'm not sure I uderstand the passage about "slightly different 
> timings"...

The timing values used are different to those on the AMD 8111 even though
the interface is similar.

>    It's stange that the driver is using CPI config. space by default 
> which not even documented in the datasheet. I guess the MSR accesses are 

The PCI configuration is the portable way to drive it.

> also somewhat faster because one doesn't have to access the address/data 
> register pair at ports 0xcf8/0xcfc...

This is a Geode. What makes you think there is even a PCI bus or that the
8111 interface isn't entirely a software construct. Geode PCI hardware
is mostly smoke and mirrors ;)

Alan

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Bartlomiej Zolnierkiewicz]

On Monday 05 January 2009, Sergei Shtylyov wrote:
> Hello.
> 
> Karl Auerbach wrote:
> 
> > I've found what I believe are some problems with the IDE drivers on 
> > the 2.6.8 kernel on
> > the PC-Engines ALIX2 platform.
> >
> > There are two points in particular:
> >
> > 1. The ide_generic driver no longer finds the IDE drive (an EXT3
> > formatted compact flash on an IDE channel on an AMD CS5536 controller)
> > unless the kernel is given the ide_generic.probe_mask=0x## command
> > line parameter.  (I'll get to the values of ## later.)
> 
>    The probing behavior was changes on purpose, IIRC.

Yes, sometimes people were (by accident) using ide_generic for controllers
that have designated PCI host drivers (which offer better support/performance
and know about such things like errata workarounds).  

[ In this particular case ide_pci_generic host driver with "all_generic_ide"
  parameter may be used if BIOS programmed controller correctly. ]

> > 2. The cs5535 ide driver doesn't seem to be able to recognize the
> > newer CS5536 controller for IDE.
> 
>    No wonder, it's even impossible to determine CS5536 IDE controller's 
> device ID from the datasheet; include/linux/pci_ids.h tells me that the 
> device ID is 0x209A, so adding another ID to the 'cs5535' driver's ID 
> table shouldn't be an issue -- if they are indeed compatible. Looking at 
> the datasheets, they are not -- bad luck, we need a new driver... BTW, 
> libata seems to already have support for this chipset.

Indeed...

Karl, care to give a try to the following patch (it is completely untested
so please backup your data first if necessary)?

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: add CS5536 host driver

This is a port of libata's pata_cs5536.c (written by Martin K. Petersen)
to IDE subsystem.


Changes done while at it:

* Reprogram PIO/MWDMA timings if needed before and after DMA transfer
  (chipset uses shared PIO/MWDMA timings).

* Fix cable detection to report 80-wires cable if BIOS set it for any
  device on a port (IDE core will do drive-side cable detection later).

* Don't disable UDMA while programming PIO timings.

* Simplify PCI/MSR support.


Pros of having IDE host driver in addition to libata's one:

* CS5536 is used in embedded applications and IDE is much lighter
  than SCSI+libata, the host driver itself is also a bit smaller:

   text    data     bss     dec     hex filename
   1237     500       4    1741     6cd drivers/ata/pata_cs5536.o
   1164     132       4    1300     514 drivers/ide/cs5536.o

* CS5536 is used mostly for driving CF cards and this allows use of
  IDE features which are unavailable under libata (32-bit I/O support,
  non-rotational media optimizations, etc).


Cc: Martin K. Petersen <mkp@mkp.net>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Karl Auerbach <karl@iwl.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ide/Kconfig  |   10 +
 drivers/ide/Makefile |    1 
 drivers/ide/cs5536.c |  303 +++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 314 insertions(+)

Index: b/drivers/ide/Kconfig
===================================================================
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -465,6 +465,16 @@ config BLK_DEV_CS5535
 
 	  It is safe to say Y to this question.
 
+config BLK_DEV_CS5536
+	tristate "CS5536 chipset support"
+	depends on X86 && !X86_64
+	select BLK_DEV_IDEDMA_PCI
+	help
+	  This option enables support for the AMD CS5536
+	  companion chip used with the Geode LX processor family.
+
+	  If unsure, say N.
+
 config BLK_DEV_HPT366
 	tristate "HPT36X/37X chipset support"
 	select BLK_DEV_IDEDMA_PCI
Index: b/drivers/ide/Makefile
===================================================================
--- a/drivers/ide/Makefile
+++ b/drivers/ide/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_BLK_DEV_CMD64X)		+= cmd64x.
 obj-$(CONFIG_BLK_DEV_CS5520)		+= cs5520.o
 obj-$(CONFIG_BLK_DEV_CS5530)		+= cs5530.o
 obj-$(CONFIG_BLK_DEV_CS5535)		+= cs5535.o
+obj-$(CONFIG_BLK_DEV_CS5536)		+= cs5536.o
 obj-$(CONFIG_BLK_DEV_SC1200)		+= sc1200.o
 obj-$(CONFIG_BLK_DEV_CY82C693)		+= cy82c693.o
 obj-$(CONFIG_BLK_DEV_DELKIN)		+= delkin_cb.o
Index: b/drivers/ide/cs5536.c
===================================================================
--- /dev/null
+++ b/drivers/ide/cs5536.c
@@ -0,0 +1,303 @@
+/*
+ * CS5536 PATA support
+ * (C) 2007 Martin K. Petersen <mkp@mkp.net>
+ * (C) 2009 Bartlomiej Zolnierkiewicz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * Documentation:
+ *	Available from AMD web site.
+ *
+ * The IDE timing registers for the CS5536 live in the Geode Machine
+ * Specific Register file and not PCI config space.  Most BIOSes
+ * virtualize the PCI registers so the chip looks like a standard IDE
+ * controller.  Unfortunately not all implementations get this right.
+ * In particular some have problems with unaligned accesses to the
+ * virtualized PCI registers.  This driver always does full dword
+ * writes to work around the issue.  Also, in case of a bad BIOS this
+ * driver can be loaded with the "msr=1" parameter which forces using
+ * the Machine Specific Registers to configure the device.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/init.h>
+#include <linux/ide.h>
+#include <asm/msr.h>
+
+#define DRV_NAME	"cs5536"
+
+enum {
+	MSR_IDE_CFG		= 0x51300010,
+	PCI_IDE_CFG		= 0x40,
+
+	CFG			= 0,
+	DTC			= 2,
+	CAST			= 3,
+	ETC			= 4,
+
+	IDE_CFG_CHANEN		= (1 << 1),
+	IDE_CFG_CABLE		= (1 << 17) | (1 << 16),
+
+	IDE_D0_SHIFT		= 24,
+	IDE_D1_SHIFT		= 16,
+	IDE_DRV_MASK		= 0xff,
+
+	IDE_CAST_D0_SHIFT	= 6,
+	IDE_CAST_D1_SHIFT	= 4,
+	IDE_CAST_DRV_MASK	= 0x3,
+
+	IDE_CAST_CMD_SHIFT	= 24,
+	IDE_CAST_CMD_MASK	= 0xff,
+};
+
+static int use_msr;
+
+static int cs5536_read(struct pci_dev *pdev, int reg, u32 *val)
+{
+	if (unlikely(use_msr)) {
+		u32 dummy;
+
+		rdmsr(MSR_IDE_CFG + reg, *val, dummy);
+		return 0;
+	}
+
+	return pci_read_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
+}
+
+static int cs5536_write(struct pci_dev *pdev, int reg, int val)
+{
+	if (unlikely(use_msr)) {
+		wrmsr(MSR_IDE_CFG + reg, val, 0);
+		return 0;
+	}
+
+	return pci_write_config_dword(pdev, PCI_IDE_CFG + reg * 4, val);
+}
+
+static void cs5536_program_dtc(ide_drive_t *drive, u8 tim)
+{
+	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
+	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
+	u32 dtc;
+
+	cs5536_read(pdev, DTC, &dtc);
+	dtc &= ~(IDE_DRV_MASK << dshift);
+	dtc |= tim << dshift;
+	cs5536_write(pdev, DTC, dtc);
+}
+
+/**
+ *	cs5536_cable_detect	-	detect cable type
+ *	@hwif: Port to detect on
+ *
+ *	Perform cable detection for ATA66 capable cable.
+ *
+ *	Returns a cable type.
+ */
+
+static u8 cs5536_cable_detect(ide_hwif_t *hwif)
+{
+	struct pci_dev *pdev = to_pci_dev(hwif->dev);
+	u32 cfg;
+
+	cs5536_read(pdev, CFG, &cfg);
+
+	if (cfg & IDE_CFG_CABLE)
+		return ATA_CBL_PATA80;
+	else
+		return ATA_CBL_PATA40;
+}
+
+/**
+ *	cs5536_set_pio_mode		-	PIO timing setup
+ *	@drive: ATA device
+ *	@pio: PIO mode number
+ */
+
+static void cs5536_set_pio_mode(ide_drive_t *drive, const u8 pio)
+{
+	static const u8 drv_timings[5] = {
+		0x98, 0x55, 0x32, 0x21, 0x20,
+	};
+
+	static const u8 addr_timings[5] = {
+		0x2, 0x1, 0x0, 0x0, 0x0,
+	};
+
+	static const u8 cmd_timings[5] = {
+		0x99, 0x92, 0x90, 0x22, 0x20,
+	};
+
+	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
+	ide_drive_t *pair = ide_get_pair_dev(drive);
+	int cshift = (drive->dn & 1) ? IDE_CAST_D1_SHIFT : IDE_CAST_D0_SHIFT;
+	u32 cast;
+	u8 cmd_pio = pio;
+
+	if (pair)
+		cmd_pio = min(pio, ide_get_best_pio_mode(pair, 255, 4));
+
+	drive->drive_data &= 0xff00;
+	drive->drive_data |= drv_timings[pio];
+
+	cs5536_program_dtc(drive, drv_timings[pio]);
+
+	cs5536_read(pdev, CAST, &cast);
+
+	cast &= ~(IDE_CAST_DRV_MASK << cshift);
+	cast |= addr_timings[pio] << cshift;
+
+	cast &= ~(IDE_CAST_CMD_MASK << IDE_CAST_CMD_SHIFT);
+	cast |= cmd_timings[cmd_pio] << IDE_CAST_CMD_SHIFT;
+
+	cs5536_write(pdev, CAST, cast);
+}
+
+/**
+ *	cs5536_set_dma_mode		-	DMA timing setup
+ *	@drive: ATA device
+ *	@mode: DMA mode
+ */
+
+static void cs5536_set_dma_mode(ide_drive_t *drive, const u8 mode)
+{
+	static const u8 udma_timings[6] = {
+		0xc2, 0xc1, 0xc0, 0xc4, 0xc5, 0xc6,
+	};
+
+	static const u8 mwdma_timings[3] = {
+		0x67, 0x21, 0x20,
+	};
+
+	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
+	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
+	u32 etc;
+
+	if (mode >= XFER_UDMA_0) {
+		cs5536_read(pdev, ETC, &etc);
+
+		etc &= ~(IDE_DRV_MASK << dshift);
+		etc |= udma_timings[mode - XFER_UDMA_0] << dshift;
+
+		cs5536_write(pdev, ETC, etc);
+	} else { /* MWDMA */
+		drive->drive_data &= 0xff;
+		drive->drive_data |= mwdma_timings[mode - XFER_MW_DMA_0] << 8;
+	}
+}
+
+static void cs5536_dma_start(ide_drive_t *drive)
+{
+	if (drive->current_speed < XFER_UDMA_0)
+		cs5536_program_dtc(drive, drive->drive_data >> 8);
+
+	ide_dma_start(drive);
+}
+
+static int cs5536_dma_end(ide_drive_t *drive)
+{
+	int ret = ide_dma_end(drive);
+
+	if (drive->current_speed < XFER_UDMA_0)
+		cs5536_program_dtc(drive, drive->drive_data & 0xff);
+
+	return ret;
+}
+
+static const struct ide_port_ops cs5536_port_ops = {
+	.set_pio_mode		= cs5536_set_pio_mode,
+	.set_dma_mode		= cs5536_set_dma_mode,
+	.cable_detect		= cs5536_cable_detect,
+};
+
+static const struct ide_dma_ops cs5536_dma_ops = {
+	.dma_host_set		= ide_dma_host_set,
+	.dma_setup		= ide_dma_setup,
+	.dma_exec_cmd		= ide_dma_exec_cmd,
+	.dma_start		= cs5536_dma_start,
+	.dma_end		= cs5536_dma_end,
+	.dma_test_irq		= ide_dma_test_irq,
+	.dma_lost_irq		= ide_dma_lost_irq,
+	.dma_timeout		= ide_dma_timeout,
+};
+
+static const struct ide_port_info cs5536_info = {
+	.name		= DRV_NAME,
+	.port_ops	= &cs5536_port_ops,
+	.dma_ops	= &cs5536_dma_ops,
+	.host_flags	= IDE_HFLAG_SINGLE,
+	.pio_mask	= ATA_PIO4,
+	.mwdma_mask	= ATA_MWDMA2,
+	.udma_mask	= ATA_UDMA5,
+};
+
+/**
+ *	cs5536_init_one
+ *	@dev: PCI device
+ *	@id: Entry in match table
+ */
+
+static int cs5536_init_one(struct pci_dev *dev, const struct pci_device_id *id)
+{
+	u32 cfg;
+
+	if (use_msr)
+		printk(KERN_ERR DRV_NAME ": Using MSR regs instead of PCI\n");
+
+	cs5536_read(dev, CFG, &cfg);
+
+	if ((cfg & IDE_CFG_CHANEN) == 0) {
+		printk(KERN_ERR DRV_NAME ": disabled by BIOS\n");
+		return -ENODEV;
+	}
+
+	return ide_pci_init_one(dev, &cs5536_info, NULL);
+}
+
+static const struct pci_device_id cs5536_pci_tbl[] = {
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_CS5536_IDE), },
+	{ },
+};
+
+static struct pci_driver cs5536_pci_driver = {
+	.name		= DRV_NAME,
+	.id_table	= cs5536_pci_tbl,
+	.probe		= cs5536_init_one,
+	.remove		= ide_pci_remove,
+	.suspend	= ide_pci_suspend,
+	.resume		= ide_pci_resume,
+};
+
+static int __init cs5536_init(void)
+{
+	return pci_register_driver(&cs5536_pci_driver);
+}
+
+static void __exit cs5536_exit(void)
+{
+	pci_unregister_driver(&cs5536_pci_driver);
+}
+
+MODULE_AUTHOR("Martin K. Petersen, Bartlomiej Zolnierkiewicz");
+MODULE_DESCRIPTION("low-level driver for the CS5536 IDE controller");
+MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(pci, cs5536_pci_tbl);
+
+module_param_named(msr, use_msr, int, 0644);
+MODULE_PARM_DESC(msr, "Force using MSR to configure IDE function (Default: 0)");
+
+module_init(cs5536_init);
+module_exit(cs5536_exit);

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

> * CS5536 is used mostly for driving CF cards and this allows use of
>   IDE features which are unavailable under libata (32-bit I/O support,
>   non-rotational media optimizations, etc).

Non rotational media handling is done by the block layer and so works for
everything. Just set the right queue according to the device policy you
want in hal/udev.

Alan

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Bartlomiej Zolnierkiewicz]

On Monday 05 January 2009, Alan Cox wrote:
> > * CS5536 is used mostly for driving CF cards and this allows use of
> >   IDE features which are unavailable under libata (32-bit I/O support,
> >   non-rotational media optimizations, etc).
> 
> Non rotational media handling is done by the block layer and so works for
> everything. Just set the right queue according to the device policy you
> want in hal/udev.

You seem to confuse no merges policy with non rotational media support.

Both are done by block layer.  The former is controlled by the user-space
while the latter is controlled by the block driver.

Thanks,
Bart

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

> Both are done by block layer.  The former is controlled by the user-space
> while the latter is controlled by the block driver.

And in the old IDE case erroneously set for any device reporting CFA via
the kernel. Queue flag management belongs in user space because its far
more complex than you seem to think to get it right.

Alan

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Bartlomiej Zolnierkiewicz]

On Monday 05 January 2009, Alan Cox wrote:
> > Both are done by block layer.  The former is controlled by the user-space
> > while the latter is controlled by the block driver.
> 
> And in the old IDE case erroneously set for any device reporting CFA via
> the kernel. Queue flag management belongs in user space because its far
> more complex than you seem to think to get it right.

Please stop playing straw man in almost every your mail.  Doing it once
in a while can be intriguing or even enjoyable but doing it on daily basis
kills any sensible debate...

There is nothing incorrect in setting non-rotational queue flag for CF
devices [1] and I wasn't suggesting where it should belong -- I was solely
describing how things look up currently.

[1] in fact some SSD devices present themselves as CF devices

Thanks,
Bart

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Alan Cox wrote:

>>>The IDE interface of the Geode CS5536 companion chip is a completely
>>>different beast.  It's a more or less standard AMD 8111 PCI IDE device
>>>with slightly different timings.

>>   I'm not sure I uderstand the passage about "slightly different 
>>timings"...

> The timing values used are different to those on the AMD 8111 even though
> the interface is similar.

    What do you mean by timing values anyway, clock counts or the register 
encoding itself?

>>   It's stange that the driver is using CPI config. space by default 
>>which not even documented in the datasheet. I guess the MSR accesses are 

> The PCI configuration is the portable way to drive it.

    Portable to what? As you have yorself noted below, this is Geode -- and I 
highly doubt that CS5536 will be used for anything else.

>>also somewhat faster because one doesn't have to access the address/data 
>>register pair at ports 0xcf8/0xcfc...

> This is a Geode.

    I know. :-)
    I have hacked on older Geode GX2 for some time back in 2004 (although not 
on something related to PCI); my "toy" board has RIP just recently.)

> What makes you think there is even a PCI bus 

    I sure know that it's not PCI (IIUC, it's the common tendency in the x86 
north-to-south-bridge busses has been emulating the PCI config. space with 
less and less PCI compatible "physical layer"). That does mean emulating PCI 
config. space mechanism #1 and Geode's not an exception here, see:

http://www.amd.com/files/connectivitysolutions/geode/geode_gx/32663C_lx_gx_pciconfig.pdf

> or that the 8111 interface isn't entirely a software construct.

    If that's the case (looks like so), it makes using it even appealing...

> Geode PCI hardware is mostly smoke and mirrors ;)

    When it comes to their internal controllers, yes (though e.g. their OHCI 
seem to have the real PCI config. space).

> Alan

WBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

> [1] in fact some SSD devices present themselves as CF devices

As do some rotating disks.

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

>     What do you mean by timing values anyway, clock counts or the register 
> encoding itself?

The counts, the encoding is the same.

> 
> >>   It's stange that the driver is using CPI config. space by default 
> >>which not even documented in the datasheet. I guess the MSR accesses are 
> 
> > The PCI configuration is the portable way to drive it.
> 
>     Portable to what? As you have yorself noted below, this is Geode -- and I 
> highly doubt that CS5536 will be used for anything else.

The Geode hardware and software interfaces are rather independant. The
hardware one may change in future product and the software one stay the
same (eg the way softvga does compared with touching the display
controllers on the older devices)

Alan

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Bartlomiej Zolnierkiewicz]

On Monday 05 January 2009, Alan Cox wrote:
> 
> > [1] in fact some SSD devices present themselves as CF devices
> 
> As do some rotating disks.

Hmm.  I now recall that Microdrives can indeed do this.

What a mess...  I'll remove CFA check for now.

Thanks,
Bart

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Martin K. Petersen]

>>>>> "Sergei" == Sergei Shtylyov <sshtylyov@ru.mvista.com> writes:

>> The driver was developed on a Soekris net5501.  To my knowledge it's
>> working fine on ALIX boards.  If that's not the case there may be a
>> problem with the ALIX BIOS VSA PCI config space emulation.  In that
>> case you can load the driver with msr=1 to force it to program the
>> IDE function using machine specific registers instead of relying on
>> PCI.
>> 

Sergei> It's stange that the driver is using CPI config. space by
Sergei> default which not even documented in the datasheet.

Using PCI config space was explicitly requested by AMD for the reasons
Alan pointed out.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

>>> 2. The cs5535 ide driver doesn't seem to be able to recognize the
>>> newer CS5536 controller for IDE.
>>>       
>>    No wonder, it's even impossible to determine CS5536 IDE controller's 
>> device ID from the datasheet; include/linux/pci_ids.h tells me that the 
>> device ID is 0x209A, so adding another ID to the 'cs5535' driver's ID 
>> table shouldn't be an issue -- if they are indeed compatible. Looking at 
>> the datasheets, they are not -- bad luck, we need a new driver... BTW, 
>> libata seems to already have support for this chipset.
>>     
>
> Indeed...
>
> Karl, care to give a try to the following patch (it is completely untested
> so please backup your data first if necessary)?
>
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] ide: add CS5536 host driver
>
> This is a port of libata's pata_cs5536.c (written by Martin K. Petersen)
> to IDE subsystem.
>
> Changes done while at it:
>
> * Reprogram PIO/MWDMA timings if needed before and after DMA transfer
>   (chipset uses shared PIO/MWDMA timings).
>   
> * Fix cable detection to report 80-wires cable if BIOS set it for any
>   device on a port (IDE core will do drive-side cable detection later).
>   

   The original pata_cs5536 cable detection is indeed somewhat bogus...

> * CS5536 is used mostly for driving CF cards and this allows use of
>   

   I woulnd't be so sure -- but anyway, I mostly see the development 
boards... :-)

> Cc: Martin K. Petersen <mkp@mkp.net>
> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Cc: Karl Auerbach <karl@iwl.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
>   

   Looks good but needs some polishing...

> Index: b/drivers/ide/Kconfig
> ===================================================================
> --- a/drivers/ide/Kconfig
> +++ b/drivers/ide/Kconfig
> @@ -465,6 +465,16 @@ config BLK_DEV_CS5535
>  
>  	  It is safe to say Y to this question.
>  
> +config BLK_DEV_CS5536
> +	tristate "CS5536 chipset support"
> +	depends on X86 && !X86_64
>   

   Why not just depend on X86_32?

> Index: b/drivers/ide/cs5536.c
> ===================================================================
> --- /dev/null
> +++ b/drivers/ide/cs5536.c
> @@ -0,0 +1,303 @@
>   
[...]
> + * The IDE timing registers for the CS5536 live in the Geode Machine
> + * Specific Register file and not PCI config space.  Most BIOSes
> + * virtualize the PCI registers so the chip looks like a standard IDE
> + * controller.  Unfortunately not all implementations get this right.
> + * In particular some have problems with unaligned accesses to the
>   

   I'd say that people doing unaligned accesses are just looking for 
trouble... :-)

> +enum {
> +	MSR_IDE_CFG		= 0x51300010,
> +	PCI_IDE_CFG		= 0x40,
> +
> +	CFG			= 0,
> +	DTC			= 2,
> +	CAST			= 3,
> +	ETC			= 4,
> +
> +	IDE_CFG_CHANEN		= (1 << 1),
> +	IDE_CFG_CABLE		= (1 << 17) | (1 << 16),
> +
> +	IDE_D0_SHIFT		= 24,
> +	IDE_D1_SHIFT		= 16,
> +	IDE_DRV_MASK		= 0xff,
> +
> +	IDE_CAST_D0_SHIFT	= 6,
> +	IDE_CAST_D1_SHIFT	= 4,
> +	IDE_CAST_DRV_MASK	= 0x3,
> +
> +	IDE_CAST_CMD_SHIFT	= 24,
> +	IDE_CAST_CMD_MASK	= 0xff,
> +};
>   

   Declaring a lot of semi-related constants is not what enum was 
intended for I think...

> +static void cs5536_program_dtc(ide_drive_t *drive, u8 tim)
> +{
> +	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
> +	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
>   

   Masking with 1 is pointless (though harmless) for this single-channel 
controller.

> +/**
> + *	cs5536_set_pio_mode		-	PIO timing setup
> + *	@drive: ATA device
> + *	@pio: PIO mode number
> + */
> +
> +static void cs5536_set_pio_mode(ide_drive_t *drive, const u8 pio)
> +{
> +	static const u8 drv_timings[5] = {
> +		0x98, 0x55, 0x32, 0x21, 0x20,
> +	};
> +
> +	static const u8 addr_timings[5] = {
> +		0x2, 0x1, 0x0, 0x0, 0x0,
> +	};
> +
> +	static const u8 cmd_timings[5] = {
> +		0x99, 0x92, 0x90, 0x22, 0x20,
> +	};
> +
> +	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
> +	ide_drive_t *pair = ide_get_pair_dev(drive);
> +	int cshift = (drive->dn & 1) ? IDE_CAST_D1_SHIFT : IDE_CAST_D0_SHIFT;
>   

   Same comment...

> +	u32 cast;
> +	u8 cmd_pio = pio;
> +
> +	if (pair)
> +		cmd_pio = min(pio, ide_get_best_pio_mode(pair, 255, 4));
> +
> +	drive->drive_data &= 0xff00;

   IDE_DRV_MASK << 8?

> +/**
> + *	cs5536_set_dma_mode		-	DMA timing setup
> + *	@drive: ATA device
> + *	@mode: DMA mode
> + */
> +
> +static void cs5536_set_dma_mode(ide_drive_t *drive, const u8 mode)
> +{
> +	static const u8 udma_timings[6] = {
> +		0xc2, 0xc1, 0xc0, 0xc4, 0xc5, 0xc6,
> +	};
> +
> +	static const u8 mwdma_timings[3] = {
> +		0x67, 0x21, 0x20,
> +	};
> +
> +	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
> +	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
> +	u32 etc;
> +
> +	if (mode >= XFER_UDMA_0) {
> +		cs5536_read(pdev, ETC, &etc);
> +
> +		etc &= ~(IDE_DRV_MASK << dshift);
> +		etc |= udma_timings[mode - XFER_UDMA_0] << dshift;
> +
> +		cs5536_write(pdev, ETC, etc);
> +	} else { /* MWDMA */
> +		drive->drive_data &= 0xff;
>   

   IDE_DRV_MASK?

> +		drive->drive_data |= mwdma_timings[mode - XFER_MW_DMA_0] << 8;
>   

   How about disabling UltraDMA mode? While not an issue in the original 
driver with the set_{dma|pio}mode() method call order strictly 
determined and the latter method disabling UltraDMA, here this becames 
an issue...

> +static void cs5536_dma_start(ide_drive_t *drive)
> +{
> +	if (drive->current_speed < XFER_UDMA_0)
> +		cs5536_program_dtc(drive, drive->drive_data >> 8);
>   

   Worth comparing the values as PIO4 and MWDMA2 timings exactly 
correspond. Hm, PIO3 and MWDMA1 too...

> +/**
> + *	cs5536_init_one
> + *	@dev: PCI device
> + *	@id: Entry in match table
> + */
> +
> +static int cs5536_init_one(struct pci_dev *dev, const struct pci_device_id *id)
> +{
> +	u32 cfg;
> +
> +	if (use_msr)
> +		printk(KERN_ERR DRV_NAME ": Using MSR regs instead of PCI\n");
>   

   Why KERN_ERR? :-O

> +	cs5536_read(dev, CFG, &cfg);
> +
> +	if ((cfg & IDE_CFG_CHANEN) == 0) {
> +		printk(KERN_ERR DRV_NAME ": disabled by BIOS\n");
> +		return -ENODEV;
>   

   Eh, why not do it via the usual .enablebits mechanism?

MBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Karl Auerbach]

Alan Cox wrote:
>> 2. The cs5535 ide driver doesn't seem to be able to recognize the
>> newer CS5536 controller for IDE.
> 
> Switch to libata as most distributions have already done and enable the
> pata_cs5536 driver, which is designed for this hardware.

Thanks for the suggestion - It made a *big* difference.

Here's a couple of timings (sequential reads from the CF) that show the difference in 
performance.  I didn't do writes because I'm never sure what various CF's do inside and 
don't have confidence that seemingly similar CF writes have consistent times.

Using the generic IDE driver:

[root@board-1 /root]# time dd if=/dev/hda2 of=/dev/null bs=512
3572352+0 records in
3572352+0 records out
real      16m 18.64s
user      0m 0.76s
sys       1m 28.08s

Using the PATA CS5536 driver:

[root@board-1 /root]# time dd if=/dev/sda2 of=/dev/null bs=512
3572352+0 records in
3572352+0 records out
real    1m 11.41s
user    0m 0.47s
sys     0m 3.56s

In other words, on sequential reads, I'm seeing a roughly 13x fold improvement in clock 
time and an 11x improvement in sys+user cpu.

[It also seemed to fix another weird thing that started with 2.6.28, the disappearance of 
the stdout from linuxrc and rc.sysinit - the kernel messages still hit the console but the 
stuff from those two startup scripts went into never never land (even though, as apparent 
from their side effects, they still executed properly.)]

I guess I now need to go through my system and make sure that any hard coded "hda" are 
changed to "sda".

As for the other issues mentioned during this very helpful discussion, of which I 
comprehended about 50%:

Do folks still want me to try that patch?  (Now that the problem I've been having seems 
fixed, and being lazy by nature, I'll do it if it is helpful but otherwise I'd prefer to 
skip it.)

As for the question of why I have the SD driver - The ALIX2 boards (which, by the way are 
Geode LX, not the older Geode) has USB and I want to sometimes plug external USB drives 
into 'em.  I thought that the SD driver is needed for that, am I in error?

By-the-way, I'm happy (modulo my previously mentioned lazy nature) to run tests on ALIX2 
and ALIX3 boards should anyone need it.

	Thanks,
		--karl--
		Karl Auerbach
		Santa Cruz, CA
		http://www.cavebear.com/

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

> As for the question of why I have the SD driver - The ALIX2 boards (which, by the way are 
> Geode LX, not the older Geode) has USB and I want to sometimes plug external USB drives 
> into 'em.  I thought that the SD driver is needed for that, am I in error?

usb-storage + sd (as in scsi-disk not SDcard)

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Karl Auerbach wrote:

>>> 2. The cs5535 ide driver doesn't seem to be able to recognize the
>>> newer CS5536 controller for IDE.
>>
>> Switch to libata as most distributions have already done and enable the
>> pata_cs5536 driver, which is designed for this hardware.
>
> Thanks for the suggestion - It made a *big* difference.
>
> Here's a couple of timings (sequential reads from the CF) that show 
> the difference in performance.  I didn't do writes because I'm never 
> sure what various CF's do inside and don't have confidence that 
> seemingly similar CF writes have consistent times.
>
> Using the generic IDE driver:

   It was a total mistake from the very start that you used ide-generic 
driver and you should really have used ide-pci-generic.

> [root@board-1 /root]# time dd if=/dev/hda2 of=/dev/null bs=512
> 3572352+0 records in
> 3572352+0 records out
> real      16m 18.64s
> user      0m 0.76s
> sys       1m 28.08s
>
> Using the PATA CS5536 driver:
>
> [root@board-1 /root]# time dd if=/dev/sda2 of=/dev/null bs=512
> 3572352+0 records in
> 3572352+0 records out
> real    1m 11.41s
> user    0m 0.47s
> sys     0m 3.56s

   Hm, looks like your CF drive is rather advanced and might be 
supporting UltraDMA (and your CF slot supports DMA). Care to post the 
output of 'hdparm -i /dev/hda'?

> Do folks still want me to try that patch?  (Now that the problem I've 
> been having seems fixed, and being lazy by nature, I'll do it if it is 
> helpful but otherwise I'd prefer to skip it.)

   Of course, it'll be helpful.

> As for the question of why I have the SD driver - The ALIX2 boards 
> (which, by the way are Geode LX, not the older Geode)

   I didn't doubt it. CS5536 isn't used with LX it seems...

> has USB and I want to sometimes plug external USB drives into 'em.  I 
> thought that the SD driver is needed for that, am I in error?

   No. That explained it.

> By-the-way, I'm happy (modulo my previously mentioned lazy nature) to 
> run tests on ALIX2 and ALIX3 boards should anyone need it.

   Judging on what you have posted, IDE driver would not probably give 
any speed improvement, only soewhat lesser memory footprint...

MBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Alan Cox]

>    Judging on what you have posted, IDE driver would not probably give 
> any speed improvement, only soewhat lesser memory footprint...

Except he is also using USB storage so the shared stack with the libata
code is already loaded ...

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Bartlomiej Zolnierkiewicz]

On Tuesday 06 January 2009, Alan Cox wrote:
> >    Judging on what you have posted, IDE driver would not probably give 
> > any speed improvement, only soewhat lesser memory footprint...
> 
> Except he is also using USB storage so the shared stack with the libata
> code is already loaded ...

Doesn't really matter because libata itself is quite heavy:

$ size drivers/ata/built-in.o drivers/ide/built-in.o
   text    data     bss     dec     hex filename
  84100    6584    4196   94880   172a0 drivers/ata/built-in.o
  50198    1032     240   51470    c90e drivers/ide/built-in.o

[ I'm pretty sure that runtime memory footprint is also lower for IDE. ]

Possible additional gains if usb-storage wouldn't be needed:

$ size drivers/scsi/built-in.o

   text    data     bss     dec     hex filename
  61136    4660     532   66328   10318 drivers/scsi/built-in.o

This is with Linus' tree from today plus "IDE updates part 3" pull request
posted today + CS5536 IDE host driver.  Enabled config options:

* libata

CONFIG_ATA=y
CONFIG_ATA_ACPI=y
CONFIG_ATA_SFF=y
CONFIG_PATA_CS5536=y

* IDE

CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
CONFIG_BLK_DEV_IDEACPI=y
CONFIG_IDE_TASK_IOCTL=y
CONFIG_BLK_DEV_IDEDMA_SFF=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_CS5536=y
CONFIG_BLK_DEV_IDEDMA=y

* SCSI

CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_WAIT_SCAN=m

--
Thanks,
Bart

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday 05 January 2009, Sergei Shtylyov wrote:
> Hello.
> 
> Bartlomiej Zolnierkiewicz wrote:
> 
> >>> 2. The cs5535 ide driver doesn't seem to be able to recognize the
> >>> newer CS5536 controller for IDE.
> >>>       
> >>    No wonder, it's even impossible to determine CS5536 IDE controller's 
> >> device ID from the datasheet; include/linux/pci_ids.h tells me that the 
> >> device ID is 0x209A, so adding another ID to the 'cs5535' driver's ID 
> >> table shouldn't be an issue -- if they are indeed compatible. Looking at 
> >> the datasheets, they are not -- bad luck, we need a new driver... BTW, 
> >> libata seems to already have support for this chipset.
> >>     
> >
> > Indeed...
> >
> > Karl, care to give a try to the following patch (it is completely untested
> > so please backup your data first if necessary)?
> >
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] ide: add CS5536 host driver
> >
> > This is a port of libata's pata_cs5536.c (written by Martin K. Petersen)
> > to IDE subsystem.
> >
> > Changes done while at it:
> >
> > * Reprogram PIO/MWDMA timings if needed before and after DMA transfer
> >   (chipset uses shared PIO/MWDMA timings).
> >   
> > * Fix cable detection to report 80-wires cable if BIOS set it for any
> >   device on a port (IDE core will do drive-side cable detection later).
> >   
> 
>    The original pata_cs5536 cable detection is indeed somewhat bogus...
> 
> > * CS5536 is used mostly for driving CF cards and this allows use of
> >   
> 
>    I woulnd't be so sure -- but anyway, I mostly see the development 
> boards... :-)

I cleaned patch description a bit based on your and Alan's concerns.
 
> > Cc: Martin K. Petersen <mkp@mkp.net>
> > Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> > Cc: Karl Auerbach <karl@iwl.com>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> >   
> 
>    Looks good but needs some polishing...
> 
> > Index: b/drivers/ide/Kconfig
> > ===================================================================
> > --- a/drivers/ide/Kconfig
> > +++ b/drivers/ide/Kconfig
> > @@ -465,6 +465,16 @@ config BLK_DEV_CS5535
> >  
> >  	  It is safe to say Y to this question.
> >  
> > +config BLK_DEV_CS5536
> > +	tristate "CS5536 chipset support"
> > +	depends on X86 && !X86_64
> >   
> 
>    Why not just depend on X86_32?

Fixed (it could be that original driver predated x86 merge).

> > Index: b/drivers/ide/cs5536.c
> > ===================================================================
> > --- /dev/null
> > +++ b/drivers/ide/cs5536.c
> > @@ -0,0 +1,303 @@
> >   
> [...]
> > + * The IDE timing registers for the CS5536 live in the Geode Machine
> > + * Specific Register file and not PCI config space.  Most BIOSes
> > + * virtualize the PCI registers so the chip looks like a standard IDE
> > + * controller.  Unfortunately not all implementations get this right.
> > + * In particular some have problems with unaligned accesses to the
> >   
> 
>    I'd say that people doing unaligned accesses are just looking for 
> trouble... :-)
> 
> > +enum {
> > +	MSR_IDE_CFG		= 0x51300010,
> > +	PCI_IDE_CFG		= 0x40,
> > +
> > +	CFG			= 0,
> > +	DTC			= 2,
> > +	CAST			= 3,
> > +	ETC			= 4,
> > +
> > +	IDE_CFG_CHANEN		= (1 << 1),
> > +	IDE_CFG_CABLE		= (1 << 17) | (1 << 16),
> > +
> > +	IDE_D0_SHIFT		= 24,
> > +	IDE_D1_SHIFT		= 16,
> > +	IDE_DRV_MASK		= 0xff,
> > +
> > +	IDE_CAST_D0_SHIFT	= 6,
> > +	IDE_CAST_D1_SHIFT	= 4,
> > +	IDE_CAST_DRV_MASK	= 0x3,
> > +
> > +	IDE_CAST_CMD_SHIFT	= 24,
> > +	IDE_CAST_CMD_MASK	= 0xff,
> > +};
> >   
> 
>    Declaring a lot of semi-related constants is not what enum was 
> intended for I think...

Don't know about that but it is still better than using defines.

> > +static void cs5536_program_dtc(ide_drive_t *drive, u8 tim)
> > +{
> > +	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
> > +	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
> >   
> 
>    Masking with 1 is pointless (though harmless) for this single-channel 
> controller.

I prefer not to do such micro-optimizations (the gain of doing it for
whole driver is only 20 bytes) as this keeps code consistent with other
drivers and results in one gotcha less if somebody decides to use this
particular driver as a base for a new one.

> > +/**
> > + *	cs5536_set_pio_mode		-	PIO timing setup
> > + *	@drive: ATA device
> > + *	@pio: PIO mode number
> > + */
> > +
> > +static void cs5536_set_pio_mode(ide_drive_t *drive, const u8 pio)
> > +{
> > +	static const u8 drv_timings[5] = {
> > +		0x98, 0x55, 0x32, 0x21, 0x20,
> > +	};
> > +
> > +	static const u8 addr_timings[5] = {
> > +		0x2, 0x1, 0x0, 0x0, 0x0,
> > +	};
> > +
> > +	static const u8 cmd_timings[5] = {
> > +		0x99, 0x92, 0x90, 0x22, 0x20,
> > +	};
> > +
> > +	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
> > +	ide_drive_t *pair = ide_get_pair_dev(drive);
> > +	int cshift = (drive->dn & 1) ? IDE_CAST_D1_SHIFT : IDE_CAST_D0_SHIFT;
> >   
> 
>    Same comment...
> 
> > +	u32 cast;
> > +	u8 cmd_pio = pio;
> > +
> > +	if (pair)
> > +		cmd_pio = min(pio, ide_get_best_pio_mode(pair, 255, 4));
> > +
> > +	drive->drive_data &= 0xff00;
> 
>    IDE_DRV_MASK << 8?

Fixed.

> > +/**
> > + *	cs5536_set_dma_mode		-	DMA timing setup
> > + *	@drive: ATA device
> > + *	@mode: DMA mode
> > + */
> > +
> > +static void cs5536_set_dma_mode(ide_drive_t *drive, const u8 mode)
> > +{
> > +	static const u8 udma_timings[6] = {
> > +		0xc2, 0xc1, 0xc0, 0xc4, 0xc5, 0xc6,
> > +	};
> > +
> > +	static const u8 mwdma_timings[3] = {
> > +		0x67, 0x21, 0x20,
> > +	};
> > +
> > +	struct pci_dev *pdev = to_pci_dev(drive->hwif->dev);
> > +	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
> > +	u32 etc;
> > +
> > +	if (mode >= XFER_UDMA_0) {
> > +		cs5536_read(pdev, ETC, &etc);
> > +
> > +		etc &= ~(IDE_DRV_MASK << dshift);
> > +		etc |= udma_timings[mode - XFER_UDMA_0] << dshift;
> > +
> > +		cs5536_write(pdev, ETC, etc);
> > +	} else { /* MWDMA */
> > +		drive->drive_data &= 0xff;
> >   
> 
>    IDE_DRV_MASK?

Fixed.

> > +		drive->drive_data |= mwdma_timings[mode - XFER_MW_DMA_0] << 8;
> >   
> 
>    How about disabling UltraDMA mode? While not an issue in the original 
> driver with the set_{dma|pio}mode() method call order strictly 
> determined and the latter method disabling UltraDMA, here this becames 
> an issue...

Agreed, fixed.

> > +static void cs5536_dma_start(ide_drive_t *drive)
> > +{
> > +	if (drive->current_speed < XFER_UDMA_0)
> > +		cs5536_program_dtc(drive, drive->drive_data >> 8);
> >   
> 
>    Worth comparing the values as PIO4 and MWDMA2 timings exactly 
> correspond. Hm, PIO3 and MWDMA1 too...

Good catch, fixed.

> > +/**
> > + *	cs5536_init_one
> > + *	@dev: PCI device
> > + *	@id: Entry in match table
> > + */
> > +
> > +static int cs5536_init_one(struct pci_dev *dev, const struct pci_device_id *id)
> > +{
> > +	u32 cfg;
> > +
> > +	if (use_msr)
> > +		printk(KERN_ERR DRV_NAME ": Using MSR regs instead of PCI\n");
> >   
> 
>    Why KERN_ERR? :-O

Copied from original driver. :)

I changed it to KERN_INFO.

> > +	cs5536_read(dev, CFG, &cfg);
> > +
> > +	if ((cfg & IDE_CFG_CHANEN) == 0) {
> > +		printk(KERN_ERR DRV_NAME ": disabled by BIOS\n");
> > +		return -ENODEV;
> >   
> 
>    Eh, why not do it via the usual .enablebits mechanism?

Because we may be using MSR access instead of PCI one.

Thanks for review Sergei, new patch description + v1->v2 interdiff
below (v2 has been merged into pata-2.6 tree now if somebody wants
to see the full patch):

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] ide: add CS5536 host driver (v2)

This is a port of libata's pata_cs5536.c (written by Martin K. Petersen)
to IDE subsystem.

Changes done while at it:

* Reprogram PIO/MWDMA timings if needed before and after DMA transfer
  (chipset uses shared PIO/MWDMA timings).

* Fix cable detection to report 80-wires cable if BIOS set it for any
  device on a port (IDE core will do drive-side cable detection later).

* Don't disable UDMA while programming PIO timings.

* Simplify PCI/MSR support.

Pros of having IDE host driver in addition to libata's one:

* IDE is much lighter than SCSI+libata, the host driver itself is also
  a bit smaller:

   text    data     bss     dec     hex filename
   1237     500       4    1741     6cd drivers/ata/pata_cs5536.o
   1214     128       4    1346     542 drivers/ide/cs5536.o

* This allows use of IDE features which are unavailable under libata.

v2:
* Fixes per review from Sergei:
  - simplify dependency check in Kconfig
  - use IDE_DRV_MASK also for ->drive_data
  - disable UDMA when programming MWDMA
  - program new DTC timings only when necessary
  - fix printk() level in cs5536_init_one()

* Fix patch description according to comments from Alan and Sergei.

Cc: Martin K. Petersen <mkp@mkp.net>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Karl Auerbach <karl@iwl.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
v1->v2 interdiff only

diff -u b/drivers/ide/Kconfig b/drivers/ide/Kconfig
--- b/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -467,7 +467,7 @@
 
 config BLK_DEV_CS5536
 	tristate "CS5536 chipset support"
-	depends on X86 && !X86_64
+	depends on X86_32
 	select BLK_DEV_IDEDMA_PCI
 	help
 	  This option enables support for the AMD CS5536
diff -u b/drivers/ide/cs5536.c b/drivers/ide/cs5536.c
--- b/drivers/ide/cs5536.c
+++ b/drivers/ide/cs5536.c
@@ -61,6 +61,9 @@
 
 	IDE_CAST_CMD_SHIFT	= 24,
 	IDE_CAST_CMD_MASK	= 0xff,
+
+	IDE_ETC_UDMA_RELSHIFT	= 6,
+	IDE_ETC_UDMA_MASK	= 0x3,
 };
 
 static int use_msr;
@@ -150,7 +153,7 @@
 	if (pair)
 		cmd_pio = min(pio, ide_get_best_pio_mode(pair, 255, 4));
 
-	drive->drive_data &= 0xff00;
+	drive->drive_data &= (IDE_DRV_MASK << 8);
 	drive->drive_data |= drv_timings[pio];
 
 	cs5536_program_dtc(drive, drv_timings[pio]);
@@ -186,22 +189,24 @@
 	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
 	u32 etc;
 
-	if (mode >= XFER_UDMA_0) {
-		cs5536_read(pdev, ETC, &etc);
+	cs5536_read(pdev, ETC, &etc);
 
+	if (mode >= XFER_UDMA_0) {
 		etc &= ~(IDE_DRV_MASK << dshift);
 		etc |= udma_timings[mode - XFER_UDMA_0] << dshift;
-
-		cs5536_write(pdev, ETC, etc);
 	} else { /* MWDMA */
-		drive->drive_data &= 0xff;
+		etc &= ~(IDE_ETC_UDMA_MASK << (dshift + IDE_ETC_UDMA_RELSHIFT));
+		drive->drive_data &= IDE_DRV_MASK;
 		drive->drive_data |= mwdma_timings[mode - XFER_MW_DMA_0] << 8;
 	}
+
+	cs5536_write(pdev, ETC, etc);
 }
 
 static void cs5536_dma_start(ide_drive_t *drive)
 {
-	if (drive->current_speed < XFER_UDMA_0)
+	if (drive->current_speed < XFER_UDMA_0 &&
+	    (drive->drive_data >> 8) != (drive->drive_data & IDE_DRV_MASK))
 		cs5536_program_dtc(drive, drive->drive_data >> 8);
 
 	ide_dma_start(drive);
@@ -211,8 +216,9 @@
 {
 	int ret = ide_dma_end(drive);
 
-	if (drive->current_speed < XFER_UDMA_0)
-		cs5536_program_dtc(drive, drive->drive_data & 0xff);
+	if (drive->current_speed < XFER_UDMA_0 &&
+	    (drive->drive_data >> 8) != (drive->drive_data & IDE_DRV_MASK))
+		cs5536_program_dtc(drive, drive->drive_data & IDE_DRV_MASK);
 
 	return ret;
 }
@@ -255,7 +261,7 @@
 	u32 cfg;
 
 	if (use_msr)
-		printk(KERN_ERR DRV_NAME ": Using MSR regs instead of PCI\n");
+		printk(KERN_INFO DRV_NAME ": Using MSR regs instead of PCI\n");
 
 	cs5536_read(dev, CFG, &cfg);
 

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Christoph .J Thompson]

Sergei Shtylyov wrote:
> Hm, looks like your CF drive is rather advanced
> and might be supporting UltraDMA (and your CF slot
> supports DMA). Care to post the output of 'hdparm -i /dev/hda'? 

/dev/hda:                                                                       
                                                                                
 Model=HMS360604D5CF00, FwRev=DP3OC40D, SerialNo=DNP450B4YHR2EA                 
 Config={ HardSect NotMFM Removeable DTR>10Mbs nonMagnetic }                    
 RawCHS=5952/16/63, TrkSize=32256, SectSize=512, ECCbytes=4                     
 BuffType=DualPortCache, BuffSize=128kB, MaxMultSect=32, MultSect=off           
 CurCHS=5952/16/63, CurSects=5999616, LBA=yes, LBAsects=5999616                 
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}               
 PIO modes:  pio0 pio1 pio2 pio3 pio4                                           
 DMA modes:  mdma0 mdma1 mdma2                                                  
 UDMA modes: udma0 udma1 *udma2                                                 
 AdvancedPM=yes: mode=0x60 (96) WriteCache=disabled                             
 Drive conforms to: ATA/ATAPI-4 published, ANSI INCITS 317-1998:  ATA/ATAPI-1,24
                                                                                
 * signifies the current active mode

That's the output for my Hitachi Microdrive on the ALIX.2d3. It's using UDMA although I'm not using the pata_cs5536 driver since this Microdrive shows up as /dev/hda.

I'm having problems booting a kernel with pata_cs5536 on this box:

PC Engines ALIX.2 v0.99h
640 KB Base Memory
261120 KB Extended Memory
Waiting for HDD ...

01F0 Master 848A HMS360604D5CF00                         
Phys C/H/S 5952/16/63 Log C/H/S 744/128/63

LI
LILLOO  2222..88  bboooott::  

LLooaaddiinngg  LLiinnuuxx..................................................

BBIIOOSS  ddaattaa  cchheecckk  ssuucccceessssffuull

[    0.000000] BIOS EBDA/lowmem at: 00000000/000a0000
[    0.000000] Linux version 2.6.28.2alix2d3-2 (witukind@wotan) (gcc version 4.2.4) #4 Fri Jan 30 23:31:26 CET 2009
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   NSC Geode by NSC
[    0.000000]   Cyrix CyrixInstead
[    0.000000]   Centaur CentaurHauls
[    0.000000]   Transmeta GenuineTMx86
[    0.000000]   Transmeta TransmetaCPU
[    0.000000]   UMC UMC UMC UMC
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
[    0.000000]  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000] DMI not present or invalid.
[    0.000000] last_pfn = 0x10000 max_arch_pfn = 0x100000
[    0.000000] ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926]
[    0.000000] 256MB LOWMEM available.
[    0.000000]   mapped low ram: 0 - 10000000
[    0.000000]   low ram: 00000000 - 10000000
[    0.000000]   bootmap 00001000 - 00003000
[    0.000000] (6 early reservations) ==> bootmem [0000000000 - 0010000000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
[    0.000000]   #1 [0000200000 - 00004ab218]    TEXT DATA BSS ==> [0000200000 - 00004ab218]
[    0.000000]   #2 [00004ac000 - 00004af000]    INIT_PG_TABLE ==> [00004ac000 - 00004af000]
[    0.000000]   #3 [000009f000 - 0000100000]    BIOS reserved ==> [000009f000 - 0000100000]
[    0.000000]   #4 [0000007000 - 0000008000]          PGTABLE ==> [0000007000 - 0000008000]
[    0.000000]   #5 [0000001000 - 0000003000]          BOOTMAP ==> [0000001000 - 0000003000]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   Normal   0x00001000 -> 0x00010000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x000000a0
[    0.000000]     0: 0x00000100 -> 0x00010000
[    0.000000] Allocating PCI resources starting at 20000000 (gap: 10000000:eff00000)
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64928
[    0.000000] Kernel command line: BOOT_IMAGE=Linux ro root=LABEL=root console=ttyS0,38400n8 edd=off
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 1024 (order: 10, 4096 bytes)
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 497.995 MHz processor.
[    0.010000] Console: colour dummy device 80x25
[    0.010000] console [ttyS0] enabled
[    0.010000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.010000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.010000] Memory: 256568k/262144k available (1568k kernel code, 5008k reserved, 752k data, 176k init, 0k highmem)
[    0.010000] virtual kernel memory layout:
[    0.010000]     fixmap  : 0xfffed000 - 0xfffff000   (  72 kB)
[    0.010000]     vmalloc : 0xd0800000 - 0xfffeb000   ( 759 MB)
[    0.010000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.010000]       .init : 0xc0448000 - 0xc0474000   ( 176 kB)
[    0.010000]       .data : 0xc03880f0 - 0xc0444334   ( 752 kB)
[    0.010000]       .text : 0xc0200000 - 0xc03880f0   (1568 kB)
[    0.010000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
[    0.010000] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.010016] Calibrating delay loop (skipped), value calculated using timer frequency.. 995.99 BogoMIPS (lpj=4979950)
[    0.030051] Security Framework initialized
[    0.040033] Mount-cache hash table entries: 512
[    0.050364] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
[    0.060011] CPU: L2 Cache: 128K (32 bytes/line)
[    0.070027] CPU: Geode(TM) Integrated Processor by AMD PCS stepping 02
[    0.090012] Checking 'hlt' instruction... OK.
[    0.141405] Freeing SMP alternatives: 0k freed
[    0.150010] ACPI: Core revision 20080926
[    0.160110] ACPI Exception (tbxface-0627): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20080926]
[    0.183426] ACPI: Unable to load the System Description Tables
[    0.190690] net_namespace: 704 bytes
[    0.200771] NET: Registered protocol family 16
[    0.210050] geode-mfgpt:  8 MFGPT timers available.
[    0.220009] geode-mfgpt:  Registered timer 0
[    0.230034] mfgpt-timer:  Registering MFGPT timer 0 as a clock event, using IRQ 7
[    0.241693] PCI: PCI BIOS revision 2.10 entry at 0xfced9, last bus=0
[    0.250013] PCI: Using configuration type 1 for base access
[    0.265322] ACPI: Interpreter disabled.
[    0.270927] SCSI subsystem initialized
[    0.280775] PCI: Probing PCI hardware
[    0.290653] pci 0000:00:09.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.300171] pci 0000:00:09.0: PME# disabled
[    0.310312] pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.320038] pci 0000:00:0a.0: PME# disabled
[    0.330141] pci 0000:00:0b.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.340011] pci 0000:00:0b.0: PME# disabled
[    0.350802] pci 0000:00:0f.4: PME# supported from D0 D3hot D3cold
[    0.360018] pci 0000:00:0f.4: PME# disabled
[    0.370247] pci 0000:00:0f.5: PME# supported from D0 D3hot D3cold
[    0.380016] pci 0000:00:0f.5: PME# disabled
[    0.392386] pnp: PnP ACPI: disabled
[    0.402124] bus: 00 index 0 io port: [0x00-0xffff]
[    0.416578] bus: 00 index 1 mmio: [0x000000-0xffffffff]
[    0.432357] NET: Registered protocol family 2
[    0.446189] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.468140] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    0.489576] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[    0.509082] TCP: Hash tables configured (established 8192 bind 8192)
[    0.528204] TCP reno registered
[    0.538551] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.584100] HugeTLB registered 4 MB page size, pre-allocated 0 pages
[    0.615490] msgmni has been set to 501
[    0.628037] alg: No test for stdrng (krng)
[    0.641030] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.663275] io scheduler noop registered
[    0.675209] io scheduler cfq registered (default)
[    0.701838] Serial: 8250/16550 driver4 ports, IRQ sharing disabled
ÿ[    1.006820] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
[    1.306617] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
[    1.326604] Driver 'sd' needs updating - please use bus_type methods
[    1.346086] scsi0 : pata_cs5536
[    1.356079] scsi1 : pata_cs5536
[    1.365962] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
[    1.386924] ata2: DUMMY
[    1.570678] ata1.00: CFA: HMS360604D5CF00, DP3OC40D, max UDMA/33
[    1.588766] ata1.00: 5999616 sectors, multi 0: LBA 
[    1.646824] ata1.00: configured for UDMA/33
[    1.659803] scsi 0:0:0:0: Direct-Access     ATA      HMS360604D5CF00  DP3O PQ: 0 ANSI: 5
[    1.684813] sd 0:0:0:0: [sda] 5999616 512-byte hardware sectors: (3.07 GB/2.86 GiB)
[    1.707902] sd 0:0:0:0: [sda] Write Protect is off
[    1.722482] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    1.750365] sd 0:0:0:0: [sda] 5999616 512-byte hardware sectors: (3.07 GB/2.86 GiB)
[    1.773459] sd 0:0:0:0: [sda] Write Protect is off
[    1.788001] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    1.815452]  sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 >
[    2.217848] sd 0:0:0:0: [sda] Attached SCSI removable disk
[    2.235380] PNP: No PS/2 controller found. Probing ports directly.
[    2.254873] i8042.c: No controller found.
[    2.267240] mice: PS/2 mouse device common for all mice
[    2.283134] cpuidle: using governor ladder
[    2.295520] cpuidle: using governor menu
[    2.310323] Using IPI Shortcut mode
[    2.322395] VFS: Cannot open root device "LABEL=root" or unknown-block(0,0)
[    2.343367] Please append a correct "root=" boot option; here are the available partitions:
[    2.368481] 0800         2999808 sda driver: sd
[    2.382190]   0801           96736 sda1
[    2.393810]   0802          249984 sda2
[    2.405455]   0803               1 sda3
[    2.417079]   0805          572512 sda5
[    2.428702]   0806          294304 sda6
[    2.440321]   0807          878944 sda7
[    2.451942]   0808          124960 sda8
[    2.463589]   0809          193504 sda9
[    2.475213]   080a          588640 sda10
[    2.487121] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

-- 
Christoph .J Thompson <cjsthompson@gmail.com>

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Martin K. Petersen]

>>>>> "Christoph" == Christoph J Thompson <cjsthompson@gmail.com> writes:

Christoph> I'm having problems booting a kernel with pata_cs5536 on this
Christoph> box:

Christoph> [ 2.322395] VFS: Cannot open root device "LABEL=root"

Your initrd isn't set up correctly.  Probably missing the pata_cs5536
driver (or not there at all).  Either generate a suitable initrd or fix
lilo to boot with root=/dev/sdaN.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Martin K. Petersen wrote:

>>>>>> "Christoph" == Christoph J Thompson <cjsthompson@gmail.com> writes:
>>>>>>             
>
> Christoph> I'm having problems booting a kernel with pata_cs5536 on this
> Christoph> box:
>
> Christoph> [ 2.322395] VFS: Cannot open root device "LABEL=root"
>
> Your initrd isn't set up correctly.  Probably missing the pata_cs5536
> driver (or not there at all).

   If you'd have read all the log and not that one line, you'd have seen 
that pata_cs5536 was present. ;-)

MBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Christoph .J Thompson wrote:

>> Hm, looks like your CF drive is rather advanced
>> and might be supporting UltraDMA (and your CF slot
>> supports DMA). Care to post the output of 'hdparm -i /dev/hda'? 
>>     
>
> /dev/hda:                                                                       
>                                                                                 
>  Model=HMS360604D5CF00, FwRev=DP3OC40D, SerialNo=DNP450B4YHR2EA                 
>  Config={ HardSect NotMFM Removeable DTR>10Mbs nonMagnetic }                    
>  RawCHS=5952/16/63, TrkSize=32256, SectSize=512, ECCbytes=4                     
>  BuffType=DualPortCache, BuffSize=128kB, MaxMultSect=32, MultSect=off           
>  CurCHS=5952/16/63, CurSects=5999616, LBA=yes, LBAsects=5999616                 
>  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}               
>  PIO modes:  pio0 pio1 pio2 pio3 pio4                                           
>  DMA modes:  mdma0 mdma1 mdma2                                                  
>  UDMA modes: udma0 udma1 *udma2                                                 
>  AdvancedPM=yes: mode=0x60 (96) WriteCache=disabled                             
>  Drive conforms to: ATA/ATAPI-4 published, ANSI INCITS 317-1998:  ATA/ATAPI-1,24
>                                                                                 
>  * signifies the current active mode
>
>   

   Could you please post the output of 'hdparm --Istdout /dev/hda' too 
(we are now in need of more CF identify data)?

> That's the output for my Hitachi Microdrive on the ALIX.2d3. It's using UDMA although I'm not using the pata_cs5536 driver since this Microdrive shows up as /dev/hda.
>   

   So you're using ide-pci-generic or Bart's new driver?

> I'm having problems booting a kernel with pata_cs5536 on this box:
>   

[...]

> [    1.326604] Driver 'sd' needs updating - please use bus_type methods
> [    1.346086] scsi0 : pata_cs5536
> [    1.356079] scsi1 : pata_cs5536
> [    1.365962] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
> [    1.386924] ata2: DUMMY
>   

   Dummy yourself. :-)

> [    1.570678] ata1.00: CFA: HMS360604D5CF00, DP3OC40D, max UDMA/33
>   

   So even the current broken code manages to recognize it as CF... it 
would be espcially interesting to see the raw identify data.

> [    1.588766] ata1.00: 5999616 sectors, multi 0: LBA 
> [    1.646824] ata1.00: configured for UDMA/33
> [    1.659803] scsi 0:0:0:0: Direct-Access     ATA      HMS360604D5CF00  DP3O PQ: 0 ANSI: 5
> [    1.684813] sd 0:0:0:0: [sda] 5999616 512-byte hardware sectors: (3.07 GB/2.86 GiB)
> [    1.707902] sd 0:0:0:0: [sda] Write Protect is off
> [    1.722482] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [    1.750365] sd 0:0:0:0: [sda] 5999616 512-byte hardware sectors: (3.07 GB/2.86 GiB)
> [    1.773459] sd 0:0:0:0: [sda] Write Protect is off
> [    1.788001] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> [    1.815452]  sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 >
> [    2.217848] sd 0:0:0:0: [sda] Attached SCSI removable disk
> [    2.235380] PNP: No PS/2 controller found. Probing ports directly.
> [    2.254873] i8042.c: No controller found.
> [    2.267240] mice: PS/2 mouse device common for all mice
> [    2.283134] cpuidle: using governor ladder
> [    2.295520] cpuidle: using governor menu
> [    2.310323] Using IPI Shortcut mode
> [    2.322395] VFS: Cannot open root device "LABEL=root" or unknown-block(0,0)
>   

   Tried specifying the root device explicitly?

MBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Martin K. Petersen]

>>>>> "Sergei" == Sergei Shtylyov <sshtylyov@ru.mvista.com> writes:

Sergei>   If you'd have read all the log and not that one line, you'd
Sergei>   have seen that pata_cs5536 was present. ;-)

-ETOOEARLY

Apparently it turned out to be a udev/Slackware problem...

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Christoph .J Thompson]

On Sat, 31 Jan 2009 17:42:52 +0300
Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:

> Hello.
>
>    Could you please post the output of 'hdparm --Istdout /dev/hda' too 
> (we are now in need of more CF identify data)?  

With the pata_cs5536 driver:

/dev/sda:
848a 1740 0000 0010 7e00 0200 003f 005b
8c00 0000 2020 2020 2020 444e 5034 3530
4234 5948 5232 4541 0003 0100 0004 4450
334f 4334 3044 484d 5333 3630 3630 3444
3543 4630 3020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8020
0000 0f00 0000 0200 0000 0007 1740 0010
003f 8c00 005b 0100 8c00 005b 0000 0007
0003 0078 0078 0078 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
001e 0012 7068 500c 4000 7048 100c 4000
0407 0000 0000 4060 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0002 0000 0111 0000 0000 0000 0000
0000 0000 0064 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 8c3f 1111 0000 0000 04b0 0001
8100 8001 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

With AMD_IDE:

/dev/hda:
848a 1740 0000 0010 7e00 0200 003f 005b
8c00 0000 2020 2020 2020 444e 5034 3530
4234 5948 5232 4541 0003 0100 0004 4450
334f 4334 3044 484d 5333 3630 3630 3444
3543 4630 3020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8020
0000 0f00 0000 0200 0000 0007 1740 0010
003f 8c00 005b 0100 8c00 005b 0000 0007
0003 0078 0078 0078 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
001e 0012 7068 500c 4000 7068 100c 4000
0407 0000 0000 4060 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 000b 0000 0111 0000 0000 0000 0000
0000 0000 0064 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 8c3f 1111 0000 0000 04b0 0001
8100 8001 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

Does it matter if that was dumped while pata_cs5536 was in use? If yes, I'll just reboot to the Slackware kernel and provide you with another dump.

>    So you're using ide-pci-generic or Bart's new driver?

I guess it's not ide-pci-generic but I could be wrong

00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01) )
        Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort--
        Latency: 248, Cache Line Size: 32 bytes
        Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size]
        Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size]
        Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size]
        Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size]
        Region 4: I/O ports at ff00 [size=16]
        Kernel driver in use: AMD_IDE
        Kernel modules: pata_cs5536, pata_amd


> > [    1.326604] Driver 'sd' needs updating - please use bus_type methods
> > [    1.346086] scsi0 : pata_cs5536
> > [    1.356079] scsi1 : pata_cs5536
> > [    1.365962] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
> > [    1.386924] ata2: DUMMY
> >   
> 
>    Dummy yourself. :-)

I think that in addition to the Compact Flash interface there's a normal IDE connector on the ALIX.2d3 as well.

> > [    1.570678] ata1.00: CFA: HMS360604D5CF00, DP3OC40D, max UDMA/33
> >   
> 
>    So even the current broken code manages to recognize it as CF... it 
> would be espcially interesting to see the raw identify data.

If you need anything more just let me know.


-- 
Christoph .J Thompson <cjsthompson@gmail.com>

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Mark Lord]

The only difference between those two identify packets
seems to be that the drive write-cache was disabled
when dumped from the pata_cs5536, and enabled when
dumped from AMD_IDE.

[~] diff -u 1.id 2.id
--- 1.id        2009-01-31 11:33:58.000000000 -0500
+++ 2.id        2009-01-31 11:34:11.000000000 -0500
@@ -31,7 +31,7 @@
 Commands/features:
        Enabled Supported:
           *    Power Management feature set
-               Write cache
+          *    Write cache
           *    Look-ahead
           *    WRITE_BUFFER command
           *    READ_BUFFER command
@@ -40,4 +40,4 @@
           *    Advanced Power Management feature set
           *    Mandatory FLUSH_CACHE
           *    CFA Power Level 1  (max 256mA)
-Integrity word not set (found 0x0000, expected 0x4da5)
+Integrity word not set (found 0x0000, expected 0x24a5)

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

>>> +enum {
>>> +	MSR_IDE_CFG		= 0x51300010,
>>> +	PCI_IDE_CFG		= 0x40,
>>> +
>>> +	CFG			= 0,
>>> +	DTC			= 2,
>>> +	CAST			= 3,
>>> +	ETC			= 4,
>>> +
>>> +	IDE_CFG_CHANEN		= (1 << 1),
>>> +	IDE_CFG_CABLE		= (1 << 17) | (1 << 16),
>>> +
>>> +	IDE_D0_SHIFT		= 24,
>>> +	IDE_D1_SHIFT		= 16,
>>> +	IDE_DRV_MASK		= 0xff,
>>> +
>>> +	IDE_CAST_D0_SHIFT	= 6,
>>> +	IDE_CAST_D1_SHIFT	= 4,
>>> +	IDE_CAST_DRV_MASK	= 0x3,
>>> +
>>> +	IDE_CAST_CMD_SHIFT	= 24,
>>> +	IDE_CAST_CMD_MASK	= 0xff,
>>> +};
>>>   
>>>       
>>    Declaring a lot of semi-related constants is not what enum was 
>> intended for I think...
>>     
>
> Don't know about that but it is still better than using defines.
>   

   That's what I doubt...

>>> +	cs5536_read(dev, CFG, &cfg);
>>> +
>>> +	if ((cfg & IDE_CFG_CHANEN) == 0) {
>>> +		printk(KERN_ERR DRV_NAME ": disabled by BIOS\n");
>>> +		return -ENODEV;
>>>   
>>>       
>>    Eh, why not do it via the usual .enablebits mechanism?
>>     
>
> Because we may be using MSR access instead of PCI one.
>   

   Ah...

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] ide: add CS5536 host driver (v2)
>
> This is a port of libata's pata_cs5536.c (written by Martin K. Petersen)
> to IDE subsystem.
>
> Changes done while at it:
>
> * Reprogram PIO/MWDMA timings if needed before and after DMA transfer
>   (chipset uses shared PIO/MWDMA timings).
>
> * Fix cable detection to report 80-wires cable if BIOS set it for any
>   device on a port (IDE core will do drive-side cable detection later).
>
> * Don't disable UDMA while programming PIO timings.
>
> * Simplify PCI/MSR support.
>
> Pros of having IDE host driver in addition to libata's one:
>
> * IDE is much lighter than SCSI+libata, the host driver itself is also
>   a bit smaller:
>
>    text    data     bss     dec     hex filename
>    1237     500       4    1741     6cd drivers/ata/pata_cs5536.o
>    1214     128       4    1346     542 drivers/ide/cs5536.o
>
> * This allows use of IDE features which are unavailable under libata.
>
> v2:
> * Fixes per review from Sergei:
>   - simplify dependency check in Kconfig
>   - use IDE_DRV_MASK also for ->drive_data
>   - disable UDMA when programming MWDMA
>   - program new DTC timings only when necessary
>   - fix printk() level in cs5536_init_one()
>
> * Fix patch description according to comments from Alan and Sergei.
>
> Cc: Martin K. Petersen <mkp@mkp.net>
> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Cc: Karl Auerbach <karl@iwl.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> v1->v2 interdiff only
>   

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>


> diff -u b/drivers/ide/cs5536.c b/drivers/ide/cs5536.c
> --- b/drivers/ide/cs5536.c
> +++ b/drivers/ide/cs5536.c
> @@ -61,6 +61,9 @@
>  
>  	IDE_CAST_CMD_SHIFT	= 24,
>  	IDE_CAST_CMD_MASK	= 0xff,
> +
> +	IDE_ETC_UDMA_RELSHIFT	= 6,
> +	IDE_ETC_UDMA_MASK	= 0x3,
>   

   Too many shifts and mask values to my taste, why not just use 0xC0?

> @@ -186,22 +189,24 @@
>  	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
>  	u32 etc;
>  
> -	if (mode >= XFER_UDMA_0) {
> -		cs5536_read(pdev, ETC, &etc);
> +	cs5536_read(pdev, ETC, &etc);
>  
> +	if (mode >= XFER_UDMA_0) {
>  		etc &= ~(IDE_DRV_MASK << dshift);
>   

   Er, I'm not sure using IDE_DRV_MASK here is completely correct as 
only the mask 0xC7 actually controls UltraDMA enables and cycle time...

MBR, Sergei

Re: Some IDE issues with 2.6.28 on PC-Engines ALIX2

[Bartlomiej Zolnierkiewicz]

On Saturday 31 January 2009, Sergei Shtylyov wrote:
> Hello.
> 
> Bartlomiej Zolnierkiewicz wrote:
> 
> >>> +enum {
> >>> +	MSR_IDE_CFG		= 0x51300010,
> >>> +	PCI_IDE_CFG		= 0x40,
> >>> +
> >>> +	CFG			= 0,
> >>> +	DTC			= 2,
> >>> +	CAST			= 3,
> >>> +	ETC			= 4,
> >>> +
> >>> +	IDE_CFG_CHANEN		= (1 << 1),
> >>> +	IDE_CFG_CABLE		= (1 << 17) | (1 << 16),
> >>> +
> >>> +	IDE_D0_SHIFT		= 24,
> >>> +	IDE_D1_SHIFT		= 16,
> >>> +	IDE_DRV_MASK		= 0xff,
> >>> +
> >>> +	IDE_CAST_D0_SHIFT	= 6,
> >>> +	IDE_CAST_D1_SHIFT	= 4,
> >>> +	IDE_CAST_DRV_MASK	= 0x3,
> >>> +
> >>> +	IDE_CAST_CMD_SHIFT	= 24,
> >>> +	IDE_CAST_CMD_MASK	= 0xff,
> >>> +};
> >>>   
> >>>       
> >>    Declaring a lot of semi-related constants is not what enum was 
> >> intended for I think...
> >>     
> >
> > Don't know about that but it is still better than using defines.
> >   
> 
>    That's what I doubt...
> 
> >>> +	cs5536_read(dev, CFG, &cfg);
> >>> +
> >>> +	if ((cfg & IDE_CFG_CHANEN) == 0) {
> >>> +		printk(KERN_ERR DRV_NAME ": disabled by BIOS\n");
> >>> +		return -ENODEV;
> >>>   
> >>>       
> >>    Eh, why not do it via the usual .enablebits mechanism?
> >>     
> >
> > Because we may be using MSR access instead of PCI one.
> >   
> 
>    Ah...
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] ide: add CS5536 host driver (v2)
> >
> > This is a port of libata's pata_cs5536.c (written by Martin K. Petersen)
> > to IDE subsystem.
> >
> > Changes done while at it:
> >
> > * Reprogram PIO/MWDMA timings if needed before and after DMA transfer
> >   (chipset uses shared PIO/MWDMA timings).
> >
> > * Fix cable detection to report 80-wires cable if BIOS set it for any
> >   device on a port (IDE core will do drive-side cable detection later).
> >
> > * Don't disable UDMA while programming PIO timings.
> >
> > * Simplify PCI/MSR support.
> >
> > Pros of having IDE host driver in addition to libata's one:
> >
> > * IDE is much lighter than SCSI+libata, the host driver itself is also
> >   a bit smaller:
> >
> >    text    data     bss     dec     hex filename
> >    1237     500       4    1741     6cd drivers/ata/pata_cs5536.o
> >    1214     128       4    1346     542 drivers/ide/cs5536.o
> >
> > * This allows use of IDE features which are unavailable under libata.
> >
> > v2:
> > * Fixes per review from Sergei:
> >   - simplify dependency check in Kconfig
> >   - use IDE_DRV_MASK also for ->drive_data
> >   - disable UDMA when programming MWDMA
> >   - program new DTC timings only when necessary
> >   - fix printk() level in cs5536_init_one()
> >
> > * Fix patch description according to comments from Alan and Sergei.
> >
> > Cc: Martin K. Petersen <mkp@mkp.net>
> > Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> > Cc: Karl Auerbach <karl@iwl.com>
> > Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > ---
> > v1->v2 interdiff only
> >   
> 
> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> 
> 
> > diff -u b/drivers/ide/cs5536.c b/drivers/ide/cs5536.c
> > --- b/drivers/ide/cs5536.c
> > +++ b/drivers/ide/cs5536.c
> > @@ -61,6 +61,9 @@
> >  
> >  	IDE_CAST_CMD_SHIFT	= 24,
> >  	IDE_CAST_CMD_MASK	= 0xff,
> > +
> > +	IDE_ETC_UDMA_RELSHIFT	= 6,
> > +	IDE_ETC_UDMA_MASK	= 0x3,
> >   
> 
>    Too many shifts and mask values to my taste, why not just use 0xC0?

Fixed, I have no idea why I did it this way originally... :)

> > @@ -186,22 +189,24 @@
> >  	int dshift = (drive->dn & 1) ? IDE_D1_SHIFT : IDE_D0_SHIFT;
> >  	u32 etc;
> >  
> > -	if (mode >= XFER_UDMA_0) {
> > -		cs5536_read(pdev, ETC, &etc);
> > +	cs5536_read(pdev, ETC, &etc);
> >  
> > +	if (mode >= XFER_UDMA_0) {
> >  		etc &= ~(IDE_DRV_MASK << dshift);
> >   
> 
>    Er, I'm not sure using IDE_DRV_MASK here is completely correct as 
> only the mask 0xC7 actually controls UltraDMA enables and cycle time...

Bits 0x38 are described to be hardwired to 0 in the datasheet so this
should be OK (also pata_cs5536.c does the same thing)...

v2->v3 interdiff:
...
v3:
* Smarter masking of UDMA bits per Sergei's suggestion.
...

diff -u b/drivers/ide/cs5536.c b/drivers/ide/cs5536.c
--- b/drivers/ide/cs5536.c
+++ b/drivers/ide/cs5536.c
@@ -62,8 +62,7 @@
 	IDE_CAST_CMD_SHIFT	= 24,
 	IDE_CAST_CMD_MASK	= 0xff,
 
-	IDE_ETC_UDMA_RELSHIFT	= 6,
-	IDE_ETC_UDMA_MASK	= 0x3,
+	IDE_ETC_UDMA_MASK	= 0xc0,
 };
 
 static int use_msr;
@@ -195,7 +194,7 @@
 		etc &= ~(IDE_DRV_MASK << dshift);
 		etc |= udma_timings[mode - XFER_UDMA_0] << dshift;
 	} else { /* MWDMA */
-		etc &= ~(IDE_ETC_UDMA_MASK << (dshift + IDE_ETC_UDMA_RELSHIFT));
+		etc &= ~(IDE_ETC_UDMA_MASK << dshift);
 		drive->drive_data &= IDE_DRV_MASK;
 		drive->drive_data |= mwdma_timings[mode - XFER_MW_DMA_0] << 8;
 	}