On Mon, Apr 25, 2022 at 9:46 PM Brian Norris <[email protected]> wrote:
>
> It's unclear if these are really needed at all, but seemingly their
> purpose is only as a write barrier. Use the general macro instead of the
> ARM-specific one.
>
> This driver is partially marked for COMPILE_TEST'ing, but it doesn't
> build under non-ARM architectures. Fix this up before *really* enabling
> it for COMPILE_TEST.
>
> Signed-off-by: Brian Norris <[email protected]>
> ---
>
> Changes in v3:
> * New in v3
>
> drivers/soc/rockchip/pm_domains.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
> index 1b029e494274..cf16ff9b73b3 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -178,7 +178,7 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
> regmap_update_bits(pmu->regmap, pmu->info->req_offset,
> pd_info->req_mask, idle ? -1U : 0);
>
> - dsb(sy);
> + wmb();
Just curious, shouldn't this be mb() instead of wmb()?
From the arm64 barrier.h:
#define mb() dsb(sy)
#define wmb() dsb(st)
>
> /* Wait util idle_ack = 1 */
> target_ack = idle ? pd_info->ack_mask : 0;
> @@ -285,7 +285,7 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
> regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
> pd->info->pwr_mask, on ? 0 : -1U);
>
> - dsb(sy);
> + wmb();
>
> if (readx_poll_timeout_atomic(rockchip_pmu_domain_is_on, pd, is_on,
> is_on == on, 0, 10000)) {
> --
> 2.36.0.rc2.479.g8af0fa9b8e-goog
>
>
> _______________________________________________
> Linux-rockchip mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 2022-04-27 00:55, Peter Geis wrote:
> On Mon, Apr 25, 2022 at 9:46 PM Brian Norris <[email protected]> wrote:
>>
>> It's unclear if these are really needed at all, but seemingly their
>> purpose is only as a write barrier. Use the general macro instead of the
>> ARM-specific one.
>>
>> This driver is partially marked for COMPILE_TEST'ing, but it doesn't
>> build under non-ARM architectures. Fix this up before *really* enabling
>> it for COMPILE_TEST.
>>
>> Signed-off-by: Brian Norris <[email protected]>
>> ---
>>
>> Changes in v3:
>> * New in v3
>>
>> drivers/soc/rockchip/pm_domains.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
>> index 1b029e494274..cf16ff9b73b3 100644
>> --- a/drivers/soc/rockchip/pm_domains.c
>> +++ b/drivers/soc/rockchip/pm_domains.c
>> @@ -178,7 +178,7 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
>> regmap_update_bits(pmu->regmap, pmu->info->req_offset,
>> pd_info->req_mask, idle ? -1U : 0);
>>
>> - dsb(sy);
>> + wmb();
>
> Just curious, shouldn't this be mb() instead of wmb()?
> From the arm64 barrier.h:
>
> #define mb() dsb(sy)
> #define wmb() dsb(st)
As I mentioned on v2, that would be the literal translation, however
there's no concurrency since this is happening under a mutex, so there's
no other agent against whose accesses loads would need to be
synchronised, therefore the only logical reason those DSBs were ever
there at all must be to ensure that the prior store(s) have been issued
to their destination before proceeding. The history implies that this
dates all the way back to RK3288, where Armv7's argument-less DSB lacked
that distinction anyway.
Robin.
>>
>> /* Wait util idle_ack = 1 */
>> target_ack = idle ? pd_info->ack_mask : 0;
>> @@ -285,7 +285,7 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
>> regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
>> pd->info->pwr_mask, on ? 0 : -1U);
>>
>> - dsb(sy);
>> + wmb();
>>
>> if (readx_poll_timeout_atomic(rockchip_pmu_domain_is_on, pd, is_on,
>> is_on == on, 0, 10000)) {
>> --
>> 2.36.0.rc2.479.g8af0fa9b8e-goog
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
On Tue, Apr 26, 2022 at 5:25 PM Robin Murphy <[email protected]> wrote:
> On 2022-04-27 00:55, Peter Geis wrote:
> > On Mon, Apr 25, 2022 at 9:46 PM Brian Norris <[email protected]> wrote:
> >>
> >> It's unclear if these are really needed at all, but seemingly their
> >> purpose is only as a write barrier. Use the general macro instead of the
> >> ARM-specific one.
...
> >> - dsb(sy);
> >> + wmb();
> >
> > Just curious, shouldn't this be mb() instead of wmb()?
> > From the arm64 barrier.h:
> >
> > #define mb() dsb(sy)
> > #define wmb() dsb(st)
>
> As I mentioned on v2, that would be the literal translation, however
> there's no concurrency since this is happening under a mutex, so there's
> no other agent against whose accesses loads would need to be
> synchronised, therefore the only logical reason those DSBs were ever
> there at all must be to ensure that the prior store(s) have been issued
> to their destination before proceeding. The history implies that this
> dates all the way back to RK3288, where Armv7's argument-less DSB lacked
> that distinction anyway.
Thanks Robin. I already tried to capture part of this in the commit message:
"It's unclear if these are really needed at all, but seemingly their
purpose is only as a write barrier."
i.e., it's intentional that I'm making a change, not a literal translation.
I ran through a few tests on Rockchip RK3399, FWIW, although I suppose
some nasty memory ordering bugs are not exactly the kind of thing that
would fall out in smoke tests.
Brian