Date:	Thu, 4 Dec 2014 19:20:58 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Simon Horman <horms@...ge.net.au>,
	SH-Linux <linux-sh@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>
Subject: Re: [PATCH 02/02] ARM: shmobile: marzen-reference: Remove IRLM workaround

Hi Geert,

On Thu, Dec 4, 2014 at 6:31 PM, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> Hi Magnus,
>
> On Thu, Dec 4, 2014 at 10:24 AM, Magnus Damm <magnus.damm@...il.com> wrote:
>> On Thu, Dec 4, 2014 at 6:19 PM, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>>> On Thu, Dec 4, 2014 at 8:33 AM, Magnus Damm <magnus.damm@...il.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@...80010 {
>>>>>> +     irqpin0: irqpin@...80000 {
>>>>>>               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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists