Re: [PATCH 17/24] arm64: dts: qcom: glymur-crd: Avoid RTC probe failure

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 10/14/25 2:36 PM, Kamal Wadhwa wrote:
> Hi Konrad, 
> 
> On Tue, Oct 14, 2025 at 12:23:23PM +0200, Konrad Dybcio wrote:
>> On 10/13/25 1:04 PM, Kamal Wadhwa wrote:
>>> On Mon, Oct 06, 2025 at 04:28:59PM +0200, Konrad Dybcio wrote:
>>>> On 10/1/25 2:23 PM, Kamal Wadhwa wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Thu, Sep 25, 2025 at 1:41 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>>>
>>>>>> On Thu, 25 Sept 2025 at 15:34, Pankaj Patil
>>>>>> <pankaj.patil@oss.qualcomm.com> wrote:
>>>>>>>
>>>>>>> From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
>>>>>>>
>>>>>>> On Glymur boards, the RTC alarm interrupts are routed to SOCCP
>>>>>>> subsystems and are not available to APPS. This can cause the
>>>>>>> RTC probe failure as the RTC IRQ registration will fail in
>>>>>>> probe.
>>>>>>>
>>>>>>> Fix this issue by adding `no-alarm` property in the RTC DT
>>>>>>> node. This will skip the RTC alarm irq registration and
>>>>>>> the RTC probe will return success.
>>>>>>
>>>>>>
>>>>>> This is ridiculous. You just added glymur CRD and you claim now that
>>>>>> it's broken and you need to fix it. So just fix that commit!
>>>>>
>>>>> I'm afraid, but this is an actual limitation we have for Glymur
>>>>> (compared to Kaanapali).
>>>>> The RTC is part of the pmk8850.dtsi that is common between Kaanapali and
>>>>> Glymur. On Glymur (unlike Kaanapali) the APPS processor does *not* have the RTC
>>>>> IRQ permission for the RTC peripheral.
>>>>
>>>> This is interesting.. is that a physical limitation, or some sort of
>>>> a software security policy?
>>>
>>> This is mostly a limitation for all compute targets(like Glymur). On compute
>>> targets we need to support ACPI TAD feature[1] this feature uses the RTC alarm.
>>> In a nutshell, this feature implements 2 times - AC ( adaptor power) and
>>> DC (battery power) timers, and based on active power source(AC or DC?) at the
>>> time of timer expiry device will either go for a full bootup or stay in power
>>> down.
>>>
>>> This feature is implemented on a different subsystem (SoCCP subsystem), and
>>> since the SPMI `IRQ` permissions can only be assigned to only one subsystem,
>>> so we can't use the alarms on APPS. This is why we use no-alarms DT to register
>>> RTC device without alarm-irq support.
>>>
>>> [1] TAD specification - https://uefi.org/sites/default/files/resources/ACPI_5.pdf
>>> section 9.18
>>
>> Hm, is there maybe some sort of an interface to talk to the SoCCP
>> and set the RTC as we wish, from the OS?
> 
> Yes, the developement is almost done and we have done some testing as well, but
> that kernel driver needs some more cleanup and testing before posting to
> upstream. This will be added in future.

Thank you. Like Dmitry mentioned, please leave a comment about this

Konrad