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.
next parent reply other threads:[~2014-09-30 20:22 UTC|newest]
Thread overview: 19+ 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 2:09 ` Benjamin Herrenschmidt
2014-10-01 20:33 ` Bjorn Helgaas
2014-10-01 20:33 ` Bjorn Helgaas
2014-10-01 22:09 ` Benjamin Herrenschmidt
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 0:33 ` Benjamin Herrenschmidt
2014-10-02 1:48 ` Stephen Rothwell
2014-10-02 1:48 ` Stephen Rothwell
2014-10-02 0:34 ` Benjamin Herrenschmidt
2014-10-02 0:34 ` Benjamin Herrenschmidt
2014-10-02 15:31 ` Bjorn Helgaas
2014-10-02 15:31 ` Bjorn Helgaas
2014-10-02 21:01 ` Benjamin Herrenschmidt
2014-10-02 21:01 ` Benjamin Herrenschmidt
2014-10-02 21:46 ` Bjorn Helgaas
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 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.