[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210224214528.GA511@duo.ucw.cz>
Date: Wed, 24 Feb 2021 22:45:28 +0100
From: Pavel Machek <pavel@....cz>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Álvaro Fernández Rojas <noltari@...il.com>,
linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] leds: bcm6328: improve write and read functions
Hi!
> > Less code duplication? It is immediately clear that driver including
> > this is specific for brcm SoCs and would not try to work somewhere else?
>
> Yes maybe, there still does not feel like this deserves a shared header,
> but as long as the generated code is the same, why not.
Ok, it seems patch is not needed at all, after all?
> >
> >> As far as using _relaxed() this is absolutely correct because the bus
> >> logic that connects the CPU to its on-chip registers is non re-ordering
> >> non posted. That is true on the MIPS BE/LE and ARM when configured in LE
> >> or BE.
> >
> > If that's right on particular SoC, then _relaxed and normal versions
> > should be same; drivers still need to use normal versions, because
> > they may be running on different SoC...?
>
> readl() includes barriers and read_relaxed() does not, hence the
> difference in the name. There is no need to pay the price of a barrier
> when a) the bus architecture guarantees non re-ordering and posting and
> that statement is true on all the SoCs where these peripherals are used,
> and b) you have worked on fine tuning your drivers to get the most
> performance out of them.
Exactly. When bus architecture guarantees ... readl and read_relaxed
can be the same. That knowledge should be in architecture code, not in
drivers.
(But it does not matter much when the drivers are
architecture-specific).
> Given these peripherals can only be used on CPUs/SoCs made by Broadcom,
> any argument about portability to other SoCs is moot.
Ok.
Pavel
--
http://www.livejournal.com/~pavelmachek
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists