linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@intracom.gr>
To: Paul Mackerras <paulus@au1.ibm.com>
Cc: joakim.tjernlund@lumentis.se, Matt Porter <porter@cox.net>,
	linuxppc-embedded@lists.linuxppc.org
Subject: Re: Regarding consistent_alloc
Date: Mon, 09 Dec 2002 11:06:13 +0200	[thread overview]
Message-ID: <3DF45D05.5030003@intracom.gr> (raw)
In-Reply-To: <15857.15826.513311.884408@argo.ozlabs.ibm.com>


Paul Mackerras wrote:

>Joakim Tjernlund writes:
>
>
>>m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work
>>on addresses returned by m8xx_cpm_hostalloc(). I just found that out the
>>hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver
>>hung as soon you tried to read something.
>>
>
>Then m8xx_cpm_hostalloc should be changed so it returns the DMA
>address along with the virtual address (of the uncached mapping).
>
>An alternative which will work, at least at present, is to use iopa()
>on the virtual address.  However, that assumes that DMA bus addresses
>are identical to CPU physical addresses.  That is true at the moment
>on all embedded PPC platforms that I know of currently, but there is
>no guarantee that it will always be true.  That is why I think it is
>better to make a practice of saving the DMA address that you get back
>from consistent_alloc and using that.
>
>Paul.
>
>
>
>
>
Since I'm the one that started this thread let me make a few points.

1. The comment that consistent_alloc is tied to the PCI bus is valid,
since the dma_handle is returned by a call to virt_to_bus(), with
the virt_to_bus() being:

/*
 * The PCI bus is inherently Little-Endian.  The PowerPC is being
 * run Big-Endian.  Thus all values which cross the [PCI] barrier
 * must be endian-adjusted.  Also, the local DRAM has a different
 * address from the PCI point of view, thus buffer addresses also
 * have to be modified [mapped] appropriately.
 */
extern inline unsigned long virt_to_bus(volatile void * address)
{
#ifndef CONFIG_APUS
        if (address == (void *)0)
                return 0;
        return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
#else
        return iopa ((unsigned long) address);
#endif
}

Also the consistent_sync() takes as a direction argument values like
PCI_DMA_FROMDEVICE.

It has something obviously to do with a PCI bus. My board, and I believe most of the boards with a 8xx do not have a PCI bus.

Is it possible to modify consistent_alloc to be something more
generic?

2. I have a requirement to have my drivers loaded as modules.
m8xx_cpm_hostalloc has a very simplistic implementation, which
makes it unsuitable for something like that. I have some patches
that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
a proper heap, with free space management and coalescing.
What is the proper way to push them, and to whom?

3. I have already posted my QMC driver, and I'm in the process
of writting some documentation and usage scenarios.
Could someone please have a look and get back to me.
I'm open to suggestions, and I would very much like to have it
included in the tree.
I know it is not perfect but still as it stands there are no QMC
drivers in the tree.

Regards

--
Pantelis Antoniou
INTRACOM S.A. Greece


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~2002-12-09  9:06 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-06 13:18 Regarding consistent_alloc Pantelis Antoniou
2002-12-06 13:23 ` Pantelis Antoniou
2002-12-06 14:25   ` Joakim Tjernlund
2002-12-06 15:59     ` Matt Porter
2002-12-06 16:08       ` Joakim Tjernlund
2002-12-06 18:30         ` Matt Porter
2002-12-06 18:15           ` Joakim Tjernlund
2002-12-06 18:52             ` Matt Porter
2002-12-06 19:59             ` Dan Malek
2002-12-06 22:11               ` Joakim Tjernlund
2002-12-07  0:16         ` Paul Mackerras
2002-12-07 12:53           ` Joakim Tjernlund
2002-12-07 16:53             ` Dan Malek
2002-12-09  9:06           ` Pantelis Antoniou [this message]
2002-12-10 17:49             ` Tom Rini
2002-12-11  3:52               ` acurtis
2002-12-11  8:57                 ` Joakim Tjernlund
2002-12-11  9:58                   ` Pantelis Antoniou
2002-12-11 14:41                     ` acurtis
2002-12-11 15:01                       ` Pantelis Antoniou
2002-12-11 15:36                         ` acurtis
2002-12-12  3:32                       ` Dan Malek
2002-12-11 14:56                     ` Tom Rini
2002-12-11 15:07                       ` Pantelis Antoniou
2002-12-12  3:41                         ` Dan Malek
2002-12-12  8:00                           ` Pantelis Antoniou
2002-12-12  8:18                             ` Wolfgang Denk
2002-12-12  8:37                               ` Pantelis Antoniou
2002-12-12 12:56                                 ` Is the preemptive kernel patch unsafe for 8xx/PPC? Joakim Tjernlund
2002-12-12 18:28                                   ` Eugene Surovegin
2002-12-12 20:35                                     ` Joakim Tjernlund
2002-12-13  4:12                                       ` acurtis
2002-12-13  6:09                                       ` Eugene Surovegin
2002-12-13  7:47                                         ` Joakim Tjernlund
2002-12-16 14:41                                           ` acurtis
2002-12-13  4:08                                     ` acurtis
2002-12-12 16:53                               ` "Missing" patches (Was: Re: Regarding consistent_alloc) Tom Rini
2002-12-06 16:56       ` Regarding consistent_alloc Dan Malek
2002-12-06 18:29         ` Matt Porter
2002-12-06 19:45           ` Dan Malek
2002-12-07  0:25           ` Paul Mackerras
2002-12-06 15:54 ` Matt Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DF45D05.5030003@intracom.gr \
    --to=panto@intracom.gr \
    --cc=joakim.tjernlund@lumentis.se \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=paulus@au1.ibm.com \
    --cc=porter@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).