public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: grundler@parisc-linux.org, matthew@wil.cx,
	jbarnes@virtuousgeek.org, mingo@elte.hu, tglx@linutronix.de,
	hpa@zytor.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH] pci: print out DMA mask info
Date: Thu, 09 Oct 2008 23:32:51 -0700	[thread overview]
Message-ID: <48EEF713.6050502@kernel.org> (raw)
In-Reply-To: <20081010150815B.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> On Thu, 9 Oct 2008 21:56:33 -0700
> "Yinghai Lu" <yinghai@kernel.org> wrote:
> 
>> On Thu, Oct 9, 2008 at 7:40 PM, FUJITA Tomonori
>> <fujita.tomonori@lab.ntt.co.jp> wrote:
>>> On Thu, 09 Oct 2008 16:05:57 -0700
>>> Yinghai Lu <yinghai@kernel.org> wrote:
>>>
>>>> Grant Grundler wrote:
>>>>> On Thu, Oct 09, 2008 at 02:51:32PM -0700, Yinghai Lu wrote:
>>>>>> On Thu, Oct 9, 2008 at 2:35 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>>>>>>> Why's that interesting to the sysadmin of the machine?  To the driver
>>>>>>> writer, certainly.  But what's the use of it to the people using the
>>>>>>> machine?
>>>>> ...
>>>>>> make linux kernel act like black box as other os?
>>>>> I don't understand your reply.
>>>>> If someone thinks linux is a black box, printing this message won't help them.
>>>>>
>>>> could find out easily why some driver doesn't set dma mask correctly.
>>>> like why
>>>>       qlogic qla2xxx only set consistent to 64bit,
>>>>       emulex lpfc not set consistent to 64bit
>>> IIRC, except for one SGI architecture, coherent_dma_mask is
>>> meaningless, dma_mask is always equal to coherent_dma_mask. Lots of
>>> IOMMU implementations ignore coherent_dma_mask and use dma_mask for
>>> alloc_coherent(). Some drivers doesn't set up coherent_dma_mask.
>> ehci_hcd 0000:00:02.1: using 31bit consistent DMA mask
>> ==> ck804 ehci, is using 31bit for consistent dma mask, at still use
>> 32 bit for dma mask.
> 
> ehci_hcd needs to set 31bit to dma_mask, I guess.

in ehci_pci_setup() 

        switch (pdev->vendor) {
        case PCI_VENDOR_ID_NVIDIA:
                /* NVidia reports that certain chips don't handle
                 * QH, ITD, or SITD addresses above 2GB.  (But TD,
                 * data buffer, and periodic schedule are normal.)
                 */
                switch (pdev->device) {
                case 0x003c:    /* MCP04 */
                case 0x005b:    /* CK804 */
                case 0x00d8:    /* CK8 */
                case 0x00e8:    /* CK8S */
                        if (pci_set_consistent_dma_mask(pdev,
                                                DMA_31BIT_MASK) < 0)
                                ehci_warn(ehci, "can't enable NVidia "
                                        "workaround for >2GB RAM\n");
                        break;
                }
                break;
        }

so that is strange silicon bug for old ck804 and before. dma_mask could be 32bit. but consistent_dma_mask is 31bit
mcp55 is ok.


> 
> 
>> qlogic qla2xxx  and emulex lpfc dma mask and consistent_dma_mask is different...
>> could have some story for them
> 
> Check out qla2xxx again. I think that it uses dma_set_mask() to set
> dma_mask. qla2xxx uses the same value for both dma_mask and
> consistent_dma_mask.
> 
> lpfc had better set 64bit to consistent_dma_mask but as I said in the
> previous mail, not setting consistent_dma_mask doesn't cause any
> problem. It means that some IOMMUs (uses consistent_dma_mask properly)
> allocates an address < 4GB in alloc_coherent() and some IOMMUs alloc
> address > 4GB. lpfc can handle both anyway.
> 
> 
>> at least gart iommu is honoring the consistent dma mask.
>> by calling dma_alloc_coherent_mask(dev, flag)
> 
> Well, that's because I wrote gart's alloc_coherent and introduced
> dma_alloc_coherent_mask. ;)

oh. it is in tip

> 
> 
>> if device could use 64 bit coherent dma mask, that is driver problem...
> 
> Can you be more specific? As I wrote above, if 64bit-dma-capable
> devices don't set consistent_dma_mask, we don't have any problem.

then can we remove consistent_dma_mask? just use dma_mask instead for all.

> 
> Yes, drivers that have dma_mask < 32bit need to set up
> consistent_dma_mask. But few devices have dma_mask < 32bit and we can
> fix them without the information at boot time, I think.

YH

  reply	other threads:[~2008-10-10  6:35 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-08 23:02 [PATCH] pci: print out DMA mask info Yinghai Lu
2008-10-09 21:18 ` Grant Grundler
2008-10-09 21:27   ` Yinghai Lu
2008-10-09 21:35     ` Matthew Wilcox
2008-10-09 21:51       ` Yinghai Lu
2008-10-09 22:55         ` Grant Grundler
2008-10-09 23:05           ` Yinghai Lu
2008-10-10  2:40             ` FUJITA Tomonori
2008-10-10  4:56               ` Yinghai Lu
2008-10-10  6:08                 ` FUJITA Tomonori
2008-10-10  6:32                   ` Yinghai Lu [this message]
2008-10-10  7:32                     ` FUJITA Tomonori
2008-10-12  7:16                       ` Grant Grundler
2008-10-10 22:45               ` Grant Grundler
2008-10-14  6:50                 ` FUJITA Tomonori
2008-10-12  7:11             ` Grant Grundler
2008-10-23  1:45               ` [PATCH] pci: show dma_mask bits in /sys Yinghai Lu
2008-10-23  3:28                 ` Matthew Wilcox
2008-10-23  4:19                   ` Yinghai Lu
2008-10-23  6:44                   ` Grant Grundler
2008-10-23  8:38                     ` Rolf Eike Beer
2008-10-23 15:39                     ` Greg KH
2008-10-23 18:37                       ` H. Peter Anvin
2008-10-23 19:36                       ` Grant Grundler
2008-10-23 19:49                         ` Greg KH
2008-10-24 10:50                     ` Andi Kleen
2008-11-01 17:10                       ` Grant Grundler
2008-10-23  6:48                 ` Grant Grundler
2008-10-23  6:51                   ` Yinghai Lu
2008-10-23 19:28                     ` Grant Grundler
2008-10-10  2:40     ` [PATCH] pci: print out DMA mask info FUJITA Tomonori
2008-10-10  2:59       ` FUJITA Tomonori
2008-10-10  2:40   ` FUJITA Tomonori
2008-10-10 15:48     ` Jesse Barnes
2008-10-10 16:19       ` Yinghai Lu
2008-10-10 16:28         ` Jesse Barnes
2008-10-10 16:33         ` Matthew Wilcox
2008-10-10 16:46           ` Yinghai Lu
2008-10-10 17:12             ` Matthew Wilcox
2008-10-10 17:18               ` Roland Dreier
2008-10-12  7:38                 ` Grant Grundler
2008-10-12  7:20       ` Grant Grundler

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=48EEF713.6050502@kernel.org \
    --to=yinghai@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=grundler@parisc-linux.org \
    --cc=hpa@zytor.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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