All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ronny.Hegewald@online.de
Cc: xen-devel@lists.xensource.com
Subject: Re: pvops dom0: no sound after boot; possibly caused by swiotlb
Date: Tue, 2 Feb 2010 19:31:16 -0500	[thread overview]
Message-ID: <20100203003116.GA9888@phenom.dumpdata.com> (raw)
In-Reply-To: <13571067.3909201265156665171.JavaMail.servlet@kundenserver>

> But thats not quite all whats dma_alloc_coherent does. As it only returns a 32-bit variable all coherent_dma_mask over 32-bit get casted down. This way bare-metal makes sure that the dma-mask is never over 32-bit.

Ooooh. I completly failed to notice that your dom0 was 32-bit.

But having that there would make the mask always be below
4GB, irregardless if the dom0 is 32 or 64-bit. Which is
exactly what it does on bare-metal. Hmmm, ok: 

http://kerneltrap.org/mailarchive/git-commits-head/2008/10/28/3841954

shows what made that happen.

I am bit worried on the casting - it does not seem to have been the
purpose of that change to utilize that, but that is a upstream problem.

I am curious - if you dom0 is 64-bit, does the sound card work?
> 
> Or are you are saying that when the hardware supports 64 bit and has set the coherent_dma_mask accordingly and dom0 is 32-bit that the allocation of DMA after the 4 GB should work fine? Because thats the assumption i see in the pvops-code.

Yes. It should have worked fine.

> 
> And from what i understood so far the DMA memory should be allocated preferably in the 24-bit address space or max. 32 bit address space, at least in a 32-bit kernel. 
> 
> >The only difference here is that under pvops we behave badly with
> >devices that have GFP_DMA set and don't have the coherent_dma_mask
> >(which it does not seem to be the case?).
> 
> As i understand it the opposite is the case. If coherent_dma_mask is not set xen_swiotlb_alloc_coherent sets it to 32-bit. That should work usually (except the device needs the dma-memory in the 24-bit space). 
> 

You are right.

  reply	other threads:[~2010-02-03  0:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03  0:24 pvops dom0: no sound after boot; possibly caused by swiotlb Ronny.Hegewald
2010-02-03  0:31 ` Konrad Rzeszutek Wilk [this message]
2010-02-03  1:26   ` Konrad Rzeszutek Wilk
  -- strict thread matches above, loose matches on Subject: below --
2010-01-26  0:40 Ronny.Hegewald
2010-01-26  7:37 ` Keir Fraser
2010-01-26 15:05 ` Konrad Rzeszutek Wilk

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=20100203003116.GA9888@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ronny.Hegewald@online.de \
    --cc=xen-devel@lists.xensource.com \
    /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.