linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dave Airlie <airlied@linux.ie>,
	Alex Deucher <alexdeucher@gmail.com>,
	Brian King <brking@linux.vnet.ibm.com>,
	linux-pci@vger.kernel.org, Yijing Wang <wangyijing@huawei.com>
Subject: Re: MSI address mask quirk issue
Date: Wed, 01 Oct 2014 06:21:04 +1000	[thread overview]
Message-ID: <1412108464.4285.154.camel@pasglop> (raw)
In-Reply-To: <CAErSpo4B6kuZJcKwreNvW1qC5sZ=1Ko71vbzNz7T8-_pjf7mww@mail.gmail.com>

On Tue, 2014-09-30 at 09:04 -0600, Bjorn Helgaas wrote:
> On Mon, Sep 29, 2014 at 9:40 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > Hi folks !

(Adding linux-pci and Yijing, which I stupidly forgot)

> > Some ATM devices have a limitation in the number of address bits they
> > can generate for MSI and MSI-X (similar to their DMA limitations).
> >
> > This makes it impossible to "reach" the MSI regions for 64-bit MSI on
> > our POWER server chips since those must have some of the top address
> > bits set.
> >
> > For DMA today, we have the DMA mask that handles that limitation fine
> > at the arch level.
> >
> > However we have nothing for MSIs.
> >
> > So far, we've workaround it with a kludge. We maintain a powerpc
> > specific flag in some auxilliary data structure that we keep along
> > with PCI devices and we have a quirk in arch/powerpc/kernel/pci_64.c
> > that will set that flag for some known devices.
> >
> > At this point we have only added two known ATI IDs corresponding to
> > radeons we ship with our machines, but as you can imagine, that not
> > a very good long term solution.
> >
> > Ideally we want that quirk to be set by the driver. The radeon driver
> > "knows" what the addressing capacity of the device it.
> >
> > So the easiest way to handle that for me would be to move that flag
> > "force_32bit_msi" from our arch data structure to pci_dev, and have
> > the radeon driver set it before it enables MSIs.
> >
> > However that would have the side effect of also limiting other archs
> > to 32-bit MSIs while the 40-bit of address (or so ....) that the radeon
> > supports might be sufficient for 64-bit MSIs to work on these.
> >
> > The slightly fancier approach would be to have something like an
> > msi64_set_address_mask() where the driver can configure the supported
> > mask for 64-bit MSIs.
> >
> > This would allow the architecture code to make a smarter decision based
> > on what is actually possible.
> >
> > Any preference, comment or suggestion ?
> 
> Please CC: linux-pci and Yijing Wang <wangyijing@huawei.com> unless
> there's something secret here.  I didn't add them myself in case you
> think this is sensitive.
> 
> If I understand correctly, per spec, devices can support MSI with
> either 32-bit or 64-bit addresses, and they advertise their capability
> via the "64 bit address capable" bit in the Message Control register.
> And per spec, devices that support MSI-X must support 64-bit
> addresses.
> 
> So apparently these devices are not spec compliant.  I suggest that
> you move the "force_32bit" flag into struct pci_dev, set it via a
> quirk, and change drivers/pci/msi.c to use it to override the
> "msi_attrib.is_64" settings in msi_setup_entry() and/or
> msix_setup_entries().
> 
> At this point, I don't see value in adding the complexity to support
> intermediate address sizes between 32 and 64 bits.

Ok, I tend to agree.

Cheers,
Ben.



       reply	other threads:[~2014-09-30 20:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1412048401.4285.128.camel@pasglop>
     [not found] ` <CAErSpo4B6kuZJcKwreNvW1qC5sZ=1Ko71vbzNz7T8-_pjf7mww@mail.gmail.com>
2014-09-30 20:21   ` Benjamin Herrenschmidt [this message]
     [not found]   ` <CADnq5_PT+dX=KA4epGNRaoraco2z1pe5K7UgqLmTUhWMnvtWkw@mail.gmail.com>
     [not found]     ` <1412108504.4285.155.camel@pasglop>
     [not found]       ` <CADnq5_O_iLAZUKLL4nph8VwuP2NOkWXhBZC2XTSkFm5P42WZ+g@mail.gmail.com>
     [not found]         ` <1412110946.4285.158.camel@pasglop>
     [not found]           ` <CADnq5_OXBax1+TKPsR2RDYTWijQKDVw34ECfWzcwN2SibCGYTg@mail.gmail.com>
     [not found]             ` <1412112324.4285.160.camel@pasglop>
2014-10-01  2:09               ` [PATCH 1/4] pci/msi: Move "force_32bit_msi" flag from powerpc to generic pci_dev Benjamin Herrenschmidt
2014-10-01 20:33                 ` Bjorn Helgaas
2014-10-01 22:09                   ` Benjamin Herrenschmidt
2014-10-02  0:33               ` [PATCH v2 1/4] pci/msi: Move "no_64bit_msi" " Benjamin Herrenschmidt
2014-10-02  1:48                 ` Stephen Rothwell
2014-10-02  0:34               ` Benjamin Herrenschmidt
2014-10-02 15:31                 ` Bjorn Helgaas
2014-10-02 21:01                   ` Benjamin Herrenschmidt
2014-10-02 21:46                     ` Bjorn Helgaas

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=1412108464.4285.154.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=airlied@linux.ie \
    --cc=alexdeucher@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=wangyijing@huawei.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 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).