Using PATA Platform Driver to access Memory Mapped CF Card

Using PATA Platform Driver to access Memory Mapped CF Card

[Graeme Russ]

Hello,

I have a CF slot mapped to a GP bus on a board I'm porting linux to. It is
wired in 8-bit Memory Mode only with only A0 - A3 mapped from the address
bus (starting at 0x20000000). I know the arrangement works as this board is
successfully accessing CF cards using existing proprietary firmware.

I have added some platform specific initialisation to the kernel. I came to
the 0x2000000E by looking at some blackfin examples (particularly
mach-bf537/boards/stamp.c) - I do not know if this is exactly right

static struct pata_platform_info enet_pata_platform_data = {
	.ioport_shift = 0,
};

static struct resource enet_pata_resources[] = {
	{
		.start = 0x20000000,
		.end = 0x20000007,
		.flags = IORESOURCE_MEM,
	},
	{
		.start = 0x2000000E,
		.end = 0x2000000E,
		.flags = IORESOURCE_MEM,
	},
};

static struct platform_device enet_pata_device = {
	.name = "pata_platform",
	.id = -1,
	.num_resources = ARRAY_SIZE(enet_pata_resources),
	.resource = enet_pata_resources,
	.dev = {
		.platform_data = &enet_pata_platform_data,
	}
};

static struct platform_device *enet_devices[] __initdata = {
	&enet_pata_device,
};

static int __init enet_init(void)
{
	printk(KERN_INFO "%s(): registering device resources\n", __func__);
	platform_add_devices(enet_devices, ARRAY_SIZE(enet_devices));
	return 0;
}

arch_initcall(enet_init);

Which results in the following kernel messages (With a 512MB SanDisk Card):
[    0.065999] enet_init(): registering device resources
...
[    1.988931] scsi0 : pata_platform
[    1.996940] ata1: PATA max PIO0 no IRQ, using PIO polling mmio cmd
0x20000000 ctl 0x2000000e
...
[    2.168883] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
[    1.995794] ata1.01: NODEV after polling detection
[    2.013803] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
...
[    7.146794] ata1.01: NODEV after polling detection
[    7.164802] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
[   12.297794] ata1.01: NODEV after polling detection
[   12.315802] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
[   17.448794] ata1.01: NODEV after polling detection

And similar with a 1G UltraII and 4G Extreme III but they do not generate
the NODEV message. With no card inserted I get neither the NODEV nor the
failed to IDENTIFY messages. It looks like something is at least partially
working.

Can anyone tell me how to go about enabling an appropriate level of
debugging options, and what I should be looking out for?

TIA

Graeme

Re: Using PATA Platform Driver to access Memory Mapped CF Card

[Alan Cox]

On Sat, 01 May 2010 17:13:47 +1000
Graeme Russ <graeme.russ@gmail.com> wrote:

> Hello,
> 
> I have a CF slot mapped to a GP bus on a board I'm porting linux to. It is
> wired in 8-bit Memory Mode only with only A0 - A3 mapped from the address
> bus (starting at 0x20000000). I know the arrangement works as this board is
> successfully accessing CF cards using existing proprietary firmware.

Our ATA/IDE driver stack only supports 16/32bit accesses for data. You
can override the data_xfer methods in a driver to do 8bit transfers. That
may be one problem you are seeing I guess.

> [    1.988931] scsi0 : pata_platform
> [    1.996940] ata1: PATA max PIO0 no IRQ, using PIO polling mmio cmd
> 0x20000000 ctl 0x2000000e
> ...
> [    2.168883] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
> [    1.995794] ata1.01: NODEV after polling detection
> [    2.013803] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
> ...
> [    7.146794] ata1.01: NODEV after polling detection
> [    7.164802] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
> [   12.297794] ata1.01: NODEV after polling detection
> [   12.315802] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x2)
> [   17.448794] ata1.01: NODEV after polling detection
> 
> And similar with a 1G UltraII and 4G Extreme III but they do not generate
> the NODEV message. With no card inserted I get neither the NODEV nor the
> failed to IDENTIFY messages. It looks like something is at least partially
> working.
> 
> Can anyone tell me how to go about enabling an appropriate level of
> debugging options, and what I should be looking out for?

include/linux/libata.h

define these: 

#undef ATA_DEBUG                /* debugging output */
#undef ATA_VERBOSE_DEBUG        /* yet more debugging output */

and you should get a lot more info

Re: Using PATA Platform Driver to access Memory Mapped CF Card

[Graeme Russ]

Alan Cox wrote:
> On Sat, 01 May 2010 17:13:47 +1000
> Graeme Russ <graeme.russ@gmail.com> wrote:
> 
>> Hello,
>>
>> I have a CF slot mapped to a GP bus on a board I'm porting linux to. It is
>> wired in 8-bit Memory Mode only with only A0 - A3 mapped from the address
>> bus (starting at 0x20000000). I know the arrangement works as this board is
>> successfully accessing CF cards using existing proprietary firmware.
> 
> Our ATA/IDE driver stack only supports 16/32bit accesses for data. You
> can override the data_xfer methods in a driver to do 8bit transfers. That
> may be one problem you are seeing I guess.
> 

Bingo! Thanks - I simply hacked:

    ioread16_rep(data_addr, buf, words);
to:
    ioread8_rep(data_addr, buf, buflen);

(and similarly for the writes) in ata_sff_data_xfer() and it all "just
works (tm)":

[    2.106837] ata1.00: CFA: SanDisk SDCFH-1024, HDX 4.04, max PIO4
[    2.109659] ata1.00: 2001888 sectors, multi 0: LBA
[    2.111034] ata1.00: configured for PIO
[    2.114811] ata1.00: configured for PIO
[    2.116445] ata1: EH complete
[    2.130852] scsi 0:0:0:0: Direct-Access     ATA      SanDisk SDCFH-10
HDX  PQ: 0 ANSI: 5
[    2.150821] sd 0:0:0:0: [sda] 2001888 512-byte logical blocks: (1.02
GB/977 MiB)
[    2.158847] sd 0:0:0:0: [sda] Write Protect is off
[    2.161977] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[    2.177842]  sda: sda1
[    2.205838] sd 0:0:0:0: [sda] Attached SCSI removable disk

Now to do things right - I've traced everything back into
pata_platform_port_ops (.sff_data_xfer = ata_sff_data_xfer_noirq). So I
will need to create custom data_xfer_noirq and data_xfer functions for the
8-bit transfers. Is there an elegant way to override pata_platform's use of
ata_sff_data_xfer_noirq or will I need to also write a new version of
pata_platform as well?

Thanks

Graeme

Re: Using PATA Platform Driver to access Memory Mapped CF Card

[Alan Cox]

> pata_platform_port_ops (.sff_data_xfer = ata_sff_data_xfer_noirq). So I
> will need to create custom data_xfer_noirq and data_xfer functions for the
> 8-bit transfers. Is there an elegant way to override pata_platform's use of
> ata_sff_data_xfer_noirq or will I need to also write a new version of
> pata_platform as well?

Extending pata_platform_info is probably the right thing to do - and
allow it to override the data_xfer operation if a new data_xfer field is
non NULL. See include/linux/ata_platform.h.

So you'll need to tweak pata_platform a spot. Alternatively you could
write a small libata driver specifically for your device - which may make
sense if it supports higher speed modes and speed setting stuff.

Alan

Re: Using PATA Platform Driver to access Memory Mapped CF Card

[Graeme Russ]

Alan Cox wrote:
>> pata_platform_port_ops (.sff_data_xfer = ata_sff_data_xfer_noirq). So I
>> will need to create custom data_xfer_noirq and data_xfer functions for the
>> 8-bit transfers. Is there an elegant way to override pata_platform's use of
>> ata_sff_data_xfer_noirq or will I need to also write a new version of
>> pata_platform as well?
> 
> Extending pata_platform_info is probably the right thing to do - and
> allow it to override the data_xfer operation if a new data_xfer field is
> non NULL. See include/linux/ata_platform.h.
> 
> So you'll need to tweak pata_platform a spot. Alternatively you could
> write a small libata driver specifically for your device - which may make
> sense if it supports higher speed modes and speed setting stuff.
> 

Thanks Alan,

I've added a data_xfer member to pata_platform_info and added the following
just prior to the call to __pata_platform_probe()

	if (pp_info)
		if (unlikely(pp_info->data_xfer))
			pata_platform_port_ops.sff_data_xfer = pp_info->data_xfer;

and implemented an 8-bit version of ata_sff_data_xfer() in my board
specific code. Should I submit a patch (or is this considered too esoteric
for mainline?)

I now have another problem - My board has two CF slots (one at base address
0x20000000 and one at base address 0x20001000. I would like to be able to
access them both, but if I try to init two pata_platform devices I get:

sysfs: cannot create duplicate filename '/devices/platform/pata_platform'

and

kobject_add_internal failed for pata_platform with -EEXIST, don't try to
register things with the same name in the same directory

Is it possible to register two devices using the pata platform driver?

Regards,

Graeme

Re: Using PATA Platform Driver to access Memory Mapped CF Card

[Alan Cox]

> and implemented an 8-bit version of ata_sff_data_xfer() in my board
> specific code. Should I submit a patch (or is this considered too esoteric
> for mainline?)

Please submit a patch.

> 
> I now have another problem - My board has two CF slots (one at base address
> 0x20000000 and one at base address 0x20001000. I would like to be able to
> access them both, but if I try to init two pata_platform devices I get:
> 
> sysfs: cannot create duplicate filename '/devices/platform/pata_platform'
> 
> and
> 
> kobject_add_internal failed for pata_platform with -EEXIST, don't try to
> register things with the same name in the same directory
> 
> Is it possible to register two devices using the pata platform driver?

Yes but you cannot have two devices with the same name/id so make sure
you are setting the id etc. See

 arch/arm/mach-s3c2440/mach-anubis.c