On 12/09/16 02:51, Mars Cheng wrote:
> On Thu, 2016-09-08 at 15:32 +0100, Marc Zyngier wrote:
>> On 08/09/16 15:08, Mars Cheng wrote:
>>> Hi Marc
>>>
>>> Thanks for your review. the response inlined.
>>>
>>> On Thu, 2016-09-08 at 13:37 +0100, Marc Zyngier wrote:
>>>> On 08/09/16 11:49, Mars Cheng wrote:
>>>>> This adds DT binding documentation for Mediatek MT6797.
>>>>>
>>>>> Signed-off-by: Mars Cheng <mars.cheng@xxxxxxxxxxxx>
>>>>> ---
>>> [...]
>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
>>>>> index 9d1d72c..3d97eb4 100644
>>>>> --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
>>>>> +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
>>>>> @@ -8,6 +8,7 @@ Required properties:
>>>>> "mediatek,mt8173-sysirq"
>>>>> "mediatek,mt8135-sysirq"
>>>>> "mediatek,mt8127-sysirq"
>>>>> + "mediatek,mt6797-sysirq"
>>>>> "mediatek,mt6795-sysirq"
>>>>> "mediatek,mt6755-sysirq"
>>>>> "mediatek,mt6592-sysirq"
>>>>> @@ -21,7 +22,8 @@ Required properties:
>>>>> - interrupt-parent: phandle of irq parent for sysirq. The parent must
>>>>> use the same interrupt-cells format as GIC.
>>>>> - reg: Physical base address of the intpol registers and length of memory
>>>>> - mapped region.
>>>>> + mapped region. Could be up to 2 registers here at max. Ex: 6797 needs 2 reg,
>>>>> + others need 1.
>>>>
>>>> Two things:
>>>>
>>>> - Please make this a separate patch that can be reviewed independently
>>>> of the rest of the changes, which are just adding new compatible
>>>> identifiers.
>>>
>>> Will fix this in the next patch set.
>>>
>>>>
>>>> - Why can't you simply expose it as a separate controller? Looking at
>>>> the way you're changing the corresponding driver, it looks like you're
>>>> simply adding an extra base/size. If you simply had a base for the
>>>> corresponding GIC interrupts, you could handle as many region as you
>>>> want, and have a more generic driver.
>>>>
>>>
>>> May I know the meaning of "simply expose it as a separate controller"?
>>
>> At the moment, you have something like this:
>>
>> sysirq: intpol-controller@10200620 {
>> compatible = "mediatek,mt6755-sysirq",
>> "mediatek,mt6577-sysirq";
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> interrupt-parent = <&gic>;
>> reg = <0 0x10200620 0 0x20>;
>> };
>>
>> I suggest that, when you have a second base (which is effectively
>> another controller), you add:
>>
>> sysirq2: intpol-controller@10201620 {
>> compatible = "mediatek,mt6755-sysirq",
>> "mediatek,mt6577-sysirq";
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> interrupt-parent = <&gic>;
>> irq-base = <32>;
>> reg = <0 0x10201620 0 0x20>;
>> };
>>
>> Where irq-base is the first SPI this is connected to (the lack of
>> property indicates implies that irq-base is 0). This becomes a very
>> simple change in the driver.
>>
>>> Or you might like to suggest me any similar driver as a reference? I
>>> will examine it. Current design is based on the fact: We expect
>>> irq-mtk-sysirq needs the optional second base but the third one will not
>>> happen.
>>>
>>> If we really need more than 2 bases, we can figure out a more generic
>>> driver at the time, right?
>>
>> I'd rather fix the driver and the binding to do the right thing once and
>> for all. In my experience, you will need to add a third base in six
>> months, and a fourth soon after. I'd rather either support an arbitrary
>> number of bases, or a single one per controller (and have multiple
>> controllers).
> Hi Marc
>
> Thanks for suggesting this approach I never thought.
>
> However, I will modify the irq-mtk-sysirq driver to handle as many bases
> as we specify in current node in the next patch set. Will not use the
> second interrupt node in DT. The main reason is to simplify the writing
> of DT. Or we need to know which interrupt node to be specified for other
> nodes. As you said that might be the third or fourth bases, that will
> complicate the writing of DT more.
>
> Would you think this is OK?
There is still one thing that is not completely obvious to me: How do
you map a new set of registers to the corresponding base GIC SPI?
At the moment, this is an implicit SPI0 (hwirq 32 on the GIC). I don't
think assuming that all the banks will forever be contiguous is a safe
bet, so introducing some form of sparseness support seems beneficial.
As for simplifying the DT, I'm not convinced either. You already deal
with two interrupt controllers (the GIC and this intpol), which means
you need to locally annotate some DT nodes to point to the GIC. With my
scheme, you keep annotating more (or use the extended interrupt
specifier notation), but that doesn't feel like a massive burden. How
often do you write a DT from scratch?
Anyway, this is up to you. My only requirements is about being able to
support an arbitrary numbers of register sets, with arbitrary SPI bases.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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
