Re: Any guides for adding new IDE chipset drivers?

Re: Any guides for adding new IDE chipset drivers?

[Alex Bennee]

On Monday 16 of Febuary 2004 09:40:21 PST, Bart wrote:
>On Monday 16 of February 2004 18:04, Alex Bennee wrote:
>
>> Is there a driver that can be held of as an example of good taste and
>> the "right" way to implement a chipset driver?
>
>Yep.  Please take a look at drivers/ide/arm/icside.c.
>It is well written, quite simple and has DMA support.

Thanks. I'll base my driver on this one as it does seem quite easy
to follow. However I'm wondering what the point of the begin/end functions
are. The dma_read/write functions just seem to call dma_count which starts the
dma requests going.

Am I missing something here? Is all that required from the higher level a single
call to dma_read/write or should I be expecting a series of calls to setup a transfer?


>If you have any questions/issues feel free to ask
>on linux-ide@vger.kernel.org mailing list.

Hmmm, vger seems to be ignoring my subscribe requests. 

Is the list archived anywhere? None are listed on VGER.


-- 
Alex, homepage: http://www.bennee.com/~alex/
It is a hard matter, my fellow citizens, to argue with the belly,
since it has no ears.
		-- Marcus Porcius Cato

Re: Any guides for adding new IDE chipset drivers?

[Randy.Dunlap]

On Tue, 17 Feb 2004 14:27:06 +0000 Alex Bennee <kernel-hacker@bennee.com> wrote:

| On Monday 16 of Febuary 2004 09:40:21 PST, Bart wrote:
| >On Monday 16 of February 2004 18:04, Alex Bennee wrote:
| >
| >> Is there a driver that can be held of as an example of good taste and
| >> the "right" way to implement a chipset driver?
| >
| >Yep.  Please take a look at drivers/ide/arm/icside.c.
| >It is well written, quite simple and has DMA support.
| 
| Thanks. I'll base my driver on this one as it does seem quite easy
| to follow. However I'm wondering what the point of the begin/end functions
| are. The dma_read/write functions just seem to call dma_count which starts the
| dma requests going.
| 
| Am I missing something here? Is all that required from the higher level a single
| call to dma_read/write or should I be expecting a series of calls to setup a transfer?
| 
| 
| >If you have any questions/issues feel free to ask
| >on linux-ide@vger.kernel.org mailing list.
| 
| Hmmm, vger seems to be ignoring my subscribe requests. 
| 
| Is the list archived anywhere? None are listed on VGER.

http://marc.theaimsgroup.com/?l=linux-ide



--
~Randy
kernel-janitors project:  http://janitor.kernelnewbies.org/

Re: Any guides for adding new IDE chipset drivers?

[Bartlomiej Zolnierkiewicz]

On Tuesday 17 of February 2004 15:27, Alex Bennee wrote:
> On Monday 16 of Febuary 2004 09:40:21 PST, Bart wrote:
> >On Monday 16 of February 2004 18:04, Alex Bennee wrote:
> >> Is there a driver that can be held of as an example of good taste and
> >> the "right" way to implement a chipset driver?
> >
> >Yep.  Please take a look at drivers/ide/arm/icside.c.
> >It is well written, quite simple and has DMA support.
>
> Thanks. I'll base my driver on this one as it does seem quite easy
> to follow. However I'm wondering what the point of the begin/end functions
> are. The dma_read/write functions just seem to call dma_count which starts
> the dma requests going.

hwif->ide_dma_count() is gone in 2.6.3-rc4.

ATAPI drivers (ie. ide-cd.c) and TCQ code (ide-tcq.c)
use ->ide_dma_begin() and ->ide_dma_end() directly.

DMA timeout recovery functions also call ->ide_dma_end().

> Am I missing something here? Is all that required from the higher level a
> single call to dma_read/write or should I be expecting a series of calls to
> setup a transfer?

To setup a DMA transfer:

ATA: ->ide_dma_{read,write}() (they call ->ide_dma_begin()) or
     __ide_dma_queued_{read,write}() (they may call ->ide_dma_begin())

ATAPI: ->ide_dma_{read,write}() + ->ide_dma_begin()

Hope this helps.

Re: Any guides for adding new IDE chipset drivers?

[Alex Bennee]

On Tue, 2004-02-17 at 19:10, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 17 of February 2004 15:27, Alex Bennee wrote:
> >
> > Thanks. I'll base my driver on this one as it does seem quite easy
> > to follow. However I'm wondering what the point of the begin/end functions
> > are. The dma_read/write functions just seem to call dma_count which starts
> > the dma requests going.
> 
> hwif->ide_dma_count() is gone in 2.6.3-rc4.

Ok that makes sense. However I'm working with 2.4 as I'm not ready to
make the jump in versions yet. However the rest of your notes make
things clearer.

> ATAPI drivers (ie. ide-cd.c) and TCQ code (ide-tcq.c)
> use ->ide_dma_begin() and ->ide_dma_end() directly.
> 
> DMA timeout recovery functions also call ->ide_dma_end().

I take it the dma_test_irq() function is called from the ide layer can
just test to see if the DMA engine has finished its transfer?

> > Am I missing something here? Is all that required from the higher level a
> > single call to dma_read/write or should I be expecting a series of calls to
> > setup a transfer?
> 
> To setup a DMA transfer:
> 
> ATA: ->ide_dma_{read,write}() (they call ->ide_dma_begin()) or
>      __ide_dma_queued_{read,write}() (they may call ->ide_dma_begin())
> 
> ATAPI: ->ide_dma_{read,write}() + ->ide_dma_begin()
> 
> Hope this helps.

It does thanks :-)

-- 
Alex, homepage: http://www.bennee.com/~alex/
Leela: "Well, it's a type M planet, so it should at least have
Roddenberries." 

Any guides for adding new IDE chipset drivers?

[Alex Bennee]

Hi,

We currently have implemented a simple (PIO) IDE interface on our
embedded SH based board. The "driver" is just a simple call from
ide_setup() that twiddles the various values in ide_hwifs to set the
correct port addresses.

All this is all well and good and works fine. However I'm looking at
adding DMA support to the driver to make better use of the hardware.
I've been looking around the other arch IDE drivers (e.g. the ppc pmac
driver) which seem to hook into the probe_for_hwifs() and then update
the hwifs table itself. This makes me wonder am I initialising my driver
the "correct" way.

As far as implementing the DMA features is concerned as far as I can
tell I just need to code up routines for all the various
hwifs[x].ide_dma* functions and be done with it. Am I missing anything?

So my questions boil down to:

Are there any guides for driver writers for what needs doing to add new
IDE chipset drivers?

Is there a driver that can be held of as an example of good taste and
the "right" way to implement a chipset driver?

Regards,


-- 
Alex, homepage: http://www.bennee.com/~alex/
"I am not sure what this is, but an `F' would only dignify it."
		-- English Professor

Re: Any guides for adding new IDE chipset drivers?

[Bartlomiej Zolnierkiewicz]

On Monday 16 of February 2004 18:04, Alex Bennee wrote:
> Hi,
>
> We currently have implemented a simple (PIO) IDE interface on our
> embedded SH based board. The "driver" is just a simple call from
> ide_setup() that twiddles the various values in ide_hwifs to set the
> correct port addresses.

Most embedded people till now just _abused_ ide_init_default_hwifs() :-(.

> All this is all well and good and works fine. However I'm looking at
> adding DMA support to the driver to make better use of the hardware.
> I've been looking around the other arch IDE drivers (e.g. the ppc pmac
> driver) which seem to hook into the probe_for_hwifs() and then update
> the hwifs table itself. This makes me wonder am I initialising my driver
> the "correct" way.

No, it is not the "correct" way.

> As far as implementing the DMA features is concerned as far as I can
> tell I just need to code up routines for all the various
> hwifs[x].ide_dma* functions and be done with it. Am I missing anything?
>
> So my questions boil down to:
>
> Are there any guides for driver writers for what needs doing to add new
> IDE chipset drivers?

No, unfortunately.

> Is there a driver that can be held of as an example of good taste and
> the "right" way to implement a chipset driver?

Yep.  Please take a look at drivers/ide/arm/icside.c.
It is well written, quite simple and has DMA support.

If you have any questions/issues feel free to ask
on linux-ide@vger.kernel.org mailing list.

Cheers,
--bart