[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c39eab66-4e78-4f24-bcaf-003161b38ed0@kernel.org>
Date: Fri, 3 May 2024 11:13:06 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: André Draszik <andre.draszik@...aro.org>,
Tudor Ambarus <tudor.ambarus@...aro.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Alim Akhtar <alim.akhtar@...sung.com>,
Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Tomasz Figa <tomasz.figa@...il.com>,
Peter Griffin <peter.griffin@...aro.org>
Cc: Will McVicker <willmcvicker@...gle.com>,
Sam Protsenko <semen.protsenko@...aro.org>, kernel-team@...roid.com,
linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org,
linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] pinctrl: samsung: support a bus clock
On 02/05/2024 12:41, André Draszik wrote:
> On Thu, 2024-05-02 at 09:46 +0200, Krzysztof Kozlowski wrote:
>> On 02/05/2024 09:41, Tudor Ambarus wrote:
>>>>
>>>> @@ -223,6 +268,13 @@ static void exynos_irq_release_resources(struct irq_data *irqd)
>>>> shift = irqd->hwirq * bank_type->fld_width[PINCFG_TYPE_FUNC];
>>>> mask = (1 << bank_type->fld_width[PINCFG_TYPE_FUNC]) - 1;
>>>>
>>>> + if (clk_enable(bank->drvdata->pclk)) {
>>>> + dev_err(bank->gpio_chip.parent,
>>>> + "unable to enable clock for deconfiguring pin %s-%lu\n",
>>>> + bank->name, irqd->hwirq);
>>>> + return;
>>>
>>> but here we just print an error. I guess that for consistency reasons it
>>> would be good to follow up with a patch and change the return types of
>>> these methods and return the error too when the clock enable fails.
>>
>> That's a release, so usually void callback. The true issue is that we
>> expect release to always succeed, I think.
>>
>> This points to issue with this patchset: looks like some patchwork all
>> around the places having register accesses. But how do you even expect
>> interrupts and pins to work if entire pinctrl block is clock gated?
>
> I was initially thinking the same, but the clock seems to be required for
> register access only, interrupts are still being received and triggered
> with pclk turned off as per my testing.
Probably we could simplify this all and keep the clock enabled always,
when device is not suspended. Toggling clock on/off for every pin change
is also an overhead. Anyway, I merged the patches for now, because it
addresses real problem and seems like one of reasonable solutions.
Best regards,
Krzysztof
Powered by blists - more mailing lists