linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tharvey@gateworks.com (Tim Harvey)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: imx_v6_v7_defconfig: enable PCI_MSI
Date: Tue, 11 Apr 2017 09:05:00 -0700	[thread overview]
Message-ID: <CAJ+vNU2MG66ruQ87TmSrVCtWfHwGc3s=_NG-ysgV2uyJzzskiQ@mail.gmail.com> (raw)
In-Reply-To: <1491394571.2904.44.camel@pengutronix.de>

On Wed, Apr 5, 2017 at 5:16 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Mittwoch, den 05.04.2017, 13:07 +0100 schrieb Joao Pinto:
> [...]
>> >>> Lucas,
>> >>>
>> >>> I feel a bit dumb here for forgetting about this issue and letting it
>> >>> drop, but I've just spent a day debugging an issue with the ath9k
>> >>> wireless driver only to realize it was that the ath9k card and/or
>> >>> driver doesn't support MSI interrupts and thus no longer work on
>> >>> mainline kernels that have MSI enabled. To be honest I'm not sure how
>> >>> many PCIe devices out there can't support MSI because of hardware
>> >>> limitations vs drivers that simply have not implemented it.
>> >>>
>> >>> To make matters worse 3ee803641e76bea76ec730c80dcc64739a9919ff makes
>> >>> it such that you can't disable MSI on the IMX6.
>> >>>
>> >>> Is there some fix you can think of to make the IMX6 PCIe host
>> >>> controller raise an interrupt for cards/drivers that use legacy irq's?
>> >>> If not, then we need to allow MSI to be disabled for IMX6 and default
>> >>> it to disabled for compatibility.
>> >>>
>> >>
>> >> Joao / Jingoo,
>> >>
>> >> (Adding linux-pci to the list to pick up maintainers of other DWC PCIe
>> >> core drivers)
>> >>
>> >> Is Luca's statement that 'legacy IRQs and MSIs can't be used together'
>> >> true in general for the DW PCIe core? If any of the host controllers
>> >> using this core can't support both legacy and MSI irqs together I
>> >> still believe we shouldn't enable/require MSI as it breaks any
>> >> card/driver that only supports legacy interrupts (such as ath9k).
>> >
>> > If there are 2 DW PCIe controllers, one controller can be used for legacy
>> > and another controller can be used for MSI.
>> >
>> > But, I am not sure that one DW PCIe controller can support both MSI device
>> > and legacy interrupt device at the same time.
>> >
>> > To Joao Pinto,
>> > Will you confirm this?
>> >
>>
>> Hi Jingoo,
>> I confirm that if a RC has MSI enable, it won't support legacy interrupts.
>
> Okay, so the only way to solve this in a generic way, that I can see at
> the moment is to defer MSI enable until the downstream device actually
> requests an MSI irq.
>
> Also we need to disable the MSI capability if any bridge device turns up
> during the bus topology scan, as we can have devices with conflicting
> requirements connected to the RC in that case.
>
> I'll cook up some patches to implement this.
>

Lucas,

Any thoughts yet? I'll likely want to backport this to stable although
the restructuring to drivers/pci/dwc and subsequent changes since 4.10
will likely require a re-written patch.

Best regards,

Tim

  reply	other threads:[~2017-04-11 16:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-30 17:00 [PATCH 1/2] ARM: imx6: remove config space from PCIe controller ranges property Lucas Stach
2015-11-30 17:00 ` [PATCH 2/2] ARM: imx_v6_v7_defconfig: enable PCI_MSI Lucas Stach
2015-12-02  8:03   ` Shawn Guo
2016-04-14 15:13   ` Tim Harvey
2016-04-15  8:21     ` Lucas Stach
2017-03-30 23:42       ` Tim Harvey
2017-03-31 16:05         ` Tim Harvey
2017-04-04 20:54           ` Jingoo Han
2017-04-05 12:07             ` Joao Pinto
2017-04-05 12:16               ` Lucas Stach
2017-04-11 16:05                 ` Tim Harvey [this message]
2017-04-26 11:50                   ` Lucas Stach
2015-12-02  8:01 ` [PATCH 1/2] ARM: imx6: remove config space from PCIe controller ranges property Shawn Guo

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='CAJ+vNU2MG66ruQ87TmSrVCtWfHwGc3s=_NG-ysgV2uyJzzskiQ@mail.gmail.com' \
    --to=tharvey@gateworks.com \
    --cc=linux-arm-kernel@lists.infradead.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 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).