DMA in PCI chipset -- module vs. compiled-in

DMA in PCI chipset -- module vs. compiled-in

[William Park]

Dear experts,

Normally, my PCI chipset (ie. via82cxxx, hpt366) are compiled in, and it
correctly enables DMA of my harddisk.

But, for experiment, I tried compiling in only the "generic" options,
and moved all specific PCI chipsets as modules.  Hotplug loads the
modules, but with all 'hdparm' options turned off.  When I tried turning
on DMA, 
    $ hdparm -m 16 -c 1 -u 1 -d 1 /dev/hda
I get
    /dev/hda:
     setting 32-bit IO_support flag to 1
     setting multcount to 16
     setting unmaskirq to 1 (on)
     setting using_dma to 1 (on)
     HDIO_SET_DMA failed: Operation not permitted
     multcount    = 16 (on)
     IO_support   =  1 (32-bit)
     unmaskirq    =  1 (on)
     using_dma    =  0 (off)

Is this normal?  How do I turn on DMA, if I load my PCI chipset as
module?

-- 
William Park <opengeometry@yahoo.ca>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
	   http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
	  http://freshmeat.net/projects/bashdiff/

Re: DMA in PCI chipset -- module vs. compiled-in

[Lee Revell]

On Sun, 2006-02-05 at 22:43 -0500, William Park wrote:
> But, for experiment, I tried compiling in only the "generic" options,
> and moved all specific PCI chipsets as modules.  Hotplug loads the
> modules, but with all 'hdparm' options turned off.  When I tried turning
> on DMA, 

Generic and chipset specific support are not complementary, they are
mutually exclusive.  Having generic PCI IDE support enabled will prevent
the chipset specific support from working properly.

This is actually a problem in several areas of the kernel (it's the same
for "Generic RTC" vs. the normal RTC) - I don't think the name "Generic"
properly reflects that it will prevent more specific device support from
working.

Lee

Re: DMA in PCI chipset -- module vs. compiled-in

[Ingo Oeser]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

Hi Lee,

On Monday 06 February 2006 05:32, Lee Revell wrote:
> This is actually a problem in several areas of the kernel (it's the same
> for "Generic RTC" vs. the normal RTC) - I don't think the name "Generic"
> properly reflects that it will prevent more specific device support from
> working.

What about "Fallback $DEVICE" instead?

Regards

Ingo Oeser


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: DMA in PCI chipset -- module vs. compiled-in

[Alan Cox]

On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> Generic and chipset specific support are not complementary, they are
> mutually exclusive.  Having generic PCI IDE support enabled will prevent
> the chipset specific support from working properly.

Untrue.

The PCI generic driver by default grabs only hardware with PCI IDS it
knows can be driven generically. That list purposefully has no overlaps
with chipset drivers.

Alan

Re: DMA in PCI chipset -- module vs. compiled-in

[Lee Revell]

On Mon, 2006-02-06 at 19:49 +0000, Alan Cox wrote:
> On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> > Generic and chipset specific support are not complementary, they are
> > mutually exclusive.  Having generic PCI IDE support enabled will prevent
> > the chipset specific support from working properly.
> 
> Untrue.
> 
> The PCI generic driver by default grabs only hardware with PCI IDS it
> knows can be driven generically. That list purposefully has no overlaps
> with chipset drivers.

OK.  But wasn't this a problem in previous kernels?

Lee

Re: DMA in PCI chipset -- module vs. compiled-in

[Lee Revell]

On Mon, 2006-02-06 at 20:31 +0100, Ingo Oeser wrote:
> Hi Lee,
> 
> On Monday 06 February 2006 05:32, Lee Revell wrote:
> > This is actually a problem in several areas of the kernel (it's the same
> > for "Generic RTC" vs. the normal RTC) - I don't think the name "Generic"
> > properly reflects that it will prevent more specific device support from
> > working.
> 
> What about "Fallback $DEVICE" instead?

Yes, that would be much better for the RTC case.

Lee

Re: DMA in PCI chipset -- module vs. compiled-in

[William Park]

On Mon, Feb 06, 2006 at 07:49:25PM +0000, Alan Cox wrote:
> On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> > Generic and chipset specific support are not complementary, they are
> > mutually exclusive.  Having generic PCI IDE support enabled will prevent
> > the chipset specific support from working properly.
> 
> Untrue.
> 
> The PCI generic driver by default grabs only hardware with PCI IDS it
> knows can be driven generically. That list purposefully has no overlaps
> with chipset drivers.

The kernel I'm using is 2.6.14.  My chipset is Via 82c694x and 82c686b
(Abit VP6 dual-P3 with HighPoint 370).  DMA is on only when 'via82cxxx'
and 'hpt366' are compiled in.  Most importantly, DMA cannot be turned on
if loading by module.

Does it mean that this "bug" is pecular to my chipset?

-- 
William Park <opengeometry@yahoo.ca>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
	   http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
	  http://freshmeat.net/projects/bashdiff/

Re: DMA in PCI chipset -- module vs. compiled-in

[Bartlomiej Zolnierkiewicz]

On 2/6/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Mon, 2006-02-06 at 19:49 +0000, Alan Cox wrote:
> > On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> > > Generic and chipset specific support are not complementary, they are
> > > mutually exclusive.  Having generic PCI IDE support enabled will prevent
> > > the chipset specific support from working properly.
> >
> > Untrue.
> >
> > The PCI generic driver by default grabs only hardware with PCI IDS it
> > knows can be driven generically. That list purposefully has no overlaps
> > with chipset drivers.
>
> OK.  But wasn't this a problem in previous kernels?

It wasn't.  The issue is more complicated, you can have
three host drivers driving the same hardware:

* ide-generic driver
  - ISA like support
  - also works for PCI in legacy mode

* IDE PCI generic (the one Alan refers to)
  - generic IDE PCI support
  - by default doesn't grab IDs for which we have other drivers
    (can be forced by using kernel parameter)

* chipset specific driver

The most common mistake is to built-in ide-generic driver
and compile chipset specific driver as module...

To William:
CONFIG_IDE_GENERIC=n is a likely solution for your problem.

Bartlomiej

Re: DMA in PCI chipset -- module vs. compiled-in

[Alan Cox]

On Maw, 2006-02-07 at 09:14 +0100, Bartlomiej Zolnierkiewicz wrote:
> * chipset specific driver
> 
> The most common mistake is to built-in ide-generic driver
> and compile chipset specific driver as module...

Oh that no longer works. That worked in 2.4, as it would take over the
chipset. Didn't work if it was in use at the time but did work correctly
if idle.

Re: DMA in PCI chipset -- module vs. compiled-in

[Bartlomiej Zolnierkiewicz]

On 2/7/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2006-02-07 at 09:14 +0100, Bartlomiej Zolnierkiewicz wrote:
> > * chipset specific driver
> >
> > The most common mistake is to built-in ide-generic driver
> > and compile chipset specific driver as module...
>
> Oh that no longer works. That worked in 2.4, as it would take over the
> chipset. Didn't work if it was in use at the time but did work correctly
> if idle.

I'm talking about _driver_ here and it works just fine.

If you are talking about "taking over" feature, you are right.
It was racy and indeed "worked" depending on timing.

Bartlomiej

Re: DMA in PCI chipset -- module vs. compiled-in

[William Park]

On Tue, Feb 07, 2006 at 12:14:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On 2/7/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Maw, 2006-02-07 at 09:14 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > * chipset specific driver
> > >
> > > The most common mistake is to built-in ide-generic driver
> > > and compile chipset specific driver as module...
> >
> > Oh that no longer works. That worked in 2.4, as it would take over the
> > chipset. Didn't work if it was in use at the time but did work correctly
> > if idle.
> 
> I'm talking about _driver_ here and it works just fine.
> 
> If you are talking about "taking over" feature, you are right.
> It was racy and indeed "worked" depending on timing.

Interesting.  I'll move the "generic" as module, and see how it goes.

-- 
William Park <opengeometry@yahoo.ca>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
	   http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
	  http://freshmeat.net/projects/bashdiff/