On 01/06/2016 01:34 PM, Rob Herring wrote:
> On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <nm@xxxxxx> wrote:
>> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>>
>>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>>>> Hi,
>>>>
>>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@xxxxxx>:
>>>>
>>>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>>>>> + rtc {
>>>>>> + compatible = "ti,palmas-rtc";
>>>>>> + interrupt-parent = <&palmas>;
>>>>>> + interrupts = <8 IRQ_TYPE_NONE>;
>>>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>>>> it had none, there'd be no interrupt, right?
>>>> Well, it just translates IRQ_TYPE_NONE through
>>>>
>>>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>>>
>>>> to
>>>>
>>>> interrupts = <8 0>;
>>>>
>>>> which is given as an example in
>>>>
>>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>>>
>>>> Since I don't know anything about the rtc driver beyond the bindings
>>>> documentation I assume it is correct...
>>>> I have added Laxman Dewangan because he introduced this interrupts =
>>>> <8 0>;
>>>>
>>>
>>> As this is for palmas interrupt controller, it does not use the second
>>> field for interrupt from RTC.
>>> So there is no really any polarity. It can be set to 0.
>>>
>>> The second argument will be used for GPIOs mainly. However, support need
>>> to be added on GPIO driver for rising/falling configuration.
>>
>>
>> Device tree represents the hardware - not to reflect how the driver
>> works. if the driver is wrong, fix it. the interrupt polarity needs to
>> be described in DT. based on palmas like designs, you should probably
>> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
>> the SoC as it reaches Secondary interrupt handlers(SIH) registers.
>
> If the trigger type is not programmable, then not setting the trigger
> type in the DT is fine. Internal connections are often not documented.
>
Weird, that is not what I got feedback when I send
https://patchwork.ozlabs.org/patch/381125/
If this is the new norm, I retract my objection.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
