Hi Geert,
On Thu, Dec 4, 2014 at 6:31 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
> Hi Magnus,
>
> On Thu, Dec 4, 2014 at 10:24 AM, Magnus Damm <magnus.d...@gmail.com> wrote:
>> On Thu, Dec 4, 2014 at 6:19 PM, Geert Uytterhoeven <ge...@linux-m68k.org>
>> wrote:
>>> On Thu, Dec 4, 2014 at 8:33 AM, Magnus Damm <magnus.d...@gmail.com> wrote:
>>>>>> --- 0002/arch/arm/boot/dts/r8a7779.dtsi
>>>>>> +++ work/arch/arm/boot/dts/r8a7779.dtsi 2014-12-03
>>>>>> 20:27:49.000000000 +0900
>>>>>> @@ -139,7 +139,7 @@
>>>>>> interrupt-controller;
>>>>>> };
>>>>>>
>>>>>> - irqpin0: irqpin@fe780010 {
>>>>>> + irqpin0: irqpin@fe780000 {
>>>>>> compatible = "renesas,intc-irqpin-r8a7779",
>>>>>> "renesas,intc-irqpin";
>>>>>> #interrupt-cells = <2>;
>>>>>> status = "disabled";
>>>>>> @@ -148,7 +148,8 @@
>>>>>> <0xfe780010 4>,
>>>>>> <0xfe780024 4>,
>>>>>> <0xfe780044 4>,
>>>>>> - <0xfe780064 4>;
>>>>>> + <0xfe780064 4>,
>>>>>> + <0xfe780000 4>;
>>>>>
>>>>> Is there any order implied by the above list?
>>>>> Naïvely I would expect it to be sorted numerically.
>>>>
>>>> Yes, the driver assumes the register banks to be passed in a certain
>>>> order. In the case of r8a7779 we add one more register bank at the end
>>>> for IRLM setup. Register detail (base address, access size, order and
>>>> bitfield width) varies with SoC version. So the IRLM register will be
>>>> at different addresses depending on SoC, but the driver wants it at
>>>> the end of the list.
>>>
>>> As these are all individual registers, and there are that many, I think
>>> it's worth adding a reg-names property to identify the registers.
>>> Of course the driver still has to support the old anonymous order
>>> for backwards compatibility.
>>
>> If we should rework things, then I propose going the other way around.
>> =) Basically only passing a single base address with a certain SoC
>> specific compat string, and based on that letting the driver
>> internally figure out which register is at what offset and the access
>> size and bitfield size.
>
> That's gonna mean a complete new compatible value.
> Seems like we shouldn't have added "renesas,intc-irqpin-r8a7779",
> as the SoC-type was encoded in the reg properties...
Yeah, having that SoC specific compat string in the DTS does not
exactly help us that this point. We could however use a slightly
different SoC compat string or something else that is unused if we
wanted to change things around.
>> Either way we have a limited number of SoCs and they are all old.
>
> So your current patch looks like the best option for now
> (can you promise future R-Car SoCs won't have an intc-irqpin hardware
> block ;-)?
Hehe, almost. =)
I think I can promise that R-Car hardware won't use that hardware -
the IRQC hardware block replaced INTC-IRQPIN in R-Car Gen2 and it will
most likely not make a comeback. However, other SoC product lines may
show up with old interrupt controllers. But if so we can rework things
at that point and make use of a fresh compatible string for a clean
start.
Cheers,
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
