On Thu, Nov 2, 2017 at 12:47 PM, Matthias Brugger
<matthias.bgg@xxxxxxxxx> wrote:
> Hi Arnd,
>
> On 10/31/2017 05:19 AM, Ryder Lee wrote:
>> Hi Arnd,
>>
>> We have 3 root ports in MT7623, but this is a bug in this chip where the
>> HW designers wired the IRQs in a nonstandard way. We've tried to
>> statically assign the bus portion of the address part in the parent
>> interrupt-map before, but this approach cannot handle the case - if we
>> attach the device in random order.
>>
>
> Ryder, please don't top post :)
>
>> Thanks.
>>
>> On Mon, 2017-10-30 at 13:42 +0100, Arnd Bergmann wrote:
>>> On Mon, Oct 23, 2017 at 12:06 AM, Matthias Brugger
>>> <matthias.bgg@xxxxxxxxx> wrote:
>>>>
>>>> ----------------------------------------------------------------
>>>> - mt76233 add PCIe node
>>>
>>> Could you clarify what the subnodes in the PCI node are for? It seems odd
>>> to have "interrupt-map" properties in both the pcie controller and its child
>>> nodes, and I want to ensure this is following the standard PCIe binding before
>>> I pull it.
>>>
>
> Arnd, I didn't found the pull request in your next/dt branch.
> Is there more clarification needed from our side?
I'm still unsure about it., this looks like exactly the thing that the top-level
interrupt-map is supposed to handle fine.
Can you send a pull request for the series without the pci child nodes for the
moment while we figure out what the exact problem is? We can take
whatever fix we come up with during the v4.15 -rc cycle then.
I would assume that either the parent interrupt-map is wrong, or something
broke the parser, but that it's not actually something that's wrong in the
hardware design in a way that we can't already handle in a standard way.
Ryder, can you be more specific how the interrupts are wired up?
Is there one IRQ per slot that is connected to all of IntA/IntB/IntC/IntD
and gets propagated through the bridges like that, or is it something else?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
