From: "Nuno Sá" <noname.nuno@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Michael Walle" <mwalle@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
linux-doc@vger.kernel.org,
"Linus Walleij" <linus.walleij@linaro.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Nicolas Ferre" <nicolas.ferre@microchip.com>,
"Paul Cercueil" <paul@crapouillou.net>,
linux-tegra@vger.kernel.org,
"Conor Dooley" <conor.dooley@microchip.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"James Clark" <james.clark@arm.com>,
"Pavel Machek" <pavel@ucw.cz>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
"Guenter Roeck" <groeck@chromium.org>,
chrome-platform@lists.linux.dev,
"Nobuhiro Iwamatsu" <nobuhiro1.iwamatsu@toshiba.co.jp>,
"Fabio Estevam" <festevam@gmail.com>,
linux-riscv@lists.infradead.org,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
"Jerome Brunet" <jbrunet@baylibre.com>,
"Rob Herring" <robh@kernel.org>,
"Samuel Holland" <samuel@sholland.org>,
linux-samsung-soc@vger.kernel.org,
"Bjorn Andersson" <quic_bjorande@quicinc.com>,
"Florian Fainelli" <florian.fainelli@broadcom.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Sean Anderson" <sean.anderson@seco.com>,
"Benson Leung" <bleung@chromium.org>,
"Bartosz Golaszewski" <brgl@bgdev.pl>,
"Lee Jones" <lee@kernel.org>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Hammer Hsieh" <hammerh0314@gmail.com>,
linux-rockchip@lists.infradead.org,
"Chen-Yu Tsai" <wens@csie.org>,
"Michal Simek" <michal.simek@amd.com>,
"NXP Linux Team" <linux-imx@nxp.com>,
linux-leds@vger.kernel.org,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Alim Akhtar" <alim.akhtar@samsung.com>,
linux-mips@vger.kernel.org, linux-sunxi@lists.linux.dev,
platform-driver-x86@vger.kernel.org, linux-pwm@vger.kernel.org,
"Kees Cook" <keescook@chromium.org>,
"Sven Peter" <sven@svenpeter.dev>,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Ray Jui" <rjui@broadcom.com>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
"Vladimir Zapolskiy" <vz@mleia.com>,
"Hans de Goede" <hdegoede@redhat.com>,
"Mark Brown" <broonie@kernel.org>,
linux-mediatek@lists.infradead.org,
linux-rpi-kernel@lists.infradead.org,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
linux-amlogic@lists.infradead.org,
"Orson Zhai" <orsonzhai@gmail.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Alexander Shiyan" <shc_work@mail.ru>,
"Scott Branden" <sbranden@broadcom.com>,
linux-gpio@vger.kernel.org,
"Daire McNamara" <daire.mcnamara@microchip.com>,
"Chunyan Zhang" <zhang.lyra@gmail.com>,
"Hector Martin" <marcan@marcan.st>,
linux-stm32@st-md-mailman.stormreply.com,
"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"Fabrice Gasnier" <fabrice.gasnier@foss.st.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
asahi@lists.linux.dev,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Kevin Hilman" <khilman@baylibre.com>,
"Shawn Guo" <shawnguo@kernel.org>,
"Anjelique Melendez" <quic_amelende@quicinc.com>
Subject: Re: [PATCH v6 003/164] pwm: Provide pwmchip_alloc() function and a devm variant of it
Date: Thu, 15 Feb 2024 14:51:31 +0100 [thread overview]
Message-ID: <63b248efcbd62a121610cbf37ea0339bd87c99e7.camel@gmail.com> (raw)
In-Reply-To: <ws4ybgtvfxqz53vk3i67suipzyqpy5y5fqeee5uf3ua6ow222n@i4ktjuorq3nl>
On Thu, 2024-02-15 at 13:01 +0100, Uwe Kleine-König wrote:
> On Wed, Feb 14, 2024 at 02:49:26PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 14, 2024 at 10:30:50AM +0100, Uwe Kleine-König wrote:
> > > This function allocates a struct pwm_chip and driver data. Compared to
> > > the status quo the split into pwm_chip and driver data is new, otherwise
> > > it doesn't change anything relevant (yet).
> > >
> > > The intention is that after all drivers are switched to use this
> > > allocation function, its possible to add a struct device to struct
> > > pwm_chip to properly track the latter's lifetime without touching all
> > > drivers again. Proper lifetime tracking is a necessary precondition to
> > > introduce character device support for PWMs (that implements atomic
> > > setting and doesn't suffer from the sysfs overhead of the /sys/class/pwm
> > > userspace support).
> > >
> > > The new function pwmchip_priv() (obviously?) only works for chips
> > > allocated with pwmchip_alloc().
> >
> > ...
> >
> > > +#define PWMCHIP_ALIGN ARCH_DMA_MINALIGN
> > > +
> > > +static void *pwmchip_priv(struct pwm_chip *chip)
> > > +{
> > > + return (void *)chip + ALIGN(sizeof(*chip), PWMCHIP_ALIGN);
> > > +}
> >
> > Why not use dma_get_cache_alignment() ?
>
> Hmm, that function returns 1 if ARCH_HAS_DMA_MINALIGN isn't defined. The
> idea of using ARCH_DMA_MINALIGN was to ensure that the priv data has the
> same minimal alignment as kmalloc(). Took my inspriration from
> https://lore.kernel.org/r/20240209-counter-align-fix-v2-1-5777ea0a2722@analog.com
> . The implementation of dma_get_cache_alignment suggests that not all
> archs provide ARCH_DMA_MINALIGN? Also there is ARCH_KMALLOC_MINALIGN.
> Hmm, don't know yet what to do here.
Here it goes my 2 cents... AFAIK, ARCH_DMA_MINALIGN gives you the same alignment
guarantees than devm_kmalloc() for instance. In some archs it will effectively be the
same as ARCH_KMALLOC_MINALIGN. Now, I think it only matters if the owners of private
data intend to have a DMA safe buffer in their structs. If that is the case, we need
to ensure a proper alignment for that structure. In IIO for example, the construct is
like this:
https://elixir.bootlin.com/linux/latest/source/drivers/iio/dac/ltc2688.c#L96
The buffers should come last in the struct so they are alone in the line. In IIO,
Jonathan has a strict policy for this. Like, even if you just want to transfer 2/4
bytes via spi, we need to make the buffer safe (apparently there are some controllers
only doing DMA - even for small transfers).
I would say that if unsure, go with ARCH_DMA_MINALIGN. You just might waste some
space in some archs. OTOH, if you think DMA is not really a thing for pwm chips, you
might go ARCH_KMALLOC_MINALIGN. And since you already have your own PWMCHIP_ALIGN, it
should be easy to change the requirements down the road (if needed).
That said, I'm not familiar with dma_get_cache_alignment().
- Nuno Sá
next prev parent reply other threads:[~2024-02-15 13:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
2024-02-14 9:30 ` [PATCH v6 003/164] pwm: Provide pwmchip_alloc() function and a devm variant of it Uwe Kleine-König
2024-02-14 12:49 ` Andy Shevchenko
2024-02-15 12:01 ` Uwe Kleine-König
2024-02-15 13:51 ` Nuno Sá [this message]
2024-02-14 9:31 ` [PATCH v6 067/164] pwm: lpss-*: Make use of devm_pwmchip_alloc() function Uwe Kleine-König
2024-02-14 12:46 ` Andy Shevchenko
2024-02-14 16:01 ` Uwe Kleine-König
2024-02-14 16:09 ` Andy Shevchenko
2024-02-14 17:04 ` Uwe Kleine-König
2024-02-14 15:39 ` Uwe Kleine-König
2024-02-14 9:33 ` [PATCH v6 151/164] gpio: mvebu: " Uwe Kleine-König
2024-02-15 11:46 ` [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
2024-03-25 1:54 ` patchwork-bot+chrome-platform
2024-03-25 2:13 ` patchwork-bot+chrome-platform
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63b248efcbd62a121610cbf37ea0339bd87c99e7.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alexandre.belloni@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=alim.akhtar@samsung.com \
--cc=alyssa@rosenzweig.io \
--cc=andriy.shevchenko@linux.intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=asahi@lists.linux.dev \
--cc=baolin.wang@linux.alibaba.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bleung@chromium.org \
--cc=brgl@bgdev.pl \
--cc=broonie@kernel.org \
--cc=chrome-platform@lists.linux.dev \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor.dooley@microchip.com \
--cc=corbet@lwn.net \
--cc=daire.mcnamara@microchip.com \
--cc=fabrice.gasnier@foss.st.com \
--cc=festevam@gmail.com \
--cc=florian.fainelli@broadcom.com \
--cc=groeck@chromium.org \
--cc=hammerh0314@gmail.com \
--cc=hdegoede@redhat.com \
--cc=heiko@sntech.de \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=j.neuschaefer@gmx.net \
--cc=james.clark@arm.com \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=keescook@chromium.org \
--cc=kernel@pengutronix.de \
--cc=khilman@baylibre.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-leds@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=martin.blumenstingl@googlemail.com \
--cc=matthias.bgg@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=michal.simek@amd.com \
--cc=mika.westerberg@linux.intel.com \
--cc=mwalle@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=nicolas.ferre@microchip.com \
--cc=nobuhiro1.iwamatsu@toshiba.co.jp \
--cc=orsonzhai@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=paul@crapouillou.net \
--cc=pavel@ucw.cz \
--cc=platform-driver-x86@vger.kernel.org \
--cc=quic_amelende@quicinc.com \
--cc=quic_bjorande@quicinc.com \
--cc=rjui@broadcom.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=samuel@sholland.org \
--cc=sbranden@broadcom.com \
--cc=sean.anderson@seco.com \
--cc=shawnguo@kernel.org \
--cc=shc_work@mail.ru \
--cc=sven@svenpeter.dev \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vz@mleia.com \
--cc=wens@csie.org \
--cc=zhang.lyra@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).