Hi All!
I am currently writing a low-level driver for non-PCI SATA controller
in ARM platform.which uses libata-core.c for linux-2.4.25. Can any one
tell me any reference code available under linux.
Regards,
balani
--
"A smile confuses an approaching frown..."
On Maw, 2005-10-25 at 17:41 +0530, Deven Balani wrote:
> Hi All!
>
> I am currently writing a low-level driver for non-PCI SATA controller
> in ARM platform.which uses libata-core.c for linux-2.4.25. Can any one
> tell me any reference code available under linux.
At the moment its a bit hard to do a non PCI driver because the core
code assumes that there is a device structure (or pci_dev structure) for
everything. Fixing that is a two line change for 2.6 (probably similar
for 2.4) but Jeff Garzik rejected it. A second problem is that it
doesn't return the host_set by default but 2.4 libata doesn't have the
changes for unloading SATA modules so that should be ignorable
With that patched something like this will do the job (you'll probably
be using MMIO while the example is PIO)
static __init int legacy_init_one(unsigned long io, unsigned long ctrl,
int irq)
{
struct ata_probe_ent ae;
int ret;
memset(&ae, 0, sizeof(struct ata_probe_ent));
ae.dev = NULL;
ae.port_ops = &legacy_port_ops;
ae.sht = &legacy_sht;
ae.n_ports = 2;
ae.pio_mask = 0x1F;
ae.irq = irq;
ae.irq_flags = 0;
ae.host_flags = ATA_FLAG_SLAVE_POSS;
ae.port[0].cmd_addr = io;
ata_std_ports(&ae.port[0]);
ae.port[0].altstatus_addr = ctrl;
ae.port[0].ctl_addr = ctrl;
ret = ata_device_add(&ae);
if(ret == 0)
return -ENODEV;
legacy_host[nr_legacy_host++] = ae.host_set;
return 0;
}
Alan Cox wrote:
> On Maw, 2005-10-25 at 17:41 +0530, Deven Balani wrote:
>
>>Hi All!
>>
>>I am currently writing a low-level driver for non-PCI SATA controller
>>in ARM platform.which uses libata-core.c for linux-2.4.25. Can any one
>>tell me any reference code available under linux.
>
>
> At the moment its a bit hard to do a non PCI driver because the core
> code assumes that there is a device structure (or pci_dev structure) for
> everything. Fixing that is a two line change for 2.6 (probably similar
> for 2.4) but Jeff Garzik rejected it.
In 2.6.x, libata needs no fixes to support non-PCI devices.
An out-of-tree driver for a non-PCI embedded board exists, and works
100%. Use of struct device and dma_xxx() means it is bus-agnostic.
That's how the whole system was designed to work -- and work, it does.
None of this is true in 2.4.x, of course...
Jeff
Hi jeff,
Thank you for your quick reply.
According to your mail I believe I had to write a SATA low-level
driver only for
2.6 kernels.
But I have a problem my other drivers are 2.4.25 compliant. So it is a huge work
to make all other drivers 2.6 compliant and use libata-core.c.
I believe it is far more easier to have 2.4.x libata rather than
porting my drivers to
2.6.x.
What do you suggest me ?
Regards,
balani
On 10/25/05, Jeff Garzik <[email protected]> wrote:
> Alan Cox wrote:
> > On Maw, 2005-10-25 at 17:41 +0530, Deven Balani wrote:
> >
> >>Hi All!
> >>
> >>I am currently writing a low-level driver for non-PCI SATA controller
> >>in ARM platform.which uses libata-core.c for linux-2.4.25. Can any one
> >>tell me any reference code available under linux.
> >
> >
> > At the moment its a bit hard to do a non PCI driver because the core
> > code assumes that there is a device structure (or pci_dev structure) for
> > everything. Fixing that is a two line change for 2.6 (probably similar
> > for 2.4) but Jeff Garzik rejected it.
>
> In 2.6.x, libata needs no fixes to support non-PCI devices.
>
> An out-of-tree driver for a non-PCI embedded board exists, and works
> 100%. Use of struct device and dma_xxx() means it is bus-agnostic.
> That's how the whole system was designed to work -- and work, it does.
>
> None of this is true in 2.4.x, of course...
>
> Jeff
>
>
>
--
"A smile confuses an approaching frown..."
On Wed, Oct 26, 2005 at 11:28:10AM +0530, Deven Balani wrote:
> But I have a problem my other drivers are 2.4.25 compliant. So it is
> a huge work
> to make all other drivers 2.6 compliant and use libata-core.c.
> I believe it is far more easier to have 2.4.x libata rather than
> porting my drivers to
> 2.6.x.
Porting drivers to 2.6 isn't too hard. LWN has a nice tutorial, see
http://lwn.net/Articles/driver-porting/ .
> What do you suggest me ?
Use 2.6, especially with new hardware. The 2.4 kernel on ARM is no
longer supported, all development has moved to 2.6 almost two years
ago.
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
Hi Jeff
In your previous mail you've mentioned that:
>An out-of-tree driver for a non-PCI embedded board exists, and works
>100%. Use of struct device and dma_xxx() means it is bus-agnostic.
>That's how the whole system was designed to work -- and work, it does.
Can I just have a patch or link to the said out-of-tree code?
Thanks,
Deven
On 10/25/05, Jeff Garzik <[email protected]> wrote:
> Alan Cox wrote:
> > On Maw, 2005-10-25 at 17:41 +0530, Deven Balani wrote:
> >
> >>Hi All!
> >>
> >>I am currently writing a low-level driver for non-PCI SATA controller
> >>in ARM platform.which uses libata-core.c for linux-2.4.25. Can any one
> >>tell me any reference code available under linux.
> >
> >
> > At the moment its a bit hard to do a non PCI driver because the core
> > code assumes that there is a device structure (or pci_dev structure) for
> > everything. Fixing that is a two line change for 2.6 (probably similar
> > for 2.4) but Jeff Garzik rejected it.
>
> In 2.6.x, libata needs no fixes to support non-PCI devices.
>
> An out-of-tree driver for a non-PCI embedded board exists, and works
> 100%. Use of struct device and dma_xxx() means it is bus-agnostic.
> That's how the whole system was designed to work -- and work, it does.
>
> None of this is true in 2.4.x, of course...
>
> Jeff
>
>
--
"A smile confuses an approaching frown..."