[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02174460-87b8-bb1c-7b6f-39694fa416c3@starfivetech.com>
Date: Tue, 17 Jan 2023 15:45:22 +0800
From: Walker Chen <walker.chen@...rfivetech.com>
To: Conor Dooley <conor@...nel.org>
CC: <linux-riscv@...ts.infradead.org>, <linux-pm@...r.kernel.org>,
<devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor.dooley@...rochip.com>,
Emil Renner Berthing <emil.renner.berthing@...onical.com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 0/3] JH7110 PMU Support
On 2023/1/17 3:19, Conor Dooley wrote:
> Hey Walker,
>
> On Mon, Jan 16, 2023 at 03:42:56PM +0800, Walker Chen wrote:
>> Hello,
>>
>> This patchset adds PMU (Power Management Unit) controller driver for the
>> StarFive JH7110 SoC. In order to meet low power requirements, PMU is
>> designed for including multiple PM domains that can be used for power
>> gating of selected IP blocks for power saving by reduced leakage
>> current. The first patch adds device tree binding for PM domain provider
>> and consumer. The second patch adds pmu driver and support JH7110 SoC.
>> The last patch adds device node about pmu to JH7110 dts.
>>
>> The series has been tested on the VisionFive 2 boards which equip with
>> JH7110 SoC and works normally.
>
> For the series:
> Reviewed-by: Conor Dooley <conor.dooley@...rochip.com>
>
> I'm hoping that someone with knowledge of the power APIs will take a
> look now that the driver looks to be in a pretty good state (to my naive
> eyes at least).
>
>> Changes in v3:
>> - Rebased on tag v6.1.
>
> FYI, please pick something more recent than that.
> Ideally, the last -rc1, which in this case is v6.2-rc1.
OK, the next version will be rebased to the latest kernel.
> It's helpful to do this, as when I went to apply your patch, there were
> some conflicts that needed to be sorted out. Because of your prerequisite
> patches, the usual `b4` commands would not usable. E.g.
>
> b4 am -3 20230116074259.22874-1-walker.chen@...rfivetech.com
> Analyzing 4 messages in the thread
> Checking attestation on all messages, may take a moment...
> ---
> [PATCH v3 1/3] dt-bindings: power: Add starfive,jh7110-pmu
> [PATCH v3 2/3] soc: starfive: Add StarFive JH71XX pmu driver
> [PATCH v3 3/3] riscv: dts: starfive: add pmu controller node
> ---
> Total patches: 3
> Preparing fake-am for v3: JH7110 PMU Support
> ERROR: Could not find matching blob for MAINTAINERS (85e8f83161d7)
> If you know on which tree this patchset is based,
> add it as a remote and perform "git remote update"
> in order to fetch the missing objects.
>
> Fortunately, this is just a driver addition so despite `b4` not
> helping it was easy to resolve but for other patches in the future,
> this may not be the case.
>
> Assuming the dt maintainers are happy with the binding, ping me in 2
> weeks if no-one else has commented and I'll apply patches 1 & 2.
Could I drop patch 3 and rebase patch 1 & 2 on the latest mainline then submit as v4 ?
Best regards,
Walker
Powered by blists - more mailing lists