All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jacky Lam" <jackylam@astri.org>
To: <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: General porting question
Date: Fri, 10 Oct 2003 01:23:29 +0800	[thread overview]
Message-ID: <000b01c38e8a$0f4ef650$0202a8c0@homevl9biy3v7e> (raw)
In-Reply-To: 20031009093720.A13184@home.com


> > > You can not use virt_to_* on the address returned by
> > > pci_alloc_consistent().
> >
> >     Why?
>
> Because virt_to_*() is only defined for staticly mapped kernel virtual
> addresses...consistent_alloc() is not guaranteed to return a staticly
> mapped kernel virtual address so you can't use virt_to_*().  It is not
> a generic address translation API.
>
> >     By the way, this problem will only affect the consistency of dma
buffer.
> > In my case, it will only cause wrong output sound. But my card seems
don't
> > consume the dma and doesn't give any interrupt in return. It's fine on
PC
> > and I can receive interrupt if I write to the card's register to force
an
> > interrupt. What other possible porting problem can be here? Really
> > strange....
>
> Endianness issues as another person pointed out.  You still have to
> solve these address munging issues.

    Thanks. I will spend more time to understand those mapping stuff.....I
still cannot understand very clearly...

    Concerning endianness, I think the read/write to register of PCI card is
ok because it is done by inl()/outl() which already handled the endian
conversion. The remaining is the data written to dma buffer. I don't care it
now because the card seems don't start to consume the data.

    I look through the code many times. I can't find out any porting related
issues beside endianness and memory mapping that will make x86 and PPC
different. Any idea?

Best regards,
Jacky

P.S.: By the way, in embedded system, I know how much PCI memory are used.
Why don't we just give up some on board memory, say 1MB, and map "simply"
the memory with uncachable flag. Then this region of memory can be use by
PCI cards without need to take care all those mapping stuffs.


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

      reply	other threads:[~2003-10-09 17:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-09  4:11 General porting question Jacky Lam
2003-10-09  4:24 ` Bret Indrelee
2003-10-09  5:35 ` Matt Porter
2003-10-09  6:18   ` Jacky Lam
2003-10-09 13:38     ` Matt Porter
2003-10-09 15:36       ` Jacky Lam
2003-10-09 16:37         ` Matt Porter
2003-10-09 17:23           ` Jacky Lam [this message]

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='000b01c38e8a$0f4ef650$0202a8c0@homevl9biy3v7e' \
    --to=jackylam@astri.org \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.