[Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[Keith Owens]

2.4.16-ia64-011128 has no definition for dma64_addr_t.
drivers/scsi/sym53c8xx_2/sym_glue.c:306: parse error before `bus_addr_t'

Index: 16.6/include/asm-ia64/types.h
--- 16.6/include/asm-ia64/types.h Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/s/24_types.h 1.1 644)
+++ 16.6(w)/include/asm-ia64/types.h Sun, 02 Dec 2001 14:46:52 +1100 kaos (linux-2.4/s/24_types.h 1.1 644)
@@ -63,6 +63,7 @@ typedef __u64 u64;
 /* DMA addresses are 64-bits wide, in general.  */
 
 typedef u64 dma_addr_t;
+typedef u64 dma64_addr_t;
 
 # endif /* __KERNEL__ */
 #endif /* !__ASSEMBLY__ */

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[Gérard Roudier]

On Mon, 3 Dec 2001, David Mosberger wrote:

> This error appears to be due to a bug in the sym53c8xx_2 driver.  Note
> that dma64_addr_t should be used only for the pci_dac_* interface,
> which I do not want to support on ia64 unless and until we absolutely
> have to (technically, there is no need for pci_dac_* on ia64 or x86).
>
> If you need a 64-bit integer type, just use u64 instead.

Hmmm....

The hardware hasn't knowledge of abstractions used in the kernel. The
dma_addr_t thing that can be 32 or 64 bits at kernel developer convenience
does not help significantly, in my opinion, when actually talking with
real hardware is in concern.

Speaking for me, all bus-related bloaty things that exist on various
kernels I have ported the driver (for now Linux + 2 BSDs) did not help me
a single pico-second. They look to me rather confusing stuff and results
of fards of brain. At the very most, they seem to be complex band-aids to
support marginal hardwares designed by stupid hardware ingenieers that
wanted to reinvent the wheel but didn't succeed.

Sorry for having missed this dma detail in sym53c8xx_2 driver, but I
cannot accept your 'bug' statement. Extremally bogus are proprietary
hardwares that require much complexity in driver development, hence
injecting useless bloat and bugs and, may-be, just sometimes discouraging
people to develop drivers as a sad result.

  Gérard.

> 	--david
>
> ----------------------------------------------
> From: Keith Owens <kaos@ocs.com.au>
> Sender: linux-ia64-admin@linuxia64.org
> To: linux-ia64@linuxia64.org
> Subject: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t
> Date: Sun, 02 Dec 2001 14:56:44 +1100
>
> 2.4.16-ia64-011128 has no definition for dma64_addr_t.
> drivers/scsi/sym53c8xx_2/sym_glue.c:306: parse error before `bus_addr_t'
>
> Index: 16.6/include/asm-ia64/types.h
> --- 16.6/include/asm-ia64/types.h Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/s/24_types.h 1.1 644)
> +++ 16.6(w)/include/asm-ia64/types.h Sun, 02 Dec 2001 14:46:52 +1100 kaos (linux-2.4/s/24_types.h 1.1 644)
> @@ -63,6 +63,7 @@ typedef __u64 u64;
>  /* DMA addresses are 64-bits wide, in general.  */
>
>  typedef u64 dma_addr_t;
> +typedef u64 dma64_addr_t;
>
>  # endif /* __KERNEL__ */
>  #endif /* !__ASSEMBLY__ */
>
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>
>

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

This error appears to be due to a bug in the sym53c8xx_2 driver.  Note
that dma64_addr_t should be used only for the pci_dac_* interface,
which I do not want to support on ia64 unless and until we absolutely
have to (technically, there is no need for pci_dac_* on ia64 or x86).

If you need a 64-bit integer type, just use u64 instead.

	--david

----------------------------------------------
From: Keith Owens <kaos@ocs.com.au>
Sender: linux-ia64-admin@linuxia64.org
To: linux-ia64@linuxia64.org
Subject: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t
Date: Sun, 02 Dec 2001 14:56:44 +1100

2.4.16-ia64-011128 has no definition for dma64_addr_t.
drivers/scsi/sym53c8xx_2/sym_glue.c:306: parse error before `bus_addr_t'

Index: 16.6/include/asm-ia64/types.h
--- 16.6/include/asm-ia64/types.h Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/s/24_types.h 1.1 644)
+++ 16.6(w)/include/asm-ia64/types.h Sun, 02 Dec 2001 14:46:52 +1100 kaos (linux-2.4/s/24_types.h 1.1 644)
@@ -63,6 +63,7 @@ typedef __u64 u64;
 /* DMA addresses are 64-bits wide, in general.  */
 
 typedef u64 dma_addr_t;
+typedef u64 dma64_addr_t;
 
 # endif /* __KERNEL__ */
 #endif /* !__ASSEMBLY__ */


_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

>>>>> On Mon, 3 Dec 2001 19:23:38 +0100 (CET), =?ISO-8859-1?Q?Gérard_Roudier?= <groudier@free.fr> said:

  Gerard> Sorry for having missed this dma detail in sym53c8xx_2
  Gerard> driver, but I cannot accept your 'bug' statement. Extremally
  Gerard> bogus are proprietary hardwares that require much complexity
  Gerard> in driver development, hence injecting useless bloat and
  Gerard> bugs and, may-be, just sometimes discouraging people to
  Gerard> develop drivers as a sad result.

Sorry, I didn't mean to critize your work.  I use "bug" fairly
casually and didn't mean to be insulting.  If it came across that way,
my apologies...

	--david

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[Gérard Roudier]

On Mon, 3 Dec 2001, David Mosberger wrote:

> >>>>> On Mon, 3 Dec 2001 19:23:38 +0100 (CET), =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> said:
>
>   Gerard> Sorry for having missed this dma detail in sym53c8xx_2
>   Gerard> driver, but I cannot accept your 'bug' statement. Extremally
>   Gerard> bogus are proprietary hardwares that require much complexity
>   Gerard> in driver development, hence injecting useless bloat and
>   Gerard> bugs and, may-be, just sometimes discouraging people to
>   Gerard> develop drivers as a sad result.
>
> Sorry, I didn't mean to critize your work.  I use "bug" fairly
> casually and didn't mean to be insulting.  If it came across that way,
> my apologies...

No apology needed. My posting was not against you. I just wanted to shout
my opinion about real source of tons of bugs beeing in the complexity
injected in modern kernels in order to support software-unfriendy designed
hardware. I didn't feel insulted at all by your 'bug' statement applying
to the driver, but just didn't accept it as is.

You are doing a great work for Linux. Sorry for having been so unclear.

  Gérard.

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[Gérard Roudier]

On Tue, 4 Dec 2001, David Mosberger wrote:

> >>>>> On Tue, 4 Dec 2001 09:45:19 +0100, Christoph Hellwig <hch@caldera.de> said:
>
>   Christoph> On Mon, Dec 03, 2001 at 11:34:28AM -0800, David Mosberger
>   Christoph> wrote:
>   >> This error appears to be due to a bug in the sym53c8xx_2 driver.
>   >> Note that dma64_addr_t should be used only for the pci_dac_*
>   >> interface, which I do not want to support on ia64 unless and
>   >> until we absolutely have to (technically, there is no need for
>   >> pci_dac_* on ia64 or x86).
>
>   Christoph> IA64 should use instead of it's horrible iommu emulation.
>
> Huh?  pci_dac_*() does not help you here at all.  pci_dac_*() is only
> needed/useful for 64-bit platforms which use a dma_addr_t that is
> smaller than 64 bits.  And even then is it needed only for drivers
> that create tons of mappings.

I am under the impression that it has been invented for sparc64 as a
provision for PCI devices that may gain advantage of real 64 bit DMA PCI
on this hardware. This platform has some streaming mode DMA implemented
for 32 bit PCI through an IO/MMU.

Choices are:

1) Faster IOs but only in 32 bit PCI mode + software complexity as a
   malus.
2) Slower IOs in 64 bit PCI mode.

Chosing the less bad one, here choice #1, is what is to be done when no
good choice is available.

  Gérard.

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[Gérard Roudier]

On Tue, 4 Dec 2001, David Mosberger wrote:

> >>>>> On Tue, 4 Dec 2001 19:15:06 +0100 (CET), =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> said:
>
>   Gerard> I am under the impression that it has been invented for
>   Gerard> sparc64 as a provision for PCI devices that may gain
>   Gerard> advantage of real 64 bit DMA PCI on this hardware. This
>   Gerard> platform has some streaming mode DMA implemented for 32 bit
>   Gerard> PCI through an IO/MMU.
>
>   Gerard> Choices are:
>
>   Gerard> 1) Faster IOs but only in 32 bit PCI mode + software
>   Gerard> complexity as a malus.  2) Slower IOs in 64 bit PCI mode.
>
>   Gerard> Chosing the less bad one, here choice #1, is what is to be
>   Gerard> done when no good choice is available.
>
> Close, but not quite: DaveM *always* wants to use SAC on SPARC64
> (using the I/O TLB if necessary) *unless* the device creates so many
> mappings that it could exhaust the address space of the I/O TLB.  His
> choice is motivated by the assumption that DAC is slower than SAC.  I

DAC costs 1 additionnal PCI cycle more than SAC for each transaction.
Given reasonnable burst lengths you will not see significant differences
all other things being equal, but they aren't on sparc64.

> don't believe that's a significant effect for machines with real
> 64-bit PCI buses.  Also, I think for most device driver writers, the
> complexity of having to choose between pci_* and pci_dac_* is just too
> much (just look at the original qlogic drivers if you don't know what
> I mean...).

I can guess.

> So, the rule of thumb should be:
>
>  (1) use the normal pci_* routines.
>
>  (2) if the device is DAC capable and can *truly* address all 64-bit
>      address bits (not just 36 bits or whatever) and SPARC64 runs into
>      I/O TLB address space trouble, consider using pci_dac_*.

I am rather interested in practice here and the pci_dac_* stuff seems to
address sparc64 only (and only linux, btw). Nothing than can motivate
anybody excepted DSM, in my opinion. :-)

  Gérard.

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

>>>>> On Tue, 4 Dec 2001 09:45:19 +0100, Christoph Hellwig <hch@caldera.de> said:

  Christoph> On Mon, Dec 03, 2001 at 11:34:28AM -0800, David Mosberger
  Christoph> wrote:
  >> This error appears to be due to a bug in the sym53c8xx_2 driver.
  >> Note that dma64_addr_t should be used only for the pci_dac_*
  >> interface, which I do not want to support on ia64 unless and
  >> until we absolutely have to (technically, there is no need for
  >> pci_dac_* on ia64 or x86).

  Christoph> IA64 should use instead of it's horrible iommu emulation.

Huh?  pci_dac_*() does not help you here at all.  pci_dac_*() is only
needed/useful for 64-bit platforms which use a dma_addr_t that is
smaller than 64 bits.  And even then is it needed only for drivers
that create tons of mappings.

	--david

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

>>>>> On Tue, 4 Dec 2001 16:52:05 +0100, Christoph Hellwig <hch@caldera.de> said:

  Christoph> On Tue, Dec 04, 2001 at 07:49:07AM -0800, David Mosberger
  Christoph> wrote: IA64 should use instead of it's horrible iommu
  Christoph> emulation.
  >>  Huh?  pci_dac_*() does not help you here at all.  pci_dac_*() is
  >> only needed/useful for 64-bit platforms which use a dma_addr_t
  >> that is smaller than 64 bits.  And even then is it needed only
  >> for drivers that create tons of mappings.

  Christoph> pci_dac_*() is defined to operate on dma64_addr_t
  Christoph> independand on wether it actually is different on
  Christoph> dma_addr_t.

Yes, but pci_dac_*() is also specifically designed *not* to do any
remapping.  It must do direct translation between address spaces
(i.e., basically what used to be called bus_to_virt()/virt_to_bus()).
It works only for fully-64bit capable DMA engines.

  Christoph> Maybe it should have been named dmadac_addr_t instead..

Perhaps.

	--david

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

>>>>> On Tue, 4 Dec 2001 17:00:33 +0100, Christoph Hellwig <hch@caldera.de> said:

  Chris> On Tue, Dec 04, 2001 at 07:57:07AM -0800, David Mosberger
  Chris> wrote:
  >> Yes, but pci_dac_*() is also specifically designed *not* to do
  >> any remapping.  It must do direct translation between address
  >> spaces (i.e., basically what used to be called
  >> bus_to_virt()/virt_to_bus()).  It works only for fully-64bit
  >> capable DMA engines.

  Chris> I don't get the point the above contributes to this
  Chris> discussion.  Does this mean you want drivers that are DAC
  Chris> capable to use pci_dac_* on 32bit plattforms and pci_* on
  Chris> 64bit plattforms?

No, of course not.  You that said ia64 should use pci_dac_*() instead
of an I/O TLB emulation and I'm saying that this doesn't work because
pci_dac_*() is a non-solution.

The suggestion is to always use the normal pci_*() mapping routines,
independent of whether the platform is 32 or 64 bit.

	--david

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

>>>>> On Tue, 4 Dec 2001 17:18:23 +0100, Christoph Hellwig <hch@caldera.de> said:

  Chris> On Tue, Dec 04, 2001 at 08:12:47AM -0800, David Mosberger
  Chris> wrote:
  >> No, of course not.  You that said ia64 should use pci_dac_*()
  >> instead of an I/O TLB emulation and I'm saying that this doesn't
  >> work because pci_dac_*() is a non-solution.
  >> 
  >> The suggestion is to always use the normal pci_*() mapping
  >> routines, independent of whether the platform is 32 or 64 bit.

  Chris> Yes and no.  Drivers that can and want to use DAC can do that
  Chris> on 32bit plattforms now, using the pci_dac_* stuff without
  Chris> _any_ IOMMU.  This should work on ia64 aswell, even if it's
  Chris> native dma_addr_t already is a 64 bit type.

The reason I don't like this very much is that you're assuming that
all DAC-capable devices will be able to address the full 64-bit
address space.  That just doesn't seem to be the case.  And as soon as
we have machines with larger memories than some of the DAC-capable
devices can address, we're back to pci_dac_*() having to have some
smarts as to whether a direct mapping is possible.

The only extra overhead of going through normal pci mapping routines
is a function call.  If that's noticable, you have a very fast device
indeed.

	--david

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

>>>>> On Tue, 4 Dec 2001 17:29:32 +0100, Christoph Hellwig <hch@caldera.de> said:

  Christoph> The problem is that we need a uniform API on all Linux
  Christoph> plattforms.  Linus has decided on this one, may it be
  Christoph> nice or not. (And I don't really like the pci_dac_* part
  Christoph> as it is to implementation-specific).

  >> The only extra overhead of going through normal pci mapping
  >> routines is a function call.  If that's noticable, you have a
  >> very fast device indeed.

  Christoph> On IA64 yes, on i386 or other 32bit plattforms not.

Then fix those implementations.  There is nothing difficult in first
checking the DMA mask.

Look, this is precisely why I'm reluctant to add the pci_dac*()
support now: people will use it in the wrong way and eventually we'll have
to add yet another layer of mapping underneath pci_dac_*().

pci_dac_*() is not intended for all DAC-capable devices.  It is
intended for DAC capable devices that generate tons of mappings.  If
you don't believe me, check with Dave Miller.

	--david

Re: [Linux-ia64] 2.4.16-ia64-011128 is missing dma64_addr_t

[David Mosberger]

>>>>> On Tue, 4 Dec 2001 19:15:06 +0100 (CET), =?ISO-8859-1?Q?Gérard_Roudier?= <groudier@free.fr> said:

  Gerard> I am under the impression that it has been invented for
  Gerard> sparc64 as a provision for PCI devices that may gain
  Gerard> advantage of real 64 bit DMA PCI on this hardware. This
  Gerard> platform has some streaming mode DMA implemented for 32 bit
  Gerard> PCI through an IO/MMU.

  Gerard> Choices are:

  Gerard> 1) Faster IOs but only in 32 bit PCI mode + software
  Gerard> complexity as a malus.  2) Slower IOs in 64 bit PCI mode.

  Gerard> Chosing the less bad one, here choice #1, is what is to be
  Gerard> done when no good choice is available.

Close, but not quite: DaveM *always* wants to use SAC on SPARC64
(using the I/O TLB if necessary) *unless* the device creates so many
mappings that it could exhaust the address space of the I/O TLB.  His
choice is motivated by the assumption that DAC is slower than SAC.  I
don't believe that's a significant effect for machines with real
64-bit PCI buses.  Also, I think for most device driver writers, the
complexity of having to choose between pci_* and pci_dac_* is just too
much (just look at the original qlogic drivers if you don't know what
I mean...).

So, the rule of thumb should be:

 (1) use the normal pci_* routines.

 (2) if the device is DAC capable and can *truly* address all 64-bit
     address bits (not just 36 bits or whatever) and SPARC64 runs into
     I/O TLB address space trouble, consider using pci_dac_*.

	--david