* Applied "ASoC: sun4i-i2s: Add support for TDM slots" to the asoc tree
From: Mark Brown @ 2019-08-21 12:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: alsa-devel, lgirdwood, Maxime Ripard, linux-kernel, codekipper,
Chen-Yu Tsai, Mark Brown, linux-arm-kernel
In-Reply-To: <26392af30b3e7b31ee48d5b867d45be8675db046.1566242458.git-series.maxime.ripard@bootlin.com>
The patch
ASoC: sun4i-i2s: Add support for TDM slots
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 137befe19f310400a8b20fd8a4ce8c4141aafde0 Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime.ripard@bootlin.com>
Date: Mon, 19 Aug 2019 21:25:27 +0200
Subject: [PATCH] ASoC: sun4i-i2s: Add support for TDM slots
The i2s controller supports TDM, for up to 8 slots. Let's support the TDM
API.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/26392af30b3e7b31ee48d5b867d45be8675db046.1566242458.git-series.maxime.ripard@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-i2s.c | 40 +++++++++++++++++++++++++++++++------
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 9e691baee1e8..8326b8cfa569 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -168,6 +168,8 @@ struct sun4i_i2s {
struct reset_control *rst;
unsigned int mclk_freq;
+ unsigned int slots;
+ unsigned int slot_width;
struct snd_dmaengine_dai_dma_data capture_dma_data;
struct snd_dmaengine_dai_dma_data playback_dma_data;
@@ -287,7 +289,7 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int oversample)
static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
unsigned int rate,
- unsigned int channels,
+ unsigned int slots,
unsigned int word_size)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
@@ -335,7 +337,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
bclk_parent_rate = i2s->variant->get_bclk_parent_rate(i2s);
bclk_div = sun4i_i2s_get_bclk_div(i2s, bclk_parent_rate,
- rate, channels, word_size);
+ rate, slots, word_size);
if (bclk_div < 0) {
dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
return -EINVAL;
@@ -419,6 +421,10 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
const struct snd_pcm_hw_params *params)
{
unsigned int channels = params_channels(params);
+ unsigned int slots = channels;
+
+ if (i2s->slots)
+ slots = i2s->slots;
/* Map the channels for playback and capture */
regmap_write(i2s->regmap, SUN8I_I2S_TX_CHAN_MAP_REG, 0x76543210);
@@ -428,7 +434,6 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
SUN4I_I2S_CHAN_SEL_MASK,
SUN4I_I2S_CHAN_SEL(channels));
-
regmap_update_bits(i2s->regmap, SUN8I_I2S_RX_CHAN_SEL_REG,
SUN4I_I2S_CHAN_SEL_MASK,
SUN4I_I2S_CHAN_SEL(channels));
@@ -452,10 +457,18 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+ unsigned int word_size = params_width(params);
unsigned int channels = params_channels(params);
+ unsigned int slots = channels;
int ret, sr, wss;
u32 width;
+ if (i2s->slots)
+ slots = i2s->slots;
+
+ if (i2s->slot_width)
+ word_size = i2s->slot_width;
+
ret = i2s->variant->set_chan_cfg(i2s, params);
if (ret < 0) {
dev_err(dai->dev, "Invalid channel configuration\n");
@@ -477,15 +490,14 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
if (sr < 0)
return -EINVAL;
- wss = i2s->variant->get_wss(i2s, params_width(params));
+ wss = i2s->variant->get_wss(i2s, word_size);
if (wss < 0)
return -EINVAL;
regmap_field_write(i2s->field_fmt_wss, wss);
regmap_field_write(i2s->field_fmt_sr, sr);
- return sun4i_i2s_set_clk_rate(dai, params_rate(params),
- channels, params_width(params));
+ return sun4i_i2s_set_clk_rate(dai, params_rate(params), slots, word_size);
}
static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
@@ -785,10 +797,26 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai *dai, int clk_id,
return 0;
}
+static int sun4i_i2s_set_tdm_slot(struct snd_soc_dai *dai,
+ unsigned int tx_mask, unsigned int rx_mask,
+ int slots, int slot_width)
+{
+ struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
+
+ if (slots > 8)
+ return -EINVAL;
+
+ i2s->slots = slots;
+ i2s->slot_width = slot_width;
+
+ return 0;
+}
+
static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
.hw_params = sun4i_i2s_hw_params,
.set_fmt = sun4i_i2s_set_fmt,
.set_sysclk = sun4i_i2s_set_sysclk,
+ .set_tdm_slot = sun4i_i2s_set_tdm_slot,
.trigger = sun4i_i2s_trigger,
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Krzysztof Kozlowski @ 2019-08-21 12:16 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: devicetree, linux-samsung-soc@vger.kernel.org, Arnd Bergmann,
linux-pm, Sylwester Nawrocki, vireshk,
linux-kernel@vger.kernel.org, Jon Hunter, robh+dt, kgene,
Sylwester Nawrocki, pankaj.dubey, linux-tegra, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <72eea1ea-2433-2f76-6265-5851554e845d@samsung.com>
On Wed, 21 Aug 2019 at 13:51, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> >>> Following this change, I am now seeing the above error on our Tegra
> >>> boards where this driver is enabled. This is triggering a kernel
> >>> warnings test we have to fail. Hence, I don't think that you can remove
> >>> the compatible node test here, unless you have a better way to determine
> >>> if this is a samsung device.
> >>
> >> Right, this is really wrong... I missed that it is not a probe but
> >> early init. And this init will be called on every board... Probably it
> >> should be converted to a regular driver.
>
> Early initialization is needed for SoC driver to be used from within
> arch/arm/mach-exynos/ and _initcall() usage is the usual way for SoC
> drivers to be initialized:
>
> drivers/soc/amlogic/meson-gx-socinfo.c
> drivers/soc/amlogic/meson-mx-socinfo.c
> drivers/soc/atmel/soc.c
> drivers/soc/bcm/brcmstb/common.c
> drivers/soc/imx/soc-imx-scu.c
> drivers/soc/imx/soc-imx8.c
> drivers/soc/renesas/renesas-soc.c
> drivers/soc/tegra/fuse/fuse-tegra.c
> drivers/soc/ux500/ux500-soc-id.c
> drivers/soc/versatile/soc-integrator.c
> drivers/soc/versatile/soc-integrator.c
>
> The only SoC drivers that are regular drivers are:
>
> drivers/soc/fsl/guts.c
> drivers/soc/versatile/soc-realview.c
Thanks for pointing it out.
Indeed, the initcall was needed in your set of patches here:
https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=43565&state=*
but this work was not continued here. Maybe it will be later
resubmitted... maybe not... who knows? Therefore I would prefer proper
solution for current case (driver), unless patches for mach are being
brought back to life now.
> > I'm also inclined to have it converted to a regular driver. We already
> > have "exynos-asv" driver matching on the chipid node (patch 3/9).
> > The ASV patches will not be merged soon anyway, all this needs some more
> > thought. Krzysztof, can we abandon the chipid patches for now? Your
>
> chipid driver is good and useful on its own. The preferred solution
> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
> driver to use the regmap API" commit.
I queued the chipid as a dependency for ASV but ASV requires the
regmap. What would be left after reverting the regmap part? Simple
unused printk driver? No need for such. If reverting, then let's drop
entire driver and rework it offline.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 02/10] clk: sunxi-ng: Mark AR100 clocks as critical
From: Maxime Ripard @ 2019-08-21 12:24 UTC (permalink / raw)
To: Samuel Holland
Cc: Mark Rutland, devicetree, linux-sunxi, Stephen Boyd,
Michael Turquette, Jassi Brar, linux-kernel, Chen-Yu Tsai,
Rob Herring, Corentin Labbe, linux-clk, linux-arm-kernel
In-Reply-To: <3b67534a-eb1b-c1e8-b5e8-e0a74ae85792@sholland.org>
[-- Attachment #1.1: Type: text/plain, Size: 4574 bytes --]
On Tue, Aug 20, 2019 at 08:02:55AM -0500, Samuel Holland wrote:
> On 8/20/19 2:11 AM, Maxime Ripard wrote:
> > On Mon, Aug 19, 2019 at 10:23:03PM -0500, Samuel Holland wrote:
> >> On sun8i, sun9i, and sun50i SoCs, system suspend/resume support requires
> >> firmware running on the AR100 coprocessor (the "SCP"). Such firmware can
> >> provide additional features, such as thermal monitoring and poweron/off
> >> support for boards without a PMIC.
> >>
> >> Since the AR100 may be running critical firmware, even if Linux does not
> >> know about it or directly interact with it (all requests may go through
> >> an intermediary interface such as PSCI), Linux must not turn off its
> >> clock.
>
> This paragraph here is the key. The firmware won't necessarily have a device
> tree node, and in the current design it will not, since Linux never communicates
> with it directly. All communication goes through ATF via PSCI.
Sorry, I'm a bit lost in all those ARM firmware interfaces.
I thought SCPI was supposed to be a separate interface that had
nothing to do with PSCI?
Anyway, my main concern is that I don't really want to make exceptions
to the clock handling for everyone's usecase, and this creates a
precedent (and not even a permanent one, since eventually the plan is
to have all the clock handling happening in the firmware, right?).
There's the protected-clocks property in the DT though that will
achieve the same goal. The code to deal with it is not generic at the
moment, but it could be made that way. Would patching the DT to
protect the clock you care about, when you care about protecting them,
be an option for you?
> >> At this time, such power management firmware only exists for the A64 and
> >> H5 SoCs. However, it makes sense to take care of all CCU drivers now
> >> for consistency, and to ease the transition in the future once firmware
> >> is ported to the other SoCs.
> >>
> >> Leaving the clock running is safe even if no firmware is present, since
> >> the AR100 stays in reset by default. In most cases, the AR100 clock is
> >> kept enabled by Linux anyway, since it is the parent of all APB0 bus
> >> peripherals. This change only prevents Linux from turning off the AR100
> >> clock in the rare case that no peripherals are in use.
> >>
> >> Signed-off-by: Samuel Holland <samuel@sholland.org>
> >
> > So I'm not really sure where you want to go with this.
> >
> > That clock is only useful where you're having a firmware running on
> > the AR100, and that firmware would have a device tree node of its own,
> > where we could list the clocks needed for the firmware to keep
> > running, if it ever runs. If the driver has not been compiled in /
> > loaded, then we don't care either.
>
> See above. I don't expect that the firmware would have a device tree node,
> because the firmware doesn't need any Linux drivers.
>
> > But more fundamentally, if we're going to use SCPI, then those clocks
> > will not be handled by that driver anyway, but by the firmware, right?
>
> In the future, we might use SCPI clocks/sensors/regulators/etc. from Linux, but
> that's not the plan at the moment. Given that it's already been two years since
> I started this project, I'm trying to limit its scope so I can get at least some
> part merged. The first step is to integrate a firmware that provides
> suspend/resume functionality only. That firmware does implement SCPI, and if the
> top-level Linux SCPI driver worked with multiple mailbox channels, it could
> query the firmware's version and fetures. But all of the SCPI commands used for
> suspend/resume must go through ATF via PSCI.
I didn't know that you could / should do that with PSCI / SCPI.
> > So I'm not really sure that we should do it statically this way, and
> > that we should do it at all.
>
> Do you have a better way to model "firmware uses this clock behind the scenes,
> so Linux please don't touch it"? It's unfortunate that we have Linux and
> firmware fighting over the R_CCU, but since we didn't have firmware (e.g. SCPI
> clocks) in the beginning, it's where we are today.
>
> The AR100 clock doesn't actually have a gate, and it generally has dependencies
> like R_INTC in use. So as I mentioned in the commit message, the clock will
> normally be on anyway. The goal was to model the fact that there are users of
> this clock that Linux doesn't/can't know about.
Like I said, if that's an option, I'd prefer to have protected-clocks
work for everyone / for sunxi.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver
From: Maxime Ripard @ 2019-08-21 12:30 UTC (permalink / raw)
To: Samuel Holland
Cc: Mark Rutland, devicetree, linux-sunxi, Stephen Boyd,
Michael Turquette, Jassi Brar, linux-kernel, Chen-Yu Tsai,
Rob Herring, Corentin Labbe, linux-clk, linux-arm-kernel
In-Reply-To: <bc09e14c-1cf5-8124-fc34-c651b78577ce@sholland.org>
[-- Attachment #1.1: Type: text/plain, Size: 1225 bytes --]
On Tue, Aug 20, 2019 at 08:07:53AM -0500, Samuel Holland wrote:
> On 8/20/19 6:18 AM, Ondřej Jirman wrote:
> >> + reset = devm_reset_control_get(dev, NULL);
> >> + if (IS_ERR(reset)) {
> >> + ret = PTR_ERR(reset);
> >> + dev_err(dev, "Failed to get reset control: %d\n", ret);
> >> + goto err_disable_unprepare;
> >> + }
> >> +
> >> + ret = reset_control_deassert(reset);
> >> + if (ret) {
> >> + dev_err(dev, "Failed to deassert reset: %d\n", ret);
> >> + goto err_disable_unprepare;
> >> + }
> >
> > You need to assert the reset again from now on, in error paths. devm
> > will not do that for you.
>
> I know, and that's intentional. This same message box device is used for ATF to
> communicate with SCP firmware (on a different channel). This could be happening
> on a different core while Linux is running. So Linux is not allowed to deassert
> the reset. clk_disable_unprepare() is only okay because the clock is marked as
> critical.
I agree with Ondrej that since this is clearly not the standard use of
the API, this must have a big comment explaining why we're doing it
this way.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Sylwester Nawrocki @ 2019-08-21 12:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
Cc: devicetree, linux-samsung-soc@vger.kernel.org, Arnd Bergmann,
linux-pm, Sylwester Nawrocki, vireshk,
linux-kernel@vger.kernel.org, Jon Hunter, robh+dt, kgene,
pankaj.dubey, linux-tegra, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <CAJKOXPdh9eHrAuCxHkQBvJMqEnUCeU2xwkK=9yyiJ6BuTLJ+_A@mail.gmail.com>
On 8/21/19 14:16, Krzysztof Kozlowski wrote:
>>> I'm also inclined to have it converted to a regular driver. We already
>>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
>>> The ASV patches will not be merged soon anyway, all this needs some more
>>> thought. Krzysztof, can we abandon the chipid patches for now? Your
>>
>> chipid driver is good and useful on its own. The preferred solution
>> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
>> driver to use the regmap API" commit.
>
> I queued the chipid as a dependency for ASV but ASV requires the
> regmap. What would be left after reverting the regmap part? Simple
> unused printk driver? No need for such. If reverting, then let's drop
> entire driver and rework it offline.
In fact there is now no dependency between the chipid and the ASV
driver (patch 3/9), the regmap is provided by the syscon driver/API.
I should have added "depends on REGMAP && MFD_SYSCON" to Kconfig.
Both drivers (chipid, ASV) share the registers region so the regmap
API seemed appropriate here.
Converting the chipid code to platform driver wouldn't make sense as
it wouldn't be useful early in arch/arm/mach-exynos and we can't have
two drivers for same device (the ASV driver matches on the chipid
compatible now).
--
Regards,
Sylwester
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] soc: renesas: ARM errata updates
From: Geert Uytterhoeven @ 2019-08-21 12:45 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
Hi all,
This patch series updates the handling of ARM errata for affected
Renesas SoCs.
The first patch enables the new ARM_ERRATA_814220 for Cortex-A7, using
Kconfig logic.
The second patch moves enablement of ARM_ERRATA_754322 for Cortex-A9
from shmobile_defconfig to Kconfig logic, to make sure it's always
enabled when needed.
The third patch disables PL310_ERRATA_588369, as it doesn't affect any
Renesas SoCs.
The last patch is marked RFC, as I don't know the revision of PL310 on
EMMA Mobile EV2, and cannot test it on EMEV2.
Thanks for your comments!
Geert Uytterhoeven (3):
soc: renesas: Enable ARM_ERRATA_814220 for affected Cortex-A7
soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9
[RFC] ARM: shmobile: defconfig: Disable PL310_ERRATA_588369
arch/arm/configs/shmobile_defconfig | 2 --
drivers/soc/renesas/Kconfig | 11 +++++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] soc: renesas: Enable ARM_ERRATA_814220 for affected Cortex-A7
From: Geert Uytterhoeven @ 2019-08-21 12:46 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190821124602.29317-1-geert+renesas@glider.be>
ARM Erratum 814220 affects Cortex-A7 revisions r0p2-r0p5.
Enable automatically support to mitigate the erratum when compiling a
kernel for any of the affected Renesas SoCs:
- R-Mobile APE6: r0p2,
- RZ/G1E: r0p5,
- RZ/G1C: r0p5,
- R-Car H2: r0p3,
- R-Car E2: r0p5,
- RZ/N1: r0p5.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/soc/renesas/Kconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 2bbf49e5d441808b..a72d014ea37cc788 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -72,6 +72,7 @@ config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
select ARCH_RMOBILE
select ARM_ERRATA_798181 if SMP
+ select ARM_ERRATA_814220
select HAVE_ARM_ARCH_TIMER
select RENESAS_IRQC
@@ -95,11 +96,13 @@ config ARCH_R8A7744
config ARCH_R8A7745
bool "RZ/G1E (R8A77450)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_814220
select SYSC_R8A7745
config ARCH_R8A77470
bool "RZ/G1C (R8A77470)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_814220
select SYSC_R8A77470
config ARCH_R8A7778
@@ -117,6 +120,7 @@ config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
select ARCH_RCAR_GEN2
select ARM_ERRATA_798181 if SMP
+ select ARM_ERRATA_814220
select I2C
select SYSC_R8A7790
@@ -143,11 +147,13 @@ config ARCH_R8A7793
config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_814220
select SYSC_R8A7794
config ARCH_R9A06G032
bool "RZ/N1D (R9A06G032)"
select ARCH_RZN1
+ select ARM_ERRATA_814220
config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9
From: Geert Uytterhoeven @ 2019-08-21 12:46 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190821124602.29317-1-geert+renesas@glider.be>
ARM Erratum 754322 affects Cortex-A9 revisions r2p* and r3p*.
Enable support code to mitigate the erratum when compiling a kernel for
any of the affected Renesas SoCs:
- RZ/A1: r3p0,
- R-Mobile A1: r2p4,
- R-Car M1A: r2p2-00rel0,
- R-Car H1: r3p0,
- SH-Mobile AG5: r2p2,
and drop the corresponding config symbol from shmobile_defconfig.
EMMA Mobile EV2 (r1p3) and RZ/A2 (r4p1) are not affected.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Looks like my R-Mobile A1 is actually r2p3, and the R-Car M1A in Magnus'
farm is r2p4?
arch/arm/configs/shmobile_defconfig | 1 -
drivers/soc/renesas/Kconfig | 5 +++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index c6c70355141c38fa..123821e63873dafa 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -9,7 +9,6 @@ CONFIG_PERF_EVENTS=y
CONFIG_SLAB=y
CONFIG_ARCH_RENESAS=y
CONFIG_PL310_ERRATA_588369=y
-CONFIG_ARM_ERRATA_754322=y
CONFIG_SMP=y
CONFIG_SCHED_MC=y
CONFIG_NR_CPUS=8
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index a72d014ea37cc788..3c5e017bacbaca11 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -55,6 +55,7 @@ config ARCH_EMEV2
config ARCH_R7S72100
bool "RZ/A1H (R7S72100)"
+ select ARM_ERRATA_754322
select PM
select PM_GENERIC_DOMAINS
select RENESAS_OSTM
@@ -79,6 +80,7 @@ config ARCH_R8A73A4
config ARCH_R8A7740
bool "R-Mobile A1 (R8A77400)"
select ARCH_RMOBILE
+ select ARM_ERRATA_754322
select RENESAS_INTC_IRQPIN
config ARCH_R8A7743
@@ -108,10 +110,12 @@ config ARCH_R8A77470
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
+ select ARM_ERRATA_754322
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
select ARCH_RCAR_GEN1
+ select ARM_ERRATA_754322
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select SYSC_R8A7779
@@ -158,6 +162,7 @@ config ARCH_R9A06G032
config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
+ select ARM_ERRATA_754322
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select RENESAS_INTC_IRQPIN
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] [RFC] ARM: shmobile: defconfig: Disable PL310_ERRATA_588369
From: Geert Uytterhoeven @ 2019-08-21 12:46 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190821124602.29317-1-geert+renesas@glider.be>
PL310 Erratum 588369 affects PL310 cache controller revisions older than
r2p0.
As Renesas ARM SoCs contain the following revisions:
- SH-Mobile AG5: r3p1,
- R-Mobile A1: r3p1-50rel0,
- R-Car H1: r3p2,
- RZ/A1: r3p2,
- RZ/A2: r3p3,
none of them are affected, and support for the errata can be disabled
safely.
The EMMA Mobile EV2 documentation doesn't mention the revision of its
PL310 cache controller, so this SoC might be affected. However, the L2
cache controller is not enabled by Linux.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/configs/shmobile_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 123821e63873dafa..95a127cbe8e6fcd7 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -8,7 +8,6 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_PERF_EVENTS=y
CONFIG_SLAB=y
CONFIG_ARCH_RENESAS=y
-CONFIG_PL310_ERRATA_588369=y
CONFIG_SMP=y
CONFIG_SCHED_MC=y
CONFIG_NR_CPUS=8
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 07/21] ARM: dts: imx7-colibri: fix 1.8V/UHS support
From: Philippe Schenker @ 2019-08-21 12:49 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
michal.vokac@ysoft.com, Max Krummenacher, Stefan Agner,
Marcel Ziswiler, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, stefan@agner.ch, robh+dt@kernel.org,
linux-imx@nxp.com, kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819111847.GQ5999@X250>
On Mon, 2019-08-19 at 13:18 +0200, Shawn Guo wrote:
> On Mon, Aug 12, 2019 at 02:21:25PM +0000, Philippe Schenker wrote:
> > From: Stefan Agner <stefan.agner@toradex.com>
> >
> > Add pinmuxing and do not specify voltage restrictions for the usdhc
> > instance available on the modules edge connector. This allows to use
> > SD-cards with higher transfer modes if supported by the carrier
> > board.
> >
> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Changes in v4:
> > - Add Marcel Ziswiler's Ack
> >
> > Changes in v3:
> > - Add new commit message from Stefan's proposal on ML
> >
> > Changes in v2: None
> >
> > arch/arm/boot/dts/imx7-colibri.dtsi | 23 ++++++++++++++++++++++-
> > 1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
> > b/arch/arm/boot/dts/imx7-colibri.dtsi
> > index 5347ed38acb2..c563bb821b5e 100644
> > --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> > +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> > @@ -326,7 +326,6 @@
> > &usdhc1 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_cd_usdhc1>;
> > - no-1-8-v;
> > cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> > disable-wp;
> > vqmmc-supply = <®_LDO2>;
> > @@ -671,6 +670,28 @@
> > >;
> > };
> >
> > + pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
> > + fsl,pins = <
> > + MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
> > + MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
> > + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
> > + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
> > + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
> > + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
> > + >;
> > + };
> > +
> > + pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
>
> No reference to them from usdhc1 node?
>
> Shawn
No. I'd like to have that pinmuxing prepared for someone to add UHS
support to SD. Primary functionality of that pins is something else so
this will have priority.
Philippe
>
> > + fsl,pins = <
> > + MX7D_PAD_SD1_CMD__SD1_CMD 0x5b
> > + MX7D_PAD_SD1_CLK__SD1_CLK 0x1b
> > + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5b
> > + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5b
> > + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5b
> > + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5b
> > + >;
> > + };
> > +
> > pinctrl_usdhc3: usdhc3grp {
> > fsl,pins = <
> > MX7D_PAD_SD3_CMD__SD3_CMD 0x59
> > --
> > 2.22.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 08/21] ARM: dts: imx7-colibri: Add touch controllers
From: Philippe Schenker @ 2019-08-21 12:51 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
michal.vokac@ysoft.com, Max Krummenacher, Marcel Ziswiler,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
stefan@agner.ch, robh+dt@kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819112124.GR5999@X250>
On Mon, 2019-08-19 at 13:21 +0200, Shawn Guo wrote:
> On Mon, Aug 12, 2019 at 02:21:26PM +0000, Philippe Schenker wrote:
> > Add touch controller that is connected over an I2C bus.
> >
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Changes in v4:
> > - Add Marcel Ziswiler's Ack
> >
> > Changes in v3:
> > - Fix commit message
> >
> > Changes in v2:
> > - Deleted touchrevolution downstream stuff
> > - Use generic node name
> > - Better comment
> >
> > arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 24
> > +++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > index d4dbc4fc1adf..576dec9ff81c 100644
> > --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > @@ -145,6 +145,21 @@
> > &i2c4 {
> > status = "okay";
> >
> > + /*
> > + * Touchscreen is using SODIMM 28/30, also used for PWM<B>,
> > PWM<C>,
> > + * aka pwm2, pwm3. so if you enable touchscreen, disable the
> > pwms
> > + */
> > + touchscreen@4a {
> > + compatible = "atmel,maxtouch";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpiotouch>;
> > + reg = <0x4a>;
> > + interrupt-parent = <&gpio1>;
> > + interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /*
> > SODIMM 28 */
> > + reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; /* SODIMM 30
> > */
> > + status = "disabled";
>
> Why disabled?
>
> Shawn
Also here, this is meant as an example to get our touchscreen faster
running. But those pins are primarily used as PWM's and they should by
default muxed for PWM's.
If a customer want's to add that touchscreen he just have to switch the
status of this and PWM...
Philippe
>
> > + };
> > +
> > /* M41T0M6 real time clock on carrier board */
> > rtc: m41t0m6@68 {
> > compatible = "st,m41t0";
> > @@ -200,3 +215,12 @@
> > vmmc-supply = <®_3v3>;
> > status = "okay";
> > };
> > +
> > +&iomuxc {
> > + pinctrl_gpiotouch: touchgpios {
> > + fsl,pins = <
> > + MX7D_PAD_GPIO1_IO09__GPIO1_IO9 0x74
> > + MX7D_PAD_GPIO1_IO10__GPIO1_IO10 0x14
> > + >;
> > + };
> > +};
> > --
> > 2.22.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] iommu/io-pgtable-arm: Rationalise TCR handling
From: Robin Murphy @ 2019-08-21 12:56 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190821121120.34wqo7vj56pqk57c@willie-the-truck>
On 21/08/2019 13:11, Will Deacon wrote:
> On Tue, Aug 20, 2019 at 07:41:52PM +0100, Robin Murphy wrote:
>> On 20/08/2019 17:07, Will Deacon wrote:
>>> On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
>>>> On 20/08/2019 11:31, Will Deacon wrote:
>>>>> On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
>>>>>> Although it's conceptually nice for the io_pgtable_cfg to provide a
>>>>>> standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
>>>>>> looks exactly like an Arm CPU, and they all have various other TCR
>>>>>> controls which io-pgtable can't be expected to understand. Thus since
>>>>>> there is an expectation that drivers will have to add to the given TCR
>>>>>> value anyway, let's strip it down to just the essentials that are
>>>>>> directly relevant to io-pgatble's inner workings - namely the address
>>>>>> sizes, walk attributes, and where appropriate, format selection.
>>>>>>
>>>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>>>> ---
>>>>>> drivers/iommu/arm-smmu-v3.c | 7 +------
>>>>>> drivers/iommu/arm-smmu.c | 1 +
>>>>>> drivers/iommu/arm-smmu.h | 2 ++
>>>>>> drivers/iommu/io-pgtable-arm-v7s.c | 6 ++----
>>>>>> drivers/iommu/io-pgtable-arm.c | 4 ----
>>>>>> drivers/iommu/qcom_iommu.c | 2 +-
>>>>>> 6 files changed, 7 insertions(+), 15 deletions(-)
>>>>>
>>>>> Hmm, so I'm a bit nervous about this one since I think we really should
>>>>> be providing a TCR with EPD1 set if we're only giving you TTBR0. Relying
>>>>> on the driver to do this worries me. See my comments on the next patch.
>>>>
>>>> The whole idea is that we already know we can't provide a *complete* TCR
>>>> value (not least because anything above bit 31 is the wild west), thus
>>>> there's really no point in io-pgtable trying to provide anything other than
>>>> the parts it definitely controls. It makes sense to provide this partial TCR
>>>> value "as if" for TTBR0, since that's the most common case, but ultimately
>>>> io-pgatble doesn't know (or need to) which TTBR the caller intends to
>>>> actually use for this table. Even if the caller *is* allocating it for
>>>> TTBR0, io-pgtable doesn't know that they haven't got something live in TTBR1
>>>> already, so it still wouldn't be in a position to make the EPD1 call either
>>>> way.
>>>
>>> Ok, but the driver can happily rewrite/ignore what it gets back. I suppose
>>> an alternative would be scrapped the 'u64 tcr' and instead having a bunch
>>> of named bitfields for the stuff we're actually providing, although I'd
>>> still like EPDx to be in there.
>>
>> I like the bitfield idea; it would certainly emphasise the "you have to do
>> something more with this" angle that I'm pushing towards here, but still
>> leave things framed in TCR terms without having to go to some more general
>> abstraction. It really doesn't play into your EPD argument though - such a
>> config would be providing TxSZ/TGx/IRGNx/ORGNx/SHx, but EPDy, for y = !x.
>> For a driver to understand that and do the right thing with it is even more
>> involved than for the driver to just set EPD1 by itself anyway.
>
> Having considered the bitfield idea some more, I'm less attached to EPDx
> because we simply wouldn't be making a statement about them, rather than a
> (dangerous) zero value and expecting it to be ignored. So I think we're in
> agreement on that.
Cool, I'll give bitfields a go for v2.
> The only part I'm still stuck to is that I think io-pgtable should know
> whether it's targetting TTBR0 or TTBR1 so that it can sanitise input
> addresses correctly. Doing this in the driver code is possible, but I'd
> rather not start from that position, particularly as it would require things
> like sign-extension in the TLBI callbacks.
Good point, and thanks for the prod that the way I end up propagating
masked-off IOVAs through to the TLBI calls here is busted either way.
I'm OK with introducing an explicit TTBR1 quirk to begin with, as it
should make things a little easier to reason about, and we can always
revisit later if and when we do find a need for more flexibility.
>> If only LPAE had created these bits as enables rather than disables then
>> things would be logical and we could all be happy, but here we are...
>
> I'm happy! :D:D:D
Yeah, but I refuse to believe it's ever because of pagetables ;)
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/2] PM / devfreq: Add dev_pm_qos support
From: Leonard Crestez @ 2019-08-21 13:00 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, Krzysztof Kozlowski,
Alexandre Bailon, cpgs (cpgs@samsung.com), Georgi Djakov,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <6134bb9e-9a16-b432-c191-c91f93844319@samsung.com>
On 21.08.2019 04:40, Chanwoo Choi wrote:
> On 19. 8. 21. 오전 12:24, Leonard Crestez wrote:
>> Add dev_pm_qos notifies to devfreq core in order to support frequency
>> limits via the dev_pm_qos_add_request.
>>
>> +static unsigned long get_effective_min_freq(struct devfreq *devfreq)
>
> I'm not sure that 'effective' expression is correct.
> From this function, the devfreq can get the final target frequency.
>
> I think that we need to use the more correct expression
> to give the meaning of function as following:
>
> get_min_freq
> get_max_freq
OK, will rename to get_min_freq and get_max_freq
>> @@ -636,21 +688,40 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> err = -ENOMEM;
>> goto err_out;
>> }
>>
>> mutex_init(&devfreq->lock);
>> - mutex_lock(&devfreq->lock);
>
> Basically, I think that it is safe to lock when touch
> the variable of the devfreq.
>
> it is not proper way for the dev_pm_qos because
> it breaks the existing locking reason of devfreq's variables.
I don't understand what you mean. I'm initializing some stuff outside
the lock to avoid circular lock warning between:
(&devfreq->lock){+.+.}, at: devfreq_qos_min_notifier_call+0x24/0x48
(&(n)->rwsem){++++}, at: blocking_notifier_call_chain+0x3c/0x78
In general you don't need to lock an object while initializing except
after it becomes accessible from the outside so devfreq_add_device
doesn't need to take the lock so early.
The QOS notifiers are registered on the parent device so in theory it's
possible for somebody to add QOS requests while devfreq_add_device is
executing. Maybe notifier registration should be moved at the end after
unlock?
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/2] PM / devfreq: Use dev_pm_qos for sysfs min/max_freq
From: Leonard Crestez @ 2019-08-21 13:03 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, Krzysztof Kozlowski,
Alexandre Bailon, cpgs (cpgs@samsung.com), Georgi Djakov,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <e2ba9b0d-1930-0d2a-c262-72f0f85c86d0@samsung.com>
On 21.08.2019 05:02, Chanwoo Choi wrote:
> On 19. 8. 21. 오전 12:24, Leonard Crestez wrote:
>> Now that devfreq supports dev_pm_qos requests we can use them to handle
>> the min/max_freq values set by userspace in sysfs, similar to cpufreq.
>>
>> Since dev_pm_qos handles frequencies as kHz this change reduces the
>> precision of min_freq and max_freq. This shouldn't introduce problems
>> because frequencies which are not an integer number of kHz are likely
>> not an integer number of Hz either.
>>
>> Try to ensure compatibilitity by rounding min values down and rounding
>> max values up.
>>
>> Simplify the {min,max}_freq_store code by setting "null" values of 0 and
>> MAX_S32 respectively instead of clamping to what freq tables are
>> actually supported. Values are already automatically clamped on
>> readback.
>>
>> Also simplify by droping the limitation that userspace min_freq must be
>> lower than userspace max_freq, it is already documented that max_freq
>> takes precedence.
>>
>> @@ -1358,33 +1371,20 @@ static ssize_t min_freq_store(struct device *dev, struct device_attribute *attr,
>>
>> ret = sscanf(buf, "%lu", &value);
>> if (ret != 1)
>> return -EINVAL;
>>
>> - mutex_lock(&df->lock);
>> -
>> - if (value) {
>> - if (value > df->max_freq) {
>> - ret = -EINVAL;
>> - goto unlock;
>> - }
>
> Actually, the user can input the value they want.
> So, the above code is not necessary because the devfreq->scaling_max_freq
> is never overflow from supported maximum frequency. The devfreq->scaling_max_freq
> is based on OPP entries from DT.
>
> But, if we replace the existing request way of devfreq-cooling.c
> with dev_pm_qos, devfreq->scaling_max_freq doesn't guarantee
> the supported maximum frequency. >
> We need to keep the supported min_freq/max_freq value without dev_pm_qos
> requirement because the dev_pm_qos requirement might have the overflow value.
> the dev_pm_qos doesn't know the supported minimum and maximum frequency
> of devfreq device.
I'm not sure I understand what you mean. My patch allows user to set
entirely arbitrary min/max rates and this is good because we already
have a well-defined way to handle this: max overrides min.
The scaling_min_freq and scaling_max_freq variables can just be kept
around indefinitely no matter what happens to thermal. They're just a
cache for dev_pm_opp_find_freq_ceil and dev_pm_opp_find_freq_floor.
BTW: I noticed that scaling_min_freq and scaling_max_freq are updated in
devfreq_notifier_call but devfreq->nb is not registered by default, only
when a driver requests it explicitly. Is there a reason for this?
Because I'd call dev_pm_opp_register_notifier inside devfreq_add_device
and remove all the devfreq_register/unregister_notifier APIs.
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/4] ASoC: sun4i-i2s: Number of fixes and TDM Support
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
Hi,
This series aims at fixing a number of issues in the current i2s driver,
mostly related to the i2s master support and the A83t support. It also uses
that occasion to cleanup a few things and simplify the driver. Finally, it
builds on those fixes and cleanups to introduce TDM and DSP formats support.
Let me know what you think,
Maxime
Changes from v1:
- Removed patches applied
- Refactor a bit the call to sun4i_i2s_set_clk_rate
- Fix build issue
- Add an extra patch to cleanup sun4i_i2s_hw_params
Maxime Ripard (4):
ASoC: sun4i-i2s: Use the physical / slot width for the clocks
ASoC: sun4i-i2s: Use the actual format width instead of an hardcoded one
ASoC: sun4i-i2s: Replace call to params_width by local variable
ASoC: sun4i-i2s: Add support for DSP formats
sound/soc/sunxi/sun4i-i2s.c | 58 ++++++++++++++++++++++++++++----------
1 file changed, 43 insertions(+), 15 deletions(-)
base-commit: 137befe19f310400a8b20fd8a4ce8c4141aafde0
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/4] ASoC: sun4i-i2s: Use the physical / slot width for the clocks
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The clock dividers function has been using the word size to compute the
clock rate at which it's supposed to be running, but the proper formula
would be to use the physical width and / or slot width in TDM.
It doesn't make any difference at the moment since all the formats
supported have the same sample width and physical width, but it's not going
to last forever.
Fixes: 7d2993811a1e ("ASoC: sun4i-i2s: Add support for H3")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 8326b8cfa569..cdc3fa60ff33 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -290,7 +290,7 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int oversample)
static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
unsigned int rate,
unsigned int slots,
- unsigned int word_size)
+ unsigned int slot_width)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int oversample_rate, clk_rate, bclk_parent_rate;
@@ -337,7 +337,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
bclk_parent_rate = i2s->variant->get_bclk_parent_rate(i2s);
bclk_div = sun4i_i2s_get_bclk_div(i2s, bclk_parent_rate,
- rate, slots, word_size);
+ rate, slots, slot_width);
if (bclk_div < 0) {
dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
return -EINVAL;
@@ -458,6 +458,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int word_size = params_width(params);
+ unsigned int slot_width = params_physical_width(params);
unsigned int channels = params_channels(params);
unsigned int slots = channels;
int ret, sr, wss;
@@ -467,7 +468,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
slots = i2s->slots;
if (i2s->slot_width)
- word_size = i2s->slot_width;
+ slot_width = i2s->slot_width;
ret = i2s->variant->set_chan_cfg(i2s, params);
if (ret < 0) {
@@ -490,14 +491,15 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
if (sr < 0)
return -EINVAL;
- wss = i2s->variant->get_wss(i2s, word_size);
+ wss = i2s->variant->get_wss(i2s, slot_width);
if (wss < 0)
return -EINVAL;
regmap_field_write(i2s->field_fmt_wss, wss);
regmap_field_write(i2s->field_fmt_sr, sr);
- return sun4i_i2s_set_clk_rate(dai, params_rate(params), slots, word_size);
+ return sun4i_i2s_set_clk_rate(dai, params_rate(params),
+ slots, slot_width);
}
static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/4] ASoC: sun4i-i2s: Use the actual format width instead of an hardcoded one
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The LRCK period field in the FMT0 register holds the number of LRCK period
for one channel in I2S mode.
This has been hardcoded to 32, while it really should be the physical width
of the format, which creates an improper clock when using a 16bit format,
with the i2s controller as LRCK master.
Fixes: 7d2993811a1e ("ASoC: sun4i-i2s: Add support for H3")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index cdc3fa60ff33..9ef784b8867c 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -359,7 +359,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
if (i2s->variant->has_fmt_set_lrck_period)
regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
- SUN8I_I2S_FMT0_LRCK_PERIOD(32));
+ SUN8I_I2S_FMT0_LRCK_PERIOD(slot_width));
return 0;
}
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/4] ASoC: sun4i-i2s: Replace call to params_width by local variable
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The sun4i_i2s_hw_params function already has a variable holding the value
returned by params_width, so let's just use that variable instead of
calling params_width multiple times.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 9ef784b8867c..69162af9fd65 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -487,7 +487,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
}
i2s->playback_dma_data.addr_width = width;
- sr = i2s->variant->get_sr(i2s, params_width(params));
+ sr = i2s->variant->get_sr(i2s, word_size);
if (sr < 0)
return -EINVAL;
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/4] ASoC: sun4i-i2s: Add support for DSP formats
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
In addition to the I2S format, the controller also supports the DSP_*
formats.
This requires some extra care on the LRCK period calculation, since the
controller, with the PCM formats, require that the value set is no longer
the periods of LRCK for a single channel, but for all of them.
Let's add the code to deal with this, and support the DSP_A and DSP_B
formats.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 44 ++++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 69162af9fd65..57bf2a33753e 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -130,7 +130,6 @@ struct sun4i_i2s;
* struct sun4i_i2s_quirks - Differences between SoC variants.
*
* @has_reset: SoC needs reset deasserted.
- * @has_fmt_set_lrck_period: SoC requires lrclk period to be set.
* @reg_offset_txdata: offset of the tx fifo.
* @sun4i_i2s_regmap: regmap config to use.
* @field_clkdiv_mclk_en: regmap field to enable mclk output.
@@ -139,7 +138,6 @@ struct sun4i_i2s;
*/
struct sun4i_i2s_quirks {
bool has_reset;
- bool has_fmt_set_lrck_period;
unsigned int reg_offset_txdata; /* TX FIFO */
const struct regmap_config *sun4i_i2s_regmap;
@@ -167,6 +165,7 @@ struct sun4i_i2s {
struct regmap *regmap;
struct reset_control *rst;
+ unsigned int format;
unsigned int mclk_freq;
unsigned int slots;
unsigned int slot_width;
@@ -355,12 +354,6 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
regmap_field_write(i2s->field_clkdiv_mclk_en, 1);
- /* Set sync period */
- if (i2s->variant->has_fmt_set_lrck_period)
- regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
- SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
- SUN8I_I2S_FMT0_LRCK_PERIOD(slot_width));
-
return 0;
}
@@ -422,6 +415,7 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
{
unsigned int channels = params_channels(params);
unsigned int slots = channels;
+ unsigned int lrck_period;
if (i2s->slots)
slots = i2s->slots;
@@ -445,6 +439,26 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK,
SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(channels));
+ switch (i2s->format & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_DSP_A:
+ case SND_SOC_DAIFMT_DSP_B:
+ case SND_SOC_DAIFMT_LEFT_J:
+ case SND_SOC_DAIFMT_RIGHT_J:
+ lrck_period = params_physical_width(params) * slots;
+ break;
+
+ case SND_SOC_DAIFMT_I2S:
+ lrck_period = params_physical_width(params);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
+ SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
+ SUN8I_I2S_FMT0_LRCK_PERIOD(lrck_period));
+
regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
SUN8I_I2S_TX_CHAN_EN_MASK,
SUN8I_I2S_TX_CHAN_EN(channels));
@@ -616,6 +630,16 @@ static int sun8i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
/* DAI Mode */
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_DSP_A:
+ mode = SUN8I_I2S_CTRL_MODE_PCM;
+ offset = 1;
+ break;
+
+ case SND_SOC_DAIFMT_DSP_B:
+ mode = SUN8I_I2S_CTRL_MODE_PCM;
+ offset = 0;
+ break;
+
case SND_SOC_DAIFMT_I2S:
mode = SUN8I_I2S_CTRL_MODE_LEFT;
offset = 1;
@@ -684,6 +708,9 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
SUN4I_I2S_FIFO_CTRL_RX_MODE_MASK,
SUN4I_I2S_FIFO_CTRL_TX_MODE(1) |
SUN4I_I2S_FIFO_CTRL_RX_MODE(1));
+
+ i2s->format = fmt;
+
return 0;
}
@@ -1074,7 +1101,6 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
- .has_fmt_set_lrck_period = true,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
.field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
.field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
--
git-series 0.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Krzysztof Kozlowski @ 2019-08-21 13:10 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, Arnd Bergmann,
Bartlomiej Zolnierkiewicz, Sylwester Nawrocki, vireshk, linux-pm,
linux-kernel@vger.kernel.org, Jon Hunter, robh+dt, kgene,
pankaj.dubey, linux-tegra, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <537999b7-b0e8-33a7-4bdc-c6952a0a5d06@samsung.com>
On Wed, 21 Aug 2019 at 14:41, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> On 8/21/19 14:16, Krzysztof Kozlowski wrote:
> >>> I'm also inclined to have it converted to a regular driver. We already
> >>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
> >>> The ASV patches will not be merged soon anyway, all this needs some more
> >>> thought. Krzysztof, can we abandon the chipid patches for now? Your
> >>
> >> chipid driver is good and useful on its own. The preferred solution
> >> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
> >> driver to use the regmap API" commit.
> >
> > I queued the chipid as a dependency for ASV but ASV requires the
> > regmap. What would be left after reverting the regmap part? Simple
> > unused printk driver? No need for such. If reverting, then let's drop
> > entire driver and rework it offline.
>
> In fact there is now no dependency between the chipid and the ASV
> driver (patch 3/9), the regmap is provided by the syscon driver/API.
> I should have added "depends on REGMAP && MFD_SYSCON" to Kconfig.
> Both drivers (chipid, ASV) share the registers region so the regmap
> API seemed appropriate here.
Indeed, ASV needs only the header + DT change... Then actually we do
not need chipid driver at all. Just to print the SoC and provide sysfs
entry? If this is the only purpose, then it should be a driver.
> Converting the chipid code to platform driver wouldn't make sense as
> it wouldn't be useful early in arch/arm/mach-exynos and we can't have
> two drivers for same device (the ASV driver matches on the chipid
> compatible now).
There is no use case for arm/mach-exynos. This code was not
resubmitted and I doubt it will be (unless now someone wants to prove
I am wrong and sends it again :) ). The two-device case is indeed a
problem but it is possible. Clocks are doing it with PMU driver. See
CLK_OF_DECLARE_DRIVER(), although I do not remember whether it is
maybe obsolete pattern (discouraged).
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 11/21] ARM: dts: imx6qdl-apalis: Add sleep state to can interfaces
From: Philippe Schenker @ 2019-08-21 13:15 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
michal.vokac@ysoft.com, Max Krummenacher, Marcel Ziswiler,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
stefan@agner.ch, robh+dt@kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819112754.GU5999@X250>
On Mon, 2019-08-19 at 13:27 +0200, Shawn Guo wrote:
> On Mon, Aug 12, 2019 at 02:21:31PM +0000, Philippe Schenker wrote:
> > This patch prepares the devicetree for the new Ixora V1.2 where we
> > are
> > able to turn off the supply of the can transceiver. This implies to
> > use
> > a sleep state on transmission pins in order to prevent backfeeding.
> >
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Changes in v4:
> > - Add Marcel Ziswiler's Ack
> >
> > Changes in v3: None
> > Changes in v2:
> > - Changed commit title to '...imx6qdl-apalis:...'
> >
> > arch/arm/boot/dts/imx6qdl-apalis.dtsi | 27 +++++++++++++++++++++---
> > ---
> > 1 file changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 7c4ad541c3f5..59ed2e4a1fd1 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -148,14 +148,16 @@
> > };
> >
> > &can1 {
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&pinctrl_flexcan1>;
>
> This line doesn't need to be changed.
You're right, but by adding pinctrl_flexcan1_sleep here, I'd like to
emphasize between "default" and "sleep" and change that.
Since it's only used in this file I don't see any problems.
Philippe
>
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&pinctrl_flexcan1_default>;
> > + pinctrl-1 = <&pinctrl_flexcan1_sleep>;
> > status = "disabled";
> > };
> >
> > &can2 {
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&pinctrl_flexcan2>;
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&pinctrl_flexcan2_default>;
> > + pinctrl-1 = <&pinctrl_flexcan2_sleep>;
> > status = "disabled";
> > };
> >
> > @@ -599,19 +601,32 @@
> > >;
> > };
> >
> > - pinctrl_flexcan1: flexcan1grp {
>
> Ditto. I take them as unnecessary changes.
>
> Shawn
>
> > + pinctrl_flexcan1_default: flexcan1defgrp {
> > fsl,pins = <
> > MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
> > MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
> > >;
> > };
> >
> > - pinctrl_flexcan2: flexcan2grp {
> > + pinctrl_flexcan1_sleep: flexcan1slpgrp {
> > + fsl,pins = <
> > + MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x0
> > + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x0
> > + >;
> > + };
> > +
> > + pinctrl_flexcan2_default: flexcan2defgrp {
> > fsl,pins = <
> > MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
> > MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
> > >;
> > };
> > + pinctrl_flexcan2_sleep: flexcan2slpgrp {
> > + fsl,pins = <
> > + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x0
> > + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x0
> > + >;
> > + };
> >
> > pinctrl_gpio_bl_on: gpioblon {
> > fsl,pins = <
> > --
> > 2.22.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
From: Jeremy Linton @ 2019-08-21 13:20 UTC (permalink / raw)
To: John Garry, Will Deacon, Rafael J. Wysocki
Cc: lorenzo.pieralisi@arm.com, rric@kernel.org,
catalin.marinas@arm.com, rjw@rjwysocki.net,
linux-acpi@vger.kernel.org, Robert Richter, wanghuiqiang,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org,
lenb@kernel.org
In-Reply-To: <a2960c68-d422-3cdb-4354-6f357433ad6c@huawei.com>
Hi,
On 8/20/19 4:01 AM, John Garry wrote:
> On 12/08/2019 12:59, Will Deacon wrote:
>> On Mon, Aug 12, 2019 at 11:06:07AM +0200, Rafael J. Wysocki wrote:
>>> On Fri, Aug 9, 2019 at 12:25 AM Robert Richter <rrichter@marvell.com>
>>> wrote:
>>>>
>>>> On 08.08.19 15:40:06, Jeremy Linton wrote:
>>>>> ACPI 6.3 adds a flag to the CPU node to indicate whether
>>>>> the given PE is a thread. Add a function to return that
>>>>> information for a given linux logical CPU.
>>>>>
>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>> drivers/acpi/pptt.c | 53
>>>>> +++++++++++++++++++++++++++++++++++++++++++-
>>>>> include/linux/acpi.h | 5 +++++
>>>>> 2 files changed, 57 insertions(+), 1 deletion(-)
>>>>
>>>> Reviewed-by: Robert Richter <rrichter@marvell.com>
>>>
>>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>
>>> and please push it through ARM64 along with the second patch.
>>
>> Thanks. I'll push these into -next shortly.
>
>
> Hi Jeremy,
>
> We're considering requesting this support is backported to stable. We
> have a platform which incorrectly sets the MT bit. To update our
> firmware to PPTT v2, we need the kernel to support PPTT v2 also.
>
> Please let me know if you anticipate an issue in this.
No I don't see any issues with that once it lands.
I believe the ball is rolling in the case of some older distro kernel's
as well.
Thanks,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
From: John Garry @ 2019-08-21 13:25 UTC (permalink / raw)
To: Jeremy Linton, Will Deacon, Rafael J. Wysocki
Cc: lorenzo.pieralisi@arm.com, rric@kernel.org,
catalin.marinas@arm.com, rjw@rjwysocki.net,
linux-acpi@vger.kernel.org, Robert Richter, wanghuiqiang,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org,
lenb@kernel.org
In-Reply-To: <72ee16ea-1038-37a1-25b1-f28b5c6b6edb@arm.com>
On 21/08/2019 14:20, Jeremy Linton wrote:
> Hi,
>
> On 8/20/19 4:01 AM, John Garry wrote:
>> On 12/08/2019 12:59, Will Deacon wrote:
>>> On Mon, Aug 12, 2019 at 11:06:07AM +0200, Rafael J. Wysocki wrote:
>>>> On Fri, Aug 9, 2019 at 12:25 AM Robert Richter
>>>> <rrichter@marvell.com> wrote:
>>>>>
>>>>> On 08.08.19 15:40:06, Jeremy Linton wrote:
>>>>>> ACPI 6.3 adds a flag to the CPU node to indicate whether
>>>>>> the given PE is a thread. Add a function to return that
>>>>>> information for a given linux logical CPU.
>>>>>>
>>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>>> ---
>>>>>> drivers/acpi/pptt.c | 53
>>>>>> +++++++++++++++++++++++++++++++++++++++++++-
>>>>>> include/linux/acpi.h | 5 +++++
>>>>>> 2 files changed, 57 insertions(+), 1 deletion(-)
>>>>>
>>>>> Reviewed-by: Robert Richter <rrichter@marvell.com>
>>>>
>>>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>
>>>> and please push it through ARM64 along with the second patch.
>>>
>>> Thanks. I'll push these into -next shortly.
>>
>>
>> Hi Jeremy,
>>
>> We're considering requesting this support is backported to stable. We
>> have a platform which incorrectly sets the MT bit. To update our
>> firmware to PPTT v2, we need the kernel to support PPTT v2 also.
>>
>> Please let me know if you anticipate an issue in this.
>
> No I don't see any issues with that once it lands.
>
> I believe the ball is rolling in the case of some older distro kernel's
> as well.
Cool.
Cheers,
John
>
> Thanks,
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Bartlomiej Zolnierkiewicz @ 2019-08-21 13:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc@vger.kernel.org, Arnd Bergmann,
linux-pm, Sylwester Nawrocki, vireshk,
linux-kernel@vger.kernel.org, Jon Hunter, robh+dt, kgene,
Sylwester Nawrocki, pankaj.dubey, linux-tegra, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPdh9eHrAuCxHkQBvJMqEnUCeU2xwkK=9yyiJ6BuTLJ+_A@mail.gmail.com>
On 8/21/19 2:16 PM, Krzysztof Kozlowski wrote:
> On Wed, 21 Aug 2019 at 13:51, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
>>>>> Following this change, I am now seeing the above error on our Tegra
>>>>> boards where this driver is enabled. This is triggering a kernel
>>>>> warnings test we have to fail. Hence, I don't think that you can remove
>>>>> the compatible node test here, unless you have a better way to determine
>>>>> if this is a samsung device.
>>>>
>>>> Right, this is really wrong... I missed that it is not a probe but
>>>> early init. And this init will be called on every board... Probably it
>>>> should be converted to a regular driver.
>>
>> Early initialization is needed for SoC driver to be used from within
>> arch/arm/mach-exynos/ and _initcall() usage is the usual way for SoC
>> drivers to be initialized:
>>
>> drivers/soc/amlogic/meson-gx-socinfo.c
>> drivers/soc/amlogic/meson-mx-socinfo.c
>> drivers/soc/atmel/soc.c
>> drivers/soc/bcm/brcmstb/common.c
>> drivers/soc/imx/soc-imx-scu.c
>> drivers/soc/imx/soc-imx8.c
>> drivers/soc/renesas/renesas-soc.c
>> drivers/soc/tegra/fuse/fuse-tegra.c
>> drivers/soc/ux500/ux500-soc-id.c
>> drivers/soc/versatile/soc-integrator.c
>> drivers/soc/versatile/soc-integrator.c
>>
>> The only SoC drivers that are regular drivers are:
>>
>> drivers/soc/fsl/guts.c
>> drivers/soc/versatile/soc-realview.c
>
> Thanks for pointing it out.
>
> Indeed, the initcall was needed in your set of patches here:
> https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=43565&state=*
> but this work was not continued here. Maybe it will be later
> resubmitted... maybe not... who knows? Therefore I would prefer proper
The work got delayed mainly because of the request for the formal
audit of each usage vs cache coherency. Since it is rather small
cleanup and such audit is time consuming it became a low priority.
> solution for current case (driver), unless patches for mach are being
> brought back to life now.
>
>>> I'm also inclined to have it converted to a regular driver. We already
>>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
>>> The ASV patches will not be merged soon anyway, all this needs some more
>>> thought. Krzysztof, can we abandon the chipid patches for now? Your
>>
>> chipid driver is good and useful on its own. The preferred solution
>> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
>> driver to use the regmap API" commit.
Or just fix it by re-adding removed Exynos chipid compatible checking:
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
index 006a95feb618..d9912bd52479 100644
--- a/drivers/soc/samsung/exynos-chipid.c
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -55,6 +55,11 @@ int __init exynos_chipid_early_init(void)
u32 revision;
int ret;
+ /* look up for chipid node */
+ np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
+ if (!np)
+ return -ENODEV;
+
regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
if (IS_ERR(regmap)) {
pr_err("Failed to get CHIPID regmap\n");
> I queued the chipid as a dependency for ASV but ASV requires the
> regmap. What would be left after reverting the regmap part? Simple
> unused printk driver? No need for such. If reverting, then let's drop
It provides sysfs information about SoC/platform and is useful on its
own (for debugging, reporting etc. purposes). Maybe not terrible useful
but on OTOH the driver is only ~100 LOC.
> entire driver and rework it offline.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] usb: dwc3: meson-g12a: fix suspend resume regulator unbalanced disables
From: Neil Armstrong @ 2019-08-21 13:35 UTC (permalink / raw)
To: balbi
Cc: Neil Armstrong, Kevin Hilman, linux-usb, linux-kernel,
linux-amlogic, linux-arm-kernel
When going in suspend, in Device mode, then resuming back leads
to the following:
unbalanced disables for USB_PWR_EN
WARNING: CPU: 0 PID: 163 at ../drivers/regulator/core.c:2590 _regulator_disable+0x104/0x180
Hardware name: Amlogic Meson G12A U200 Development Board (DT)
[...]
pc : _regulator_disable+0x104/0x180
lr : _regulator_disable+0x104/0x180
[...]
Call trace:
_regulator_disable+0x104/0x180
regulator_disable+0x40/0x78
dwc3_meson_g12a_otg_mode_set+0x84/0xb0
dwc3_meson_g12a_irq_thread+0x58/0xb8
irq_thread_fn+0x28/0x80
irq_thread+0x118/0x1b8
kthread+0xf4/0x120
ret_from_fork+0x10/0x18
This disables the regulator if enabled on suspend, and the reverse on
resume.
Fixes: c99993376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue")
Reported-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/usb/dwc3/dwc3-meson-g12a.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
index bca7e92a10e9..12dda04b004d 100644
--- a/drivers/usb/dwc3/dwc3-meson-g12a.c
+++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
@@ -564,7 +564,13 @@ static int __maybe_unused dwc3_meson_g12a_runtime_resume(struct device *dev)
static int __maybe_unused dwc3_meson_g12a_suspend(struct device *dev)
{
struct dwc3_meson_g12a *priv = dev_get_drvdata(dev);
- int i;
+ int i, ret;
+
+ if (priv->vbus && priv->otg_phy_mode == PHY_MODE_USB_HOST) {
+ ret = regulator_disable(priv->vbus);
+ if (ret)
+ return ret;
+ }
for (i = 0 ; i < PHY_COUNT ; ++i) {
phy_power_off(priv->phys[i]);
@@ -599,6 +605,12 @@ static int __maybe_unused dwc3_meson_g12a_resume(struct device *dev)
return ret;
}
+ if (priv->vbus && priv->otg_phy_mode == PHY_MODE_USB_HOST) {
+ ret = regulator_enable(priv->vbus);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox