* Re: SPE capable Arm CPUs in the fields
From: Sudeep Holla @ 2019-09-20 9:40 UTC (permalink / raw)
To: Itaru Kitayama; +Cc: linux-arm-kernel, Sudeep Holla
In-Reply-To: <864D2B3A-E49A-4F9E-9277-E8B64B36E02B@riken.jp>
On Fri, Sep 20, 2019 at 05:23:38AM +0900, Itaru Kitayama wrote:
> Will,
> Though SPE is just an optional feature of the Armv8.2-A extension, I am
> wondering whether CPUs are already out in the fields or some vendors are
> planning to make one of two in the near future.
>
SPE is available on Neoverse-N1 cores.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: SPE capable Arm CPUs in the fields
From: Itaru Kitayama @ 2019-09-20 9:45 UTC (permalink / raw)
To: Sudeep Holla; +Cc: linux-arm-kernel
In-Reply-To: <20190920094009.GA13906@bogus>
Thank you Sudeep. I look forward to more N1 variants showing up in the market in 2020.
On 2019/09/20 18:40, Sudeep Holla wrote:
> On Fri, Sep 20, 2019 at 05:23:38AM +0900, Itaru Kitayama wrote:
>> Will,
>> Though SPE is just an optional feature of the Armv8.2-A extension, I am
>> wondering whether CPUs are already out in the fields or some vendors are
>> planning to make one of two in the near future.
>>
>
> SPE is available on Neoverse-N1 cores.
>
> --
> Regards,
> Sudeep
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Propagating audio properties along the audio path
From: Marc Gonzalez @ 2019-09-20 9:50 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai, Linux ARM, Jaroslav Kysela
In-Reply-To: <f7861989-8a2d-ed89-8f1f-68bad7013a34@free.fr>
On 17/09/2019 17:33, Marc Gonzalez wrote:
> Disclaimer: I've never worked in the sound/ layer, and it is possible that
> some of my questions are silly or obvious.
>
> Basically, I'm trying to implement some form of eARC(*) on an arm64 SoC.
> (*) enhanced Audio Return Channel (from HDMI 2.1)
>
> The setup looks like this:
>
> A = Some kind of audio source, typically a TV or game console
> B = The arm64 SoC, equipped with some nice speakers
>
> HDMI
> A ------> B
>
> If we look inside B, we actually have
> B1 = an eARC receiver (input = HDMI, output = I2S)
> B2 = an audio DSP (input = I2S, output = speakers)
>
> I2S ?
> B1 -----> B2 -----> speakers
>
>
> If I read the standard right, B is supposed to advertise which audio formats
> it supports, and A is supposed to pick "the best". For the sake of argument,
> let's say A picks "PCM, 48 kHz, 8 channels, 16b".
>
> At some point, B receives audio packets, parses the Channel Status, and
> determines that A is sending "PCM, 48 kHz, 8 channels, 16b". The driver
> then configures the I2S link, and forwards the audio stream over I2S to
> the DSP.
>
> QUESTION_1:
> How is the DSP supposed to "learn" the properties of the audio stream?
> (AFAIU, they're not embedded in the data, so there must be some side-channel?)
> I assume the driver of B1 is supposed to propagate the info to the driver of B2?
> (Via some call-backs? By calling a function in B2?)
>
> QUESTION_2:
> Does it ever make sense for B2 to ask B1 to change the audio properties?
> (Not sure if B1 is even allowed to renegotiate.)
I think it boils down to the "Dynamic PCM" abstraction?
https://www.kernel.org/doc/html/latest/sound/soc/dpcm.html
The downstream driver (7500 lines) is tough to ingest for a noob.
https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/sound/soc/msm/msm8998.c?h=LE.UM.1.3.r3.25
I'll keep chipping at whatever docs I can find.
One more concern popped up: if the audio stream changes mid-capture
(for example, a different TV program uses different audio settings),
then I would detect this in the eARC receiver, but it's not clear
(to me) how to propagate the info to the DSP...
I'm not even sure when the HW params actually get applied...
Is it for SNDRV_PCM_IOCTL_PREPARE? SNDRV_PCM_IOCTL_START?
I couldn't find much documentation for the IOCTLs in the kernel:
$ git grep SNDRV_PCM_IOCTL Documentation/
Documentation/sound/designs/tracepoints.rst:value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE
Documentation/sound/designs/tracepoints.rst:or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available
Documentation/sound/designs/tracepoints.rst: SNDRV_PCM_IOCTL_HW_REFINE only. Applications can select which
Documentation/sound/designs/tracepoints.rst: SNDRV_PCM_IOCTL_HW_PARAMS, this mask is ignored and all of parameters
Documentation/sound/designs/tracepoints.rst: SNDRV_PCM_IOCTL_HW_REFINE to retrieve this flag, then decide candidates
Documentation/sound/designs/tracepoints.rst: of parameters and execute ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS to
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-20 9:55 UTC (permalink / raw)
To: Robin Murphy
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Nicolin Chen,
Y.b. Lu, Christoph Hellwig, Linux ARM
In-Reply-To: <20190919172349.GJ25745@shell.armlinux.org.uk>
On Thu, Sep 19, 2019 at 06:23:49PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Sep 19, 2019 at 03:02:39PM +0100, Robin Murphy wrote:
> > On 19/09/2019 10:16, Russell King - ARM Linux admin wrote:
> > > On Tue, Sep 17, 2019 at 03:03:29PM +0100, Robin Murphy wrote:
> > > > On 17/09/2019 14:49, Russell King - ARM Linux admin wrote:
> > > > > As already replied, v4 mode is not documented as being available on
> > > > > the LX2160A - the bit in the control register is marked as "reserved".
> > > > > This is as expected as it is documented that it is using a v3.00 of
> > > > > the SDHCI standard, rather than v4.00.
> > > > >
> > > > > So, sorry, enabling "v4 mode" isn't a workaround in this scenario.
> > > > >
> > > > > Given that v4 mode is not mandatory, this shouldn't be a work-around.
> > > > >
> > > > > Given that it _does_ work some of the time with the table >4GB, then
> > > > > this is not an addressing limitation.
> > > >
> > > > Yes, that's what "something totally different" usually means.
> > > >
> > > > > > However, the other difference between getting a single page directly from
> > > > > > the page allocator vs. the CMA area is that accesses to the linear mapping
> > > > > > of the CMA area are probably pretty rare, whereas for the single-page case
> > > > > > it's much more likely that kernel tasks using adjacent pages could lead to
> > > > > > prefetching of the descriptor page's cacheable alias. That could certainly
> > > > > > explain how reverting that commit manages to hide an apparent coherency
> > > > > > issue.
> > > > >
> > > > > Right, so how do we fix this?
> > > >
> > > > By describing the hardware correctly in the DT.
> > >
> > > It would appear that it _is_ correctly described given the default
> > > hardware configuration, but the driver sets a bit in a control
> > > register that enables cache snooping.
> >
> > Oh, fun. FWIW, the more general form of that statement would be "by ensuring
> > that the device behaviour and the DT description are consistent", it's just
> > rare to have both degrees of freedom.
> >
> > Even in these cases, though, it tends to be ultimately necessary to defer to
> > what the DT says, because there can be situations where the IP believes
> > itself capable of enabling snoops, but the integration failed to wire things
> > up correctly for them to actually work. I know we have to deal with that in
> > arm-smmu, for one example.
> >
> > > Adding "dma-coherent" to the DT description does not seem to be the
> > > correct solution, as we are reliant on the DT description and driver
> > > implementation both agreeing, which is fragile.
> > >
> > > From what I can see, there isn't a way for a driver to say "I've made
> > > this device is coherent now" and I suspect making the driver set the
> > > DMA snoop bit depending on whether "dma-coherent" is present in DT or
> > > not will cause data-corrupting regressions for other people.
> > >
> > > So, we're back to where we started - what is the right solution to
> > > this problem?
> > >
> > > The only thing I can think is that the driver needs to do something
> > > like:
> > >
> > > WARN_ON(!dev_is_dma_coherent(dev));
> > >
> > > in esdhc_of_enable_dma() as a first step, and ensuring that the snoop
> > > bit matches the state of dev_is_dma_coherent(dev)? Is it permitted to
> > > use dev_is_dma_coherent() in drivers - it doesn't seem to be part of
> > > the normal DMA API?
> >
> > The safest option would be to query the firmware property layer via
> > device_get_dma_attr() - or potentially short-cut to of_dma_is_coherent() for
> > a pure DT driver. Even disregarding API purity, I don't think the DMA API
> > internals are really generic enough yet to reliably poke at (although FWIW,
> > *certain* cases like dma_direct_ops would now actually work as expected if
> > one did the unspeakable and flipped dev->dma_coherent from a driver, but
> > that would definitely not win any friends).
>
> So, I prepared a few options, and option 2 was:
>
> drivers/mmc/host/sdhci-of-esdhc.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index 4dd43b1adf2c..8076a1322499 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -19,6 +19,7 @@
> #include <linux/clk.h>
> #include <linux/ktime.h>
> #include <linux/dma-mapping.h>
> +#include <linux/dma-noncoherent.h>
> #include <linux/mmc/host.h>
> #include <linux/mmc/mmc.h>
> #include "sdhci-pltfm.h"
> @@ -495,7 +496,12 @@ static int esdhc_of_enable_dma(struct sdhci_host *host)
> dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
>
> value = sdhci_readl(host, ESDHC_DMA_SYSCTL);
> - value |= ESDHC_DMA_SNOOP;
> +
> + if (dev_is_dma_coherent(dev))
> + value |= ESDHC_DMA_SNOOP;
> + else
> + value &= ~ESDHC_DMA_SNOOP;
> +
> sdhci_writel(host, value, ESDHC_DMA_SYSCTL);
> return 0;
> }
>
> The dev_is_dma_coherent() could be changed to something like
> device_get_dma_attr() if that's the correct thing to base this
> off of. However, if it returns DEV_DMA_NOT_SUPPORTED, then what?
> Assume non-coherent or assume coherent? What will the DMA API
> layer assume?
>
> It seems to me that we want the DMA API layer and the driver to
> both agree whether the device is to be coherent or not, and for
> the sake of data integrity, we do not want any possibility for
> them to deviate in that decision making process.
I think using of_dma_is_coherent() is the safest, as if the driver
needs to be updated to ACPI, the problem will need to be readdressed.
The conditions on which dev->dma_coherent is set by the ACPI code
differs from the conditions that determine the return value of
acpi_get_dma_attr().
So, how about this:
drivers/mmc/host/sdhci-of-esdhc.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 4dd43b1adf2c..74de5e8c45c8 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -495,7 +495,12 @@ static int esdhc_of_enable_dma(struct sdhci_host *host)
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
value = sdhci_readl(host, ESDHC_DMA_SYSCTL);
- value |= ESDHC_DMA_SNOOP;
+
+ if (of_dma_is_coherent(dev->of_node))
+ value |= ESDHC_DMA_SNOOP;
+ else
+ value &= ~ESDHC_DMA_SNOOP;
+
sdhci_writel(host, value, ESDHC_DMA_SYSCTL);
return 0;
}
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* ARM core blob list
From: Sergey Brutyan @ 2019-09-20 10:15 UTC (permalink / raw)
To: linux-arm-kernel
Dear all we are company of hard/soft design and integration mostly based
on ARM cores.
We are currently working on Libre Linux development for ARM based SBC.
And ready to put professional effort for having complete blob-free Linux
kernel, as we have done research there is most problem with bootloaders
and Mali or PowerVR GPU units in SoC.
We are looking forward to cooperate and now have several need of
information.
Can you send us list for blob drivers for this SoC:
Allwinner A20
Allwinner R40
Broadcom BCM2837
Realtek RTD1395
MediaTek MT7623N
And also please offer us which is the best SoC for blob-free linux
development.
Best regards. Sergey.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: "arm64: use asm-generic/dma-mapping.h" introduced a kbuild warning
From: Masahiro Yamada @ 2019-09-20 10:24 UTC (permalink / raw)
To: Qian Cai
Cc: Michal Marek, Linux Kbuild mailing list,
Linux Kernel Mailing List, Stefano Stabellini, Will Deacon,
Christoph Hellwig, linux-arm-kernel
In-Reply-To: <1568898377.5576.186.camel@lca.pw>
Hi Qian,
On Thu, Sep 19, 2019 at 10:06 PM Qian Cai <cai@lca.pw> wrote:
>
> The commit 5489c8e0cf03 ("arm64: use asm-generic/dma-mapping.h") introduced a
> kbuild warning,
>
> scripts/Makefile.asm-generic:25: redundant generic-y found in
> arch/arm64/include/asm/Kbuild: dma-mapping.h
>
>
Which tree did you test?
I tried the latest Linus tree (, which contains 5489c8e0cf03),
but I did not see this warning.
--
Best Regards
Masahiro Yamada
_______________________________________________
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] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Russell King - ARM Linux admin @ 2019-09-20 10:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Baruch Siach, Shawn Guo, Sascha Hauer, tinywrkb, open list,
Rob Herring, NXP Linux Team, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190917183934.GJ20778@lunn.ch>
On Tue, Sep 17, 2019 at 08:39:34PM +0200, Andrew Lunn wrote:
> > > Well, the _correct_ driver needs to be used for the PHY specific
> > > features to be properly controlled. Using the generic driver
> > > in this situation will not be guaranteed to work.
>
> I fully agree about the PHY driver. I'm expect this device is
> violating c22 when it modifies the advertisement register itself. So
> all bets are off for the genphy.
>
> > Well, this hasn't worked, but not for the obvious reason. Register 0x14
> > is documented as read/write. Bits 15:6 are reserved, bit 5 is the
> > smart speed enable, 4:2 configures the attempts, bit 1 sets the link
> > stable condition, bit 0 is reserved.
> >
> > Writing 0x80c results in the register reading back 0x82c. Writing
> > 0x800 results in the same. Writing 0 reads back 0x2c. Writing 0xffff
> > seems to prevent packets being passed - and at that point I lost
> > control so I couldn't see what the result was.
> >
> > There is nothing in the data sheet which suggests that there is any
> > gating of this register. So it looks like we're stuck with smartspeed
> > enabled.
> >
> > So, I think there's only two remaining ways forward - to revert commit
> > 5502b218e001 to restore the old behaviour, read back the advertisement
> > from the PHY along with the rest of the status, as I've previously
> > stated. It means that phylib will modify phydev->advertising at
> > random points, just as it modifies phydev->lp_advertising, so locking
> > may become an issue. The revert approach is probably best until we
> > have something working along those lines.
>
> We have a couple of other PHYs which support downshift. We should see
> if we can follow what they do. What is i think important is that
> read_status return the correct speed. So we probably cannot use
> genphy_read_status() as is. Maybe we should split genphy_read_status()
> into two, so the register reading bit can be done unconditionally by
> phy drivers for hardware which don't report link down when they
> should?
I think we need to check how the downshift feature works on other PHYs
and whether it is enabled there.
Looking at the Marvell 88e151x PHYs, they have the feature, but do not
enable it by default. If firmware has enabled the feature, phylib will
incorrectly resolve the link speed based on just the advertisements.
I think the safest way in the case of both PHYs to ascertain the real
link speed is to read the Specific Status register - register 17 in
both cases. The top two bits indicate the negotiated speed resolution
and bit 13 indicates the duplex. Bit 11 indicates whether the
resolution is valid. This register layout seems to apply to both
88e151x and AR8035.
The register also contains the pause mode resolution in terms of
receive or transmit pause enabled, but this is not useful to phylib
as that is not what phylib wants to know. However, it probably makes
sense for phylib to resolve the pause mode negotiation itself rather
than having that logic in the MAC drivers.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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] spi: atmel: Fix crash when using more than 4 gpio CS
From: Mark Brown @ 2019-09-20 10:51 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Gregory CLEMENT, stable, linux-kernel, Ludovic Desroches,
Thomas Petazzoni, linux-spi, linux-arm-kernel
In-Reply-To: <20190919172350.GZ21254@piout.net>
[-- Attachment #1.1: Type: text/plain, Size: 652 bytes --]
On Thu, Sep 19, 2019 at 07:23:50PM +0200, Alexandre Belloni wrote:
> On 19/09/2019 17:03:15+0100, Mark Brown wrote:
> > This is going to break any system where we use both a GPIO chip select
> > and chip select 0. Ideally we'd try to figure out an unused chip select
> > to use here...
> The point is that this use case is already broken and this patch fixes
> the crash and is easily backportable.
> Fixing the CS + gpio CS should probably be done in a separate patch.
If the GPIO is overlaid on any of the existing slots (except GPIO 0)
then it'll cause GPIO 0 to start toggling. I'm not convinced that the
code doesn't currently support that.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 1/4] spi: mxic: Fix transmit path
From: Mark Brown @ 2019-09-20 11:02 UTC (permalink / raw)
To: Miquel Raynal
Cc: Julien Su, stable, linux-spi, Boris Brezillon, Thomas Petazzoni,
Mason Yang, linux-arm-kernel
In-Reply-To: <20190919202504.9619-1-miquel.raynal@bootlin.com>
[-- Attachment #1.1: Type: text/plain, Size: 301 bytes --]
On Thu, Sep 19, 2019 at 10:25:01PM +0200, Miquel Raynal wrote:
> In certain circumstances, it is needed to check INT_TX_EMPTY and
> INT_RX_NOT_EMPTY in the transmit path, not only in the receive
> path. In both cases, the delay penalty is negligible.
In which circumstances and why is this required?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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
* Applied "spi: mxic: Fix DMAS_CTRL register layout" to the spi tree
From: Mark Brown @ 2019-09-20 11:09 UTC (permalink / raw)
To: Miquel Raynal
Cc: Julien Su, linux-spi, Mark Brown, Thomas Petazzoni,
Boris Brezillon, Mason Yang, linux-arm-kernel
In-Reply-To: <20190919202504.9619-4-miquel.raynal@bootlin.com>
The patch
spi: mxic: Fix DMAS_CTRL register layout
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 6fe7ab3837bdbc4830addac9898a5e4bc0783dcc Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal@bootlin.com>
Date: Thu, 19 Sep 2019 22:25:04 +0200
Subject: [PATCH] spi: mxic: Fix DMAS_CTRL register layout
Fix the current layout which only matches early non-public revisions
of the IP. Since its official distribution, two bytes of the SPI
controller DMAS_CTRL register have been inverted.
Suggested-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20190919202504.9619-4-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-mxic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index b641954fdc4b..a736fdf47119 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -145,8 +145,8 @@
#define LWR_SUSP_CTRL_EN BIT(31)
#define DMAS_CTRL 0x9c
-#define DMAS_CTRL_DIR_READ BIT(31)
-#define DMAS_CTRL_EN BIT(30)
+#define DMAS_CTRL_EN BIT(31)
+#define DMAS_CTRL_DIR_READ BIT(30)
#define DATA_STROB 0xa0
#define DATA_STROB_EDO_EN BIT(2)
--
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
* Applied "spi: mxic: Select SPI_NOR type by default" to the spi tree
From: Mark Brown @ 2019-09-20 11:09 UTC (permalink / raw)
To: Miquel Raynal
Cc: Julien Su, linux-spi, Mark Brown, Thomas Petazzoni,
Boris Brezillon, Mason Yang, linux-arm-kernel
In-Reply-To: <20190919202504.9619-3-miquel.raynal@bootlin.com>
The patch
spi: mxic: Select SPI_NOR type by default
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 4a82fe0e184263b5ed8f9d8079f7dfd144598127 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal@bootlin.com>
Date: Thu, 19 Sep 2019 22:25:03 +0200
Subject: [PATCH] spi: mxic: Select SPI_NOR type by default
The SPI_NAND bit is a (wrongly named) placeholder that is intended
to be used in the future. Right now SPI_NOR (which is currently
identical to SPI_NAND in this version of the IP) should be used in
both cases.
Suggested-by: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20190919202504.9619-3-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-mxic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index f48563c09b97..b641954fdc4b 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -275,7 +275,7 @@ static void mxic_spi_hw_init(struct mxic_spi *mxic)
writel(0, mxic->regs + HC_EN);
writel(0, mxic->regs + LRD_CFG);
writel(0, mxic->regs + LRD_CTRL);
- writel(HC_CFG_NIO(1) | HC_CFG_TYPE(0, HC_CFG_TYPE_SPI_NAND) |
+ writel(HC_CFG_NIO(1) | HC_CFG_TYPE(0, HC_CFG_TYPE_SPI_NOR) |
HC_CFG_SLV_ACT(0) | HC_CFG_MAN_CS_EN | HC_CFG_IDLE_SIO_LVL(1),
mxic->regs + HC_CFG);
}
--
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
* [PATCH v2] ethernet: axienet: Use devm_platform_ioremap_resource() in axienet_probe()
From: Markus Elfring @ 2019-09-20 11:30 UTC (permalink / raw)
To: netdev, linux-arm-kernel, David S. Miller, Michal Simek,
Radhey Shyam Pandey
Cc: kernel-janitors, LKML
In-Reply-To: <CH2PR02MB700047AFFFE08FE5FD563541C78E0@CH2PR02MB7000.namprd02.prod.outlook.com>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 20 Sep 2019 13:17:01 +0200
Simplify this function implementation by using the wrapper function
“devm_platform_ioremap_resource” instead of calling the functions
“platform_get_resource” and “devm_ioremap_resource” directly.
* Thus reduce also a bit of exception handling code here.
* Delete the local variable “res”.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
v2:
Further changes were requested by Radhey Shyam Pandey.
https://lore.kernel.org/r/CH2PR02MB700047AFFFE08FE5FD563541C78E0@CH2PR02MB7000.namprd02.prod.outlook.com/
* Updates for three modules were split into a separate patch for each driver.
* The commit description was adjusted.
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 4fc627fb4d11..92783aaaa0a2 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1787,14 +1787,7 @@ static int axienet_probe(struct platform_device *pdev)
of_node_put(np);
lp->eth_irq = platform_get_irq(pdev, 0);
} else {
- /* Check for these resources directly on the Ethernet node. */
- struct resource *res = platform_get_resource(pdev,
- IORESOURCE_MEM, 1);
- if (!res) {
- dev_err(&pdev->dev, "unable to get DMA memory resource\n");
- goto free_netdev;
- }
- lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
+ lp->dma_regs = devm_platform_ioremap_resource(pdev, 1);
lp->rx_irq = platform_get_irq(pdev, 1);
lp->tx_irq = platform_get_irq(pdev, 0);
lp->eth_irq = platform_get_irq(pdev, 2);
--
2.23.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
* [PATCH] iio: adc: stm32-adc: fix kernel-doc warnings
From: Fabrice Gasnier @ 2019-09-20 11:50 UTC (permalink / raw)
To: jic23
Cc: lars, alexandre.torgue, linux-iio, pmeerw, linux-kernel,
mcoquelin.stm32, knaack.h, fabrice.gasnier, linux-stm32,
linux-arm-kernel
Fix the following warnings when documentation is built:
drivers/iio/adc/stm32-adc-core.c:62: warning: cannot understand function
prototype: 'struct stm32_adc_common_regs '
drivers/iio/adc/stm32-adc-core.c:78: warning: cannot understand function
prototype: 'struct stm32_adc_priv_cfg '
drivers/iio/adc/stm32-adc-core.c:123: warning: Function parameter or
member 'pdev' not described in 'stm32f4_adc_clk_sel'
drivers/iio/adc/stm32-adc.c:219: warning: cannot understand function
prototype: 'struct stm32_adc_regs '
drivers/iio/adc/stm32-adc.c:237: warning: cannot understand function
prototype: 'struct stm32_adc_regspec '
drivers/iio/adc/stm32-adc.c:264: warning: cannot understand function
prototype: 'struct stm32_adc_cfg '
drivers/iio/adc/stm32-adc.c:323: warning: Function parameter or member
'difsel' not described in 'N'
drivers/iio/adc/stm32-adc.c:323: warning: Function parameter or member
'pcsel' not described in 'stm32_adc'
drivers/iio/adc/stm32-adc.c:371: warning: cannot understand function
prototype: 'const struct stm32_adc_regs stm32f4_sq[STM32_ADC_MAX_SQ + 1]
drivers/iio/adc/stm32-adc.c:417: warning: cannot understand function
prototype: 'const struct stm32_adc_regs stm32f4_smp_bits[] = '
drivers/iio/adc/stm32-adc.c:508: warning: cannot understand function
prototype: 'const struct stm32_adc_regs stm32h7_smp_bits[] = '
drivers/iio/adc/stm32-adc.c:1112: warning: Function parameter or member
'indio_dev' not described in 'stm32_adc_get_trig_extsel'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'indio_dev' not described in 'stm32_adc_debugfs_reg_access'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'reg' not described in 'stm32_adc_debugfs_reg_access'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'writeval' not described in 'stm32_adc_debugfs_reg_access'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'readval' not described in 'stm32_adc_debugfs_reg_access'
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
Note: this applies on top of "iio: adc: stm32-adc: fix a race when using
several adcs with dma and irq"
---
drivers/iio/adc/stm32-adc-core.c | 11 ++++++-----
drivers/iio/adc/stm32-adc.c | 21 +++++++++++++--------
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
index 93a096a..20c626c 100644
--- a/drivers/iio/adc/stm32-adc-core.c
+++ b/drivers/iio/adc/stm32-adc-core.c
@@ -38,12 +38,12 @@
#define HAS_ANASWVDD BIT(1)
/**
- * stm32_adc_common_regs - stm32 common registers, compatible dependent data
+ * struct stm32_adc_common_regs - stm32 common registers
* @csr: common status register offset
* @ccr: common control register offset
- * @eoc1: adc1 end of conversion flag in @csr
- * @eoc2: adc2 end of conversion flag in @csr
- * @eoc3: adc3 end of conversion flag in @csr
+ * @eoc1_msk: adc1 end of conversion flag in @csr
+ * @eoc2_msk: adc2 end of conversion flag in @csr
+ * @eoc3_msk: adc3 end of conversion flag in @csr
* @ier: interrupt enable register offset for each adc
* @eocie_msk: end of conversion interrupt enable mask in @ier
*/
@@ -60,7 +60,7 @@ struct stm32_adc_common_regs {
struct stm32_adc_priv;
/**
- * stm32_adc_priv_cfg - stm32 core compatible configuration data
+ * struct stm32_adc_priv_cfg - stm32 core compatible configuration data
* @regs: common registers for all instances
* @clk_sel: clock selection routine
* @max_clk_rate_hz: maximum analog clock rate (Hz, from datasheet)
@@ -117,6 +117,7 @@ static int stm32f4_pclk_div[] = {2, 4, 6, 8};
/**
* stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
+ * @pdev: platform device
* @priv: stm32 ADC core private data
* Select clock prescaler used for analog conversions, before using ADC.
*/
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
index 663f8a5..76a247b 100644
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -102,7 +102,7 @@ struct stm32_adc_calib {
};
/**
- * stm32_adc_regs - stm32 ADC misc registers & bitfield desc
+ * struct stm32_adc_regs - stm32 ADC misc registers & bitfield desc
* @reg: register offset
* @mask: bitfield mask
* @shift: left shift
@@ -114,7 +114,7 @@ struct stm32_adc_regs {
};
/**
- * stm32_adc_regspec - stm32 registers definition, compatible dependent data
+ * struct stm32_adc_regspec - stm32 registers definition
* @dr: data register offset
* @ier_eoc: interrupt enable register & eocie bitfield
* @isr_eoc: interrupt status register & eoc bitfield
@@ -140,7 +140,7 @@ struct stm32_adc_regspec {
struct stm32_adc;
/**
- * stm32_adc_cfg - stm32 compatible configuration data
+ * struct stm32_adc_cfg - stm32 compatible configuration data
* @regs: registers descriptions
* @adc_info: per instance input channels definitions
* @trigs: external trigger sources
@@ -183,8 +183,8 @@ struct stm32_adc_cfg {
* @rx_buf: dma rx buffer cpu address
* @rx_dma_buf: dma rx buffer bus address
* @rx_buf_sz: dma rx buffer size
- * @difsel bitmask to set single-ended/differential channel
- * @pcsel bitmask to preselect channels on some devices
+ * @difsel: bitmask to set single-ended/differential channel
+ * @pcsel: bitmask to preselect channels on some devices
* @smpr_val: sampling time settings (e.g. smpr1 / smpr2)
* @cal: optional calibration data on some devices
* @chan_name: channel name array
@@ -254,7 +254,7 @@ static const struct stm32_adc_info stm32h7_adc_info = {
.num_res = ARRAY_SIZE(stm32h7_adc_resolutions),
};
-/**
+/*
* stm32f4_sq - describe regular sequence registers
* - L: sequence len (register & bit field)
* - SQ1..SQ16: sequence entries (register & bit field)
@@ -301,7 +301,7 @@ static struct stm32_adc_trig_info stm32f4_adc_trigs[] = {
{}, /* sentinel */
};
-/**
+/*
* stm32f4_smp_bits[] - describe sampling time register index & bit fields
* Sorted so it can be indexed by channel number.
*/
@@ -392,7 +392,7 @@ static struct stm32_adc_trig_info stm32h7_adc_trigs[] = {
{},
};
-/**
+/*
* stm32h7_smp_bits - describe sampling time register index & bit fields
* Sorted so it can be indexed by channel number.
*/
@@ -994,6 +994,7 @@ static int stm32_adc_conf_scan_seq(struct iio_dev *indio_dev,
/**
* stm32_adc_get_trig_extsel() - Get external trigger selection
+ * @indio_dev: IIO device structure
* @trig: trigger
*
* Returns trigger extsel value, if trig matches, -EINVAL otherwise.
@@ -1297,6 +1298,10 @@ static int stm32_adc_of_xlate(struct iio_dev *indio_dev,
/**
* stm32_adc_debugfs_reg_access - read or write register value
+ * @indio_dev: IIO device structure
+ * @reg: register offset
+ * @writeval: value to write
+ * @readval: value to read
*
* To read a value from an ADC register:
* echo [ADC reg offset] > direct_reg_access
--
2.7.4
_______________________________________________
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/2] dt-bindings: arm: fsl: Add PHYTEC i.MX6 devicetree bindings
From: Stefan Riedmueller @ 2019-09-20 11:52 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Stefan Riedmueller, Andrew Smirnov,
Fabio Estevam, Sascha Hauer, linux-kernel, Rob Herring, linux-imx,
Manivannan Sadhasivam, Shawn Guo
In-Reply-To: <1568980346-385840-1-git-send-email-s.riedmueller@phytec.de>
Add devicetree bindings for i.MX6 based phyCORE-i.MX6, phyBOARD-Mira and
phyFLEX-i.MX6.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
Changes in v2:
- Use seperate description for each board instead of squashing them into
the standard board.
---
Documentation/devicetree/bindings/arm/fsl.yaml | 37 ++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index c926ff6eac67..7dbb45cebb86 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -116,6 +116,21 @@ properties:
- technologic,imx6q-ts7970
- const: fsl,imx6q
+ - description: i.MX6Q PHYTEC phyBOARD-Mira
+ items:
+ - enum:
+ - phytec,imx6q-pbac06-emmc # PHYTEC phyBOARD-Mira eMMC RDK
+ - phytec,imx6q-pbac06-nand # PHYTEC phyBOARD-Mira NAND RDK
+ - const: phytec,imx6q-pbac06 # PHYTEC phyBOARD-Mira
+ - const: phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+ - const: fsl,imx6q
+
+ - description: i.MX6Q PHYTEC phyFLEX-i.MX6
+ items:
+ - const: phytec,imx6q-pbab01 # PHYTEC phyFLEX carrier board
+ - const: phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
+ - const: fsl,imx6q
+
- description: i.MX6QP based Boards
items:
- enum:
@@ -123,6 +138,13 @@ properties:
- fsl,imx6qp-sabresd # i.MX6 Quad Plus SABRE Smart Device Board
- const: fsl,imx6qp
+ - description: i.MX6QP PHYTEC phyBOARD-Mira
+ items:
+ - const: phytec,imx6qp-pbac06-nand
+ - const: phytec,imx6qp-pbac06 # PHYTEC phyBOARD-Mira
+ - const: phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+ - const: fsl,imx6qp
+
- description: i.MX6DL based Boards
items:
- enum:
@@ -138,6 +160,21 @@ properties:
- ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board
- const: fsl,imx6dl
+ - description: i.MX6DL PHYTEC phyBOARD-Mira
+ items:
+ - enum:
+ - phytec,imx6dl-pbac06-emmc # PHYTEC phyBOARD-Mira eMMC RDK
+ - phytec,imx6dl-pbac06-nand # PHYTEC phyBOARD-Mira NAND RDK
+ - const: phytec,imx6dl-pbac06 # PHYTEC phyBOARD-Mira
+ - const: phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+ - const: fsl,imx6dl
+
+ - description: i.MX6DL PHYTEC phyFLEX-i.MX6
+ items:
+ - const: phytec,imx6dl-pbab01 # PHYTEC phyFLEX carrier board
+ - const: phytec,imx6dl-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
+ - const: fsl,imx6dl
+
- description: i.MX6SL based Boards
items:
- enum:
--
2.7.4
_______________________________________________
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 1/2] dt-bindings: arm: fsl: Add PHYTEC i.MX6 UL/ULL devicetree bindings
From: Stefan Riedmueller @ 2019-09-20 11:52 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Stefan Riedmueller, Andrew Smirnov,
Fabio Estevam, Sascha Hauer, linux-kernel, Rob Herring, linux-imx,
Manivannan Sadhasivam, Shawn Guo
Add devicetree bindings for i.MX6 UL/ULL based phyCORE-i.MX6 UL/ULL and
phyBOARD-Segin.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
Changes in v2:
- Use seperate description for each board instead of squashing them into
the standard board.
---
Documentation/devicetree/bindings/arm/fsl.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1b4b4e6573b5..c926ff6eac67 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -164,6 +164,15 @@ properties:
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
- const: fsl,imx6ul
+ - description: i.MX6UL PHYTEC phyBOARD-Segin
+ items:
+ - enum:
+ - phytec,imx6ul-pbacd10-emmc
+ - phytec,imx6ul-pbacd10-nand
+ - const: phytec,imx6ul-pbacd10 # PHYTEC phyBOARD-Segin with i.MX6 UL
+ - const: phytec,imx6ul-pcl063 # PHYTEC phyCORE-i.MX 6UL
+ - const: fsl,imx6ul
+
- description: Kontron N6310 S Board
items:
- const: kontron,imx6ul-n6310-s
@@ -183,6 +192,15 @@ properties:
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
- const: fsl,imx6ull
+ - description: i.MX6ULL PHYTEC phyBOARD-Segin
+ items:
+ - enum:
+ - phytec,imx6ull-pbacd10-emmc
+ - phytec,imx6ull-pbacd10-nand
+ - const: phytec,imx6ull-pbacd10 # PHYTEC phyBOARD-Segin with i.MX6 ULL
+ - const: phytec,imx6ull-pcl063 # PHYTEC phyCORE-i.MX 6ULL
+ - const: fsl,imx6ull
+
- description: i.MX6ULZ based Boards
items:
- enum:
--
2.7.4
_______________________________________________
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: SPE capable Arm CPUs in the fields
From: Hanjun Guo @ 2019-09-20 11:56 UTC (permalink / raw)
To: Itaru Kitayama, Sudeep Holla; +Cc: linux-arm-kernel
In-Reply-To: <c41d681c-3486-022e-e988-9445f78c3ef8@riken.jp>
On 2019/9/20 17:45, Itaru Kitayama wrote:
> Thank you Sudeep. I look forward to more N1 variants showing up in the market in 2020.
HiSilicon Kunpeng 920 (ARM64 server chip) has SPE feature and we are working on
this to enable it with more perf support:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2067868.html
Thanks
Hanjun
_______________________________________________
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 v2] ethernet: axienet: Use devm_platform_ioremap_resource() in axienet_probe()
From: Radhey Shyam Pandey @ 2019-09-20 11:57 UTC (permalink / raw)
To: Markus Elfring, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, David S. Miller,
Michal Simek
Cc: kernel-janitors@vger.kernel.org, LKML
In-Reply-To: <604a6376-0298-ebcd-ee84-435945370374@web.de>
> -----Original Message-----
> From: Markus Elfring <Markus.Elfring@web.de>
> Sent: Friday, September 20, 2019 5:01 PM
> To: netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org; David S.
> Miller <davem@davemloft.net>; Michal Simek <michals@xilinx.com>;
> Radhey Shyam Pandey <radheys@xilinx.com>
> Cc: LKML <linux-kernel@vger.kernel.org>; kernel-janitors@vger.kernel.org
> Subject: [PATCH v2] ethernet: axienet: Use
> devm_platform_ioremap_resource() in axienet_probe()
>
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 20 Sep 2019 13:17:01 +0200
>
> Simplify this function implementation by using the wrapper function
> “devm_platform_ioremap_resource” instead of calling the functions
> “platform_get_resource” and “devm_ioremap_resource” directly.
>
> * Thus reduce also a bit of exception handling code here.
> * Delete the local variable “res”.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Thanks!
> ---
>
> v2:
> Further changes were requested by Radhey Shyam Pandey.
> https://lore.kernel.org/r/CH2PR02MB700047AFFFE08FE5FD563541C78E0@C
> H2PR02MB7000.namprd02.prod.outlook.com/
>
> * Updates for three modules were split into a separate patch for each driver.
> * The commit description was adjusted.
>
>
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 4fc627fb4d11..92783aaaa0a2 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1787,14 +1787,7 @@ static int axienet_probe(struct platform_device
> *pdev)
> of_node_put(np);
> lp->eth_irq = platform_get_irq(pdev, 0);
> } else {
> - /* Check for these resources directly on the Ethernet node.
> */
> - struct resource *res = platform_get_resource(pdev,
> -
> IORESOURCE_MEM, 1);
> - if (!res) {
> - dev_err(&pdev->dev, "unable to get DMA memory
> resource\n");
> - goto free_netdev;
> - }
> - lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
> + lp->dma_regs = devm_platform_ioremap_resource(pdev, 1);
> lp->rx_irq = platform_get_irq(pdev, 1);
> lp->tx_irq = platform_get_irq(pdev, 0);
> lp->eth_irq = platform_get_irq(pdev, 2);
> --
> 2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mt7601u: phy: simplify zero check on val
From: Colin King @ 2019-09-20 12:54 UTC (permalink / raw)
To: Jakub Kicinski, Kalle Valo, David S . Miller, Matthias Brugger,
linux-wireless, netdev, linux-arm-kernel, linux-mediatek
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently the zero check on val to break out of a loop
is a little obscure. Replace the val is zero and break check
with a loop while value is non-zero.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/mediatek/mt7601u/phy.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/phy.c b/drivers/net/wireless/mediatek/mt7601u/phy.c
index 06f5702ab4bd..4e0e473caae1 100644
--- a/drivers/net/wireless/mediatek/mt7601u/phy.c
+++ b/drivers/net/wireless/mediatek/mt7601u/phy.c
@@ -213,9 +213,7 @@ int mt7601u_wait_bbp_ready(struct mt7601u_dev *dev)
do {
val = mt7601u_bbp_rr(dev, MT_BBP_REG_VERSION);
- if (val && ~val)
- break;
- } while (--i);
+ } while (val && --i);
if (!i) {
dev_err(dev->dev, "Error: BBP is not ready\n");
--
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
* [PATCH v2 00/10] Basic sound support for Arndale board / wm8994 updates
From: Sylwester Nawrocki @ 2019-09-20 13:02 UTC (permalink / raw)
To: broonie, krzk
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, Sylwester Nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <CGME20190920130238eucas1p147fca337fa84592ac7f83760449e26a1@eucas1p1.samsung.com>
This patch series adds basic audio support for Exynos5250 SoC based Arndale
board, the Bluetooth receiver source and HDMI output are not covered yet.
There is also one fix for wm8994 driver related to WM1811 CODEC and wm8994
updates to handle MCLK clocks, similar to patches:
ae1ea48c5c59 ("ASoC: arizona: Add gating for source clocks of the FLLs")
7a4413d0dc96 ("ASoC: arizona: Add gating for clock when used for direct MCLK")
The main changes since v1:
- Fixed bug in "ASoC: wm8994: Add support for MCLKn clock gating" patch
(thanks to Charles),
- dropped the MFD part patch and moved getting of clocks to the CODEC driver,
- Added missing Kconfig entries to patch "ASoC: samsung: arndale: Add
support for WM1811 CODEC",
- Added a patch renaming the driver and a patch for exynos_defconfig.
Sylwester Nawrocki (10):
ASoC: wm8994: Do not register inapplicable controls for WM1811
ASoC: samsung: arndale: Add missing OF node dereferencing
ASoC: wm8994: Add support for setting MCLK clock rate
ASoC: wm8994: Add support for MCLKn clock gating
ASoC: samsung: arndale: Simplify DAI link initialization
ASoC: dt-bindings: Document "samsung,arndale-wm1811" compatible
ASoC: samsung: arndale: Add support for WM1811 CODEC
ASoC: samsung: Rename Arndale card driver
ARM: dts: arndale: Add audio support (WM1811 CODEC boards)
ARM: exynos_defconfig: Enable Arndale audio driver
.../devicetree/bindings/sound/arndale.txt | 5 +-
arch/arm/boot/dts/exynos5250-arndale.dts | 27 ++-
arch/arm/configs/exynos_defconfig | 1 +
sound/soc/codecs/wm8994.c | 199 +++++++++++++---
sound/soc/codecs/wm8994.h | 10 +-
sound/soc/samsung/Kconfig | 12 +-
sound/soc/samsung/Makefile | 4 +-
sound/soc/samsung/arndale.c | 217 ++++++++++++++++++
sound/soc/samsung/arndale_rt5631.c | 138 -----------
9 files changed, 438 insertions(+), 175 deletions(-)
create mode 100644 sound/soc/samsung/arndale.c
delete mode 100644 sound/soc/samsung/arndale_rt5631.c
--
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
* [PATCH v2 01/10] ASoC: wm8994: Do not register inapplicable controls for WM1811
From: Sylwester Nawrocki @ 2019-09-20 13:02 UTC (permalink / raw)
To: broonie, krzk
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, Sylwester Nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190920130218.32690-1-s.nawrocki@samsung.com>
In case of WM1811 device there are currently being registered controls
referring to registers not existing on that device.
It has been noticed when getting values of "AIF1ADC2 Volume", "AIF1DAC2
Volume" controls was failing during ALSA state restoring at boot time:
"amixer: Mixer hw:0 load error: Device or resource busy"
Reading some registers through I2C was failing with EBUSY error and
indeed these registers were not available according to the datasheet.
To fix this controls not available on WM1811 are moved to a separate
array and registered only for WM8994 and WM8958.
There are some further differences between WM8994 and WM1811,
e.g. registers 603h, 604h, 605h, which are not covered in this patch.
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes since v1:
- only Acked-by tags addition
---
sound/soc/codecs/wm8994.c | 43 +++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index c3d06e8bc54f..d5fb7f5dd551 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -533,13 +533,10 @@ static SOC_ENUM_SINGLE_DECL(dac_osr,
static SOC_ENUM_SINGLE_DECL(adc_osr,
WM8994_OVERSAMPLING, 1, osr_text);
-static const struct snd_kcontrol_new wm8994_snd_controls[] = {
+static const struct snd_kcontrol_new wm8994_common_snd_controls[] = {
SOC_DOUBLE_R_TLV("AIF1ADC1 Volume", WM8994_AIF1_ADC1_LEFT_VOLUME,
WM8994_AIF1_ADC1_RIGHT_VOLUME,
1, 119, 0, digital_tlv),
-SOC_DOUBLE_R_TLV("AIF1ADC2 Volume", WM8994_AIF1_ADC2_LEFT_VOLUME,
- WM8994_AIF1_ADC2_RIGHT_VOLUME,
- 1, 119, 0, digital_tlv),
SOC_DOUBLE_R_TLV("AIF2ADC Volume", WM8994_AIF2_ADC_LEFT_VOLUME,
WM8994_AIF2_ADC_RIGHT_VOLUME,
1, 119, 0, digital_tlv),
@@ -556,8 +553,6 @@ SOC_ENUM("AIF2DACR Source", aif2dacr_src),
SOC_DOUBLE_R_TLV("AIF1DAC1 Volume", WM8994_AIF1_DAC1_LEFT_VOLUME,
WM8994_AIF1_DAC1_RIGHT_VOLUME, 1, 96, 0, digital_tlv),
-SOC_DOUBLE_R_TLV("AIF1DAC2 Volume", WM8994_AIF1_DAC2_LEFT_VOLUME,
- WM8994_AIF1_DAC2_RIGHT_VOLUME, 1, 96, 0, digital_tlv),
SOC_DOUBLE_R_TLV("AIF2DAC Volume", WM8994_AIF2_DAC_LEFT_VOLUME,
WM8994_AIF2_DAC_RIGHT_VOLUME, 1, 96, 0, digital_tlv),
@@ -565,17 +560,12 @@ SOC_SINGLE_TLV("AIF1 Boost Volume", WM8994_AIF1_CONTROL_2, 10, 3, 0, aif_tlv),
SOC_SINGLE_TLV("AIF2 Boost Volume", WM8994_AIF2_CONTROL_2, 10, 3, 0, aif_tlv),
SOC_SINGLE("AIF1DAC1 EQ Switch", WM8994_AIF1_DAC1_EQ_GAINS_1, 0, 1, 0),
-SOC_SINGLE("AIF1DAC2 EQ Switch", WM8994_AIF1_DAC2_EQ_GAINS_1, 0, 1, 0),
SOC_SINGLE("AIF2 EQ Switch", WM8994_AIF2_EQ_GAINS_1, 0, 1, 0),
WM8994_DRC_SWITCH("AIF1DAC1 DRC Switch", WM8994_AIF1_DRC1_1, 2),
WM8994_DRC_SWITCH("AIF1ADC1L DRC Switch", WM8994_AIF1_DRC1_1, 1),
WM8994_DRC_SWITCH("AIF1ADC1R DRC Switch", WM8994_AIF1_DRC1_1, 0),
-WM8994_DRC_SWITCH("AIF1DAC2 DRC Switch", WM8994_AIF1_DRC2_1, 2),
-WM8994_DRC_SWITCH("AIF1ADC2L DRC Switch", WM8994_AIF1_DRC2_1, 1),
-WM8994_DRC_SWITCH("AIF1ADC2R DRC Switch", WM8994_AIF1_DRC2_1, 0),
-
WM8994_DRC_SWITCH("AIF2DAC DRC Switch", WM8994_AIF2_DRC_1, 2),
WM8994_DRC_SWITCH("AIF2ADCL DRC Switch", WM8994_AIF2_DRC_1, 1),
WM8994_DRC_SWITCH("AIF2ADCR DRC Switch", WM8994_AIF2_DRC_1, 0),
@@ -594,9 +584,6 @@ SOC_SINGLE("Sidetone HPF Switch", WM8994_SIDETONE, 6, 1, 0),
SOC_ENUM("AIF1ADC1 HPF Mode", aif1adc1_hpf),
SOC_DOUBLE("AIF1ADC1 HPF Switch", WM8994_AIF1_ADC1_FILTERS, 12, 11, 1, 0),
-SOC_ENUM("AIF1ADC2 HPF Mode", aif1adc2_hpf),
-SOC_DOUBLE("AIF1ADC2 HPF Switch", WM8994_AIF1_ADC2_FILTERS, 12, 11, 1, 0),
-
SOC_ENUM("AIF2ADC HPF Mode", aif2adc_hpf),
SOC_DOUBLE("AIF2ADC HPF Switch", WM8994_AIF2_ADC_FILTERS, 12, 11, 1, 0),
@@ -637,6 +624,24 @@ SOC_SINGLE("AIF2DAC 3D Stereo Switch", WM8994_AIF2_DAC_FILTERS_2,
8, 1, 0),
};
+/* Controls not available on WM1811 */
+static const struct snd_kcontrol_new wm8994_snd_controls[] = {
+SOC_DOUBLE_R_TLV("AIF1ADC2 Volume", WM8994_AIF1_ADC2_LEFT_VOLUME,
+ WM8994_AIF1_ADC2_RIGHT_VOLUME,
+ 1, 119, 0, digital_tlv),
+SOC_DOUBLE_R_TLV("AIF1DAC2 Volume", WM8994_AIF1_DAC2_LEFT_VOLUME,
+ WM8994_AIF1_DAC2_RIGHT_VOLUME, 1, 96, 0, digital_tlv),
+
+SOC_SINGLE("AIF1DAC2 EQ Switch", WM8994_AIF1_DAC2_EQ_GAINS_1, 0, 1, 0),
+
+WM8994_DRC_SWITCH("AIF1DAC2 DRC Switch", WM8994_AIF1_DRC2_1, 2),
+WM8994_DRC_SWITCH("AIF1ADC2L DRC Switch", WM8994_AIF1_DRC2_1, 1),
+WM8994_DRC_SWITCH("AIF1ADC2R DRC Switch", WM8994_AIF1_DRC2_1, 0),
+
+SOC_ENUM("AIF1ADC2 HPF Mode", aif1adc2_hpf),
+SOC_DOUBLE("AIF1ADC2 HPF Switch", WM8994_AIF1_ADC2_FILTERS, 12, 11, 1, 0),
+};
+
static const struct snd_kcontrol_new wm8994_eq_controls[] = {
SOC_SINGLE_TLV("AIF1DAC1 EQ1 Volume", WM8994_AIF1_DAC1_EQ_GAINS_1, 11, 31, 0,
eq_tlv),
@@ -4258,13 +4263,15 @@ static int wm8994_component_probe(struct snd_soc_component *component)
wm8994_handle_pdata(wm8994);
wm_hubs_add_analogue_controls(component);
- snd_soc_add_component_controls(component, wm8994_snd_controls,
- ARRAY_SIZE(wm8994_snd_controls));
+ snd_soc_add_component_controls(component, wm8994_common_snd_controls,
+ ARRAY_SIZE(wm8994_common_snd_controls));
snd_soc_dapm_new_controls(dapm, wm8994_dapm_widgets,
ARRAY_SIZE(wm8994_dapm_widgets));
switch (control->type) {
case WM8994:
+ snd_soc_add_component_controls(component, wm8994_snd_controls,
+ ARRAY_SIZE(wm8994_snd_controls));
snd_soc_dapm_new_controls(dapm, wm8994_specific_dapm_widgets,
ARRAY_SIZE(wm8994_specific_dapm_widgets));
if (control->revision < 4) {
@@ -4284,8 +4291,10 @@ static int wm8994_component_probe(struct snd_soc_component *component)
}
break;
case WM8958:
+ snd_soc_add_component_controls(component, wm8994_snd_controls,
+ ARRAY_SIZE(wm8994_snd_controls));
snd_soc_add_component_controls(component, wm8958_snd_controls,
- ARRAY_SIZE(wm8958_snd_controls));
+ ARRAY_SIZE(wm8958_snd_controls));
snd_soc_dapm_new_controls(dapm, wm8958_dapm_widgets,
ARRAY_SIZE(wm8958_dapm_widgets));
if (control->revision < 1) {
--
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 v2 02/10] ASoC: samsung: arndale: Add missing OF node dereferencing
From: Sylwester Nawrocki @ 2019-09-20 13:02 UTC (permalink / raw)
To: broonie, krzk
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, Sylwester Nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190920130218.32690-1-s.nawrocki@samsung.com>
Ensure there is no OF node references kept when the driver
is removed/unbound.
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes since v1:
- rebased to beginning of the series
---
sound/soc/samsung/arndale_rt5631.c | 34 ++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/sound/soc/samsung/arndale_rt5631.c b/sound/soc/samsung/arndale_rt5631.c
index c213913eb984..fd8c6642fb0d 100644
--- a/sound/soc/samsung/arndale_rt5631.c
+++ b/sound/soc/samsung/arndale_rt5631.c
@@ -5,6 +5,7 @@
// Author: Claude <claude@insginal.co.kr>
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
@@ -74,6 +75,17 @@ static struct snd_soc_card arndale_rt5631 = {
.num_links = ARRAY_SIZE(arndale_rt5631_dai),
};
+static void arndale_put_of_nodes(struct snd_soc_card *card)
+{
+ struct snd_soc_dai_link *dai_link;
+ int i;
+
+ for_each_card_prelinks(card, i, dai_link) {
+ of_node_put(dai_link->cpus->of_node);
+ of_node_put(dai_link->codecs->of_node);
+ }
+}
+
static int arndale_audio_probe(struct platform_device *pdev)
{
int n, ret;
@@ -103,18 +115,31 @@ static int arndale_audio_probe(struct platform_device *pdev)
if (!arndale_rt5631_dai[0].codecs->of_node) {
dev_err(&pdev->dev,
"Property 'samsung,audio-codec' missing or invalid\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_put_of_nodes;
}
}
ret = devm_snd_soc_register_card(card->dev, card);
+ if (ret) {
+ dev_err(&pdev->dev, "snd_soc_register_card() failed: %d\n", ret);
+ goto err_put_of_nodes;
+ }
+ return 0;
- if (ret)
- dev_err(&pdev->dev, "snd_soc_register_card() failed:%d\n", ret);
-
+err_put_of_nodes:
+ arndale_put_of_nodes(card);
return ret;
}
+static int arndale_audio_remove(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+ arndale_put_of_nodes(card);
+ return 0;
+}
+
static const struct of_device_id samsung_arndale_rt5631_of_match[] __maybe_unused = {
{ .compatible = "samsung,arndale-rt5631", },
{ .compatible = "samsung,arndale-alc5631", },
@@ -129,6 +154,7 @@ static struct platform_driver arndale_audio_driver = {
.of_match_table = of_match_ptr(samsung_arndale_rt5631_of_match),
},
.probe = arndale_audio_probe,
+ .remove = arndale_audio_remove,
};
module_platform_driver(arndale_audio_driver);
--
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 v2 03/10] ASoC: wm8994: Add support for setting MCLK clock rate
From: Sylwester Nawrocki @ 2019-09-20 13:02 UTC (permalink / raw)
To: broonie, krzk
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, Sylwester Nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190920130218.32690-1-s.nawrocki@samsung.com>
Extend the set_sysclk() handler so we also set frequency of the MCLK1,
MCLK2 clocks through clk API when those clocks are specified in DT.
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes since v1:
- getting of clocks moved from MFD to the CODEC's driver probe()
---
sound/soc/codecs/wm8994.c | 48 +++++++++++++++++++++++++++++++++++----
sound/soc/codecs/wm8994.h | 10 +++++++-
2 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index d5fb7f5dd551..f69545dced25 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -167,12 +167,12 @@ static int configure_aif_clock(struct snd_soc_component *component, int aif)
switch (wm8994->sysclk[aif]) {
case WM8994_SYSCLK_MCLK1:
- rate = wm8994->mclk[0];
+ rate = wm8994->mclk_rate[0];
break;
case WM8994_SYSCLK_MCLK2:
reg1 |= 0x8;
- rate = wm8994->mclk[1];
+ rate = wm8994->mclk_rate[1];
break;
case WM8994_SYSCLK_FLL1:
@@ -2372,12 +2372,29 @@ static int wm8994_set_fll(struct snd_soc_dai *dai, int id, int src,
return _wm8994_set_fll(dai->component, id, src, freq_in, freq_out);
}
+static int wm8994_set_mclk_rate(struct wm8994_priv *wm8994, unsigned int id,
+ unsigned int *freq)
+{
+ int ret;
+
+ if (!wm8994->mclk[id].clk || *freq == wm8994->mclk_rate[id])
+ return 0;
+
+ ret = clk_set_rate(wm8994->mclk[id].clk, *freq);
+ if (ret < 0)
+ return ret;
+
+ *freq = clk_get_rate(wm8994->mclk[id].clk);
+
+ return 0;
+}
+
static int wm8994_set_dai_sysclk(struct snd_soc_dai *dai,
int clk_id, unsigned int freq, int dir)
{
struct snd_soc_component *component = dai->component;
struct wm8994_priv *wm8994 = snd_soc_component_get_drvdata(component);
- int i;
+ int ret, i;
switch (dai->id) {
case 1:
@@ -2392,7 +2409,12 @@ static int wm8994_set_dai_sysclk(struct snd_soc_dai *dai,
switch (clk_id) {
case WM8994_SYSCLK_MCLK1:
wm8994->sysclk[dai->id - 1] = WM8994_SYSCLK_MCLK1;
- wm8994->mclk[0] = freq;
+
+ ret = wm8994_set_mclk_rate(wm8994, dai->id - 1, &freq);
+ if (ret < 0)
+ return ret;
+
+ wm8994->mclk_rate[0] = freq;
dev_dbg(dai->dev, "AIF%d using MCLK1 at %uHz\n",
dai->id, freq);
break;
@@ -2400,7 +2422,12 @@ static int wm8994_set_dai_sysclk(struct snd_soc_dai *dai,
case WM8994_SYSCLK_MCLK2:
/* TODO: Set GPIO AF */
wm8994->sysclk[dai->id - 1] = WM8994_SYSCLK_MCLK2;
- wm8994->mclk[1] = freq;
+
+ ret = wm8994_set_mclk_rate(wm8994, dai->id - 1, &freq);
+ if (ret < 0)
+ return ret;
+
+ wm8994->mclk_rate[1] = freq;
dev_dbg(dai->dev, "AIF%d using MCLK2 at %uHz\n",
dai->id, freq);
break;
@@ -4456,6 +4483,7 @@ static const struct snd_soc_component_driver soc_component_dev_wm8994 = {
static int wm8994_probe(struct platform_device *pdev)
{
struct wm8994_priv *wm8994;
+ int ret;
wm8994 = devm_kzalloc(&pdev->dev, sizeof(struct wm8994_priv),
GFP_KERNEL);
@@ -4467,6 +4495,16 @@ static int wm8994_probe(struct platform_device *pdev)
wm8994->wm8994 = dev_get_drvdata(pdev->dev.parent);
+ wm8994->mclk[WM8994_MCLK1].id = "MCLK1";
+ wm8994->mclk[WM8994_MCLK2].id = "MCLK2";
+
+ ret = devm_clk_bulk_get_optional(pdev->dev.parent, ARRAY_SIZE(wm8994->mclk),
+ wm8994->mclk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to get clocks: %d\n", ret);
+ return ret;
+ }
+
pm_runtime_enable(&pdev->dev);
pm_runtime_idle(&pdev->dev);
diff --git a/sound/soc/codecs/wm8994.h b/sound/soc/codecs/wm8994.h
index 1d6f2abe1c11..41c4b126114d 100644
--- a/sound/soc/codecs/wm8994.h
+++ b/sound/soc/codecs/wm8994.h
@@ -6,6 +6,7 @@
#ifndef _WM8994_H
#define _WM8994_H
+#include <linux/clk.h>
#include <sound/soc.h>
#include <linux/firmware.h>
#include <linux/completion.h>
@@ -14,6 +15,12 @@
#include "wm_hubs.h"
+enum {
+ WM8994_MCLK1,
+ WM8994_MCLK2,
+ WM8994_NUM_MCLK
+};
+
/* Sources for AIF1/2 SYSCLK - use with set_dai_sysclk() */
#define WM8994_SYSCLK_MCLK1 1
#define WM8994_SYSCLK_MCLK2 2
@@ -73,9 +80,10 @@ struct wm8994;
struct wm8994_priv {
struct wm_hubs_data hubs;
struct wm8994 *wm8994;
+ struct clk_bulk_data mclk[WM8994_NUM_MCLK];
int sysclk[2];
int sysclk_rate[2];
- int mclk[2];
+ int mclk_rate[2];
int aifclk[2];
int aifdiv[2];
int channels[2];
--
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 v2 04/10] ASoC: wm8994: Add support for MCLKn clock gating
From: Sylwester Nawrocki @ 2019-09-20 13:02 UTC (permalink / raw)
To: broonie, krzk
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, Sylwester Nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190920130218.32690-1-s.nawrocki@samsung.com>
As an intermediate step before covering the clocking subsystem
of the CODEC entirely by the clk API add handling of external CODEC's
master clocks in DAPM events when the AIFn clocks are sourced directly
from MCLKn; when FLLn are used we enable/disable respective MCLKn
before/after FLLn is enabled/disabled.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes since v1:
- addressed review comments from Charles
---
sound/soc/codecs/wm8994.c | 108 ++++++++++++++++++++++++++++++++++++--
1 file changed, 104 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index f69545dced25..15ce64a48a87 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -1038,6 +1038,45 @@ static bool wm8994_check_class_w_digital(struct snd_soc_component *component)
return true;
}
+static int aif_mclk_set(struct snd_soc_component *component, int aif, bool enable)
+{
+ struct wm8994_priv *wm8994 = snd_soc_component_get_drvdata(component);
+ unsigned int offset, val, clk_idx;
+ int ret;
+
+ if (aif)
+ offset = 4;
+ else
+ offset = 0;
+
+ val = snd_soc_component_read32(component, WM8994_AIF1_CLOCKING_1 + offset);
+ val &= WM8994_AIF1CLK_SRC_MASK;
+
+ switch (val) {
+ case 0:
+ clk_idx = WM8994_MCLK1;
+ break;
+ case 1:
+ clk_idx = WM8994_MCLK2;
+ break;
+ default:
+ return 0;
+ }
+
+ if (enable) {
+ ret = clk_prepare_enable(wm8994->mclk[clk_idx].clk);
+ if (ret < 0) {
+ dev_err(component->dev, "Failed to enable MCLK%d\n",
+ clk_idx);
+ return ret;
+ }
+ } else {
+ clk_disable_unprepare(wm8994->mclk[clk_idx].clk);
+ }
+
+ return 0;
+}
+
static int aif1clk_ev(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
{
@@ -1045,7 +1084,7 @@ static int aif1clk_ev(struct snd_soc_dapm_widget *w,
struct wm8994_priv *wm8994 = snd_soc_component_get_drvdata(component);
struct wm8994 *control = wm8994->wm8994;
int mask = WM8994_AIF1DAC1L_ENA | WM8994_AIF1DAC1R_ENA;
- int i;
+ int ret, i;
int dac;
int adc;
int val;
@@ -1061,6 +1100,10 @@ static int aif1clk_ev(struct snd_soc_dapm_widget *w,
switch (event) {
case SND_SOC_DAPM_PRE_PMU:
+ ret = aif_mclk_set(component, 0, true);
+ if (ret < 0)
+ return ret;
+
/* Don't enable timeslot 2 if not in use */
if (wm8994->channels[0] <= 2)
mask &= ~(WM8994_AIF1DAC2L_ENA | WM8994_AIF1DAC2R_ENA);
@@ -1133,6 +1176,12 @@ static int aif1clk_ev(struct snd_soc_dapm_widget *w,
break;
}
+ switch (event) {
+ case SND_SOC_DAPM_POST_PMD:
+ aif_mclk_set(component, 0, false);
+ break;
+ }
+
return 0;
}
@@ -1140,13 +1189,17 @@ static int aif2clk_ev(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
{
struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm);
- int i;
+ int ret, i;
int dac;
int adc;
int val;
switch (event) {
case SND_SOC_DAPM_PRE_PMU:
+ ret = aif_mclk_set(component, 1, true);
+ if (ret < 0)
+ return ret;
+
val = snd_soc_component_read32(component, WM8994_AIF2_CONTROL_1);
if ((val & WM8994_AIF2ADCL_SRC) &&
(val & WM8994_AIF2ADCR_SRC))
@@ -1218,6 +1271,12 @@ static int aif2clk_ev(struct snd_soc_dapm_widget *w,
break;
}
+ switch (event) {
+ case SND_SOC_DAPM_POST_PMD:
+ aif_mclk_set(component, 1, false);
+ break;
+ }
+
return 0;
}
@@ -1623,10 +1682,10 @@ SND_SOC_DAPM_POST("Late Disable PGA", late_disable_ev)
static const struct snd_soc_dapm_widget wm8994_lateclk_widgets[] = {
SND_SOC_DAPM_SUPPLY("AIF1CLK", WM8994_AIF1_CLOCKING_1, 0, 0, aif1clk_ev,
SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU |
- SND_SOC_DAPM_PRE_PMD),
+ SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMD),
SND_SOC_DAPM_SUPPLY("AIF2CLK", WM8994_AIF2_CLOCKING_1, 0, 0, aif2clk_ev,
SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU |
- SND_SOC_DAPM_PRE_PMD),
+ SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMD),
SND_SOC_DAPM_PGA("Direct Voice", SND_SOC_NOPM, 0, 0, NULL, 0),
SND_SOC_DAPM_MIXER("SPKL", WM8994_POWER_MANAGEMENT_3, 8, 0,
left_speaker_mixer, ARRAY_SIZE(left_speaker_mixer)),
@@ -2141,6 +2200,7 @@ static int _wm8994_set_fll(struct snd_soc_component *component, int id, int src,
u16 reg, clk1, aif_reg, aif_src;
unsigned long timeout;
bool was_enabled;
+ struct clk *mclk;
switch (id) {
case WM8994_FLL1:
@@ -2216,6 +2276,27 @@ static int _wm8994_set_fll(struct snd_soc_component *component, int id, int src,
snd_soc_component_update_bits(component, WM8994_FLL1_CONTROL_1 + reg_offset,
WM8994_FLL1_ENA, 0);
+ /* Disable MCLK if needed before we possibly change to new clock parent */
+ if (was_enabled) {
+ reg = snd_soc_component_read32(component, WM8994_FLL1_CONTROL_5
+ + reg_offset);
+ reg = ((reg & WM8994_FLL1_REFCLK_SRC_MASK)
+ >> WM8994_FLL1_REFCLK_SRC_SHIFT) + 1;
+
+ switch (reg) {
+ case WM8994_FLL_SRC_MCLK1:
+ mclk = wm8994->mclk[WM8994_MCLK1].clk;
+ break;
+ case WM8994_FLL_SRC_MCLK2:
+ mclk = wm8994->mclk[WM8994_MCLK2].clk;
+ break;
+ default:
+ mclk = NULL;
+ }
+
+ clk_disable_unprepare(mclk);
+ }
+
if (wm8994->fll_byp && src == WM8994_FLL_SRC_BCLK &&
freq_in == freq_out && freq_out) {
dev_dbg(component->dev, "Bypassing FLL%d\n", id + 1);
@@ -2260,10 +2341,29 @@ static int _wm8994_set_fll(struct snd_soc_component *component, int id, int src,
/* Clear any pending completion from a previous failure */
try_wait_for_completion(&wm8994->fll_locked[id]);
+ switch (src) {
+ case WM8994_FLL_SRC_MCLK1:
+ mclk = wm8994->mclk[WM8994_MCLK1].clk;
+ break;
+ case WM8994_FLL_SRC_MCLK2:
+ mclk = wm8994->mclk[WM8994_MCLK2].clk;
+ break;
+ default:
+ mclk = NULL;
+ }
+
/* Enable (with fractional mode if required) */
if (freq_out) {
+ ret = clk_prepare_enable(mclk);
+ if (ret < 0) {
+ dev_err(component->dev, "Failed to enable MCLK for FLL%d\n",
+ id + 1);
+ return ret;
+ }
+
/* Enable VMID if we need it */
if (!was_enabled) {
+
active_reference(component);
switch (control->type) {
--
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 v2 05/10] ASoC: samsung: arndale: Simplify DAI link initialization
From: Sylwester Nawrocki @ 2019-09-20 13:02 UTC (permalink / raw)
To: broonie, krzk
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, Sylwester Nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190920130218.32690-1-s.nawrocki@samsung.com>
There is only one DAI link so we can drop an unnecessary loop statement.
Use card->dai_link in place of direct static arndale_rt5631_dai[] array
dereference as a prerequisite for adding support for other CODECs.
Unnecessary assignment of dai_link->codecs->name to NULL is removed.
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes since v1:
- rebased due to reordering patches in the series
---
sound/soc/samsung/arndale_rt5631.c | 42 +++++++++++++-----------------
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/sound/soc/samsung/arndale_rt5631.c b/sound/soc/samsung/arndale_rt5631.c
index fd8c6642fb0d..004c84fafad9 100644
--- a/sound/soc/samsung/arndale_rt5631.c
+++ b/sound/soc/samsung/arndale_rt5631.c
@@ -88,36 +88,30 @@ static void arndale_put_of_nodes(struct snd_soc_card *card)
static int arndale_audio_probe(struct platform_device *pdev)
{
- int n, ret;
struct device_node *np = pdev->dev.of_node;
struct snd_soc_card *card = &arndale_rt5631;
+ struct snd_soc_dai_link *dai_link;
+ int ret;
card->dev = &pdev->dev;
+ dai_link = card->dai_link;
+
+ dai_link->cpus->of_node = of_parse_phandle(np, "samsung,audio-cpu", 0);
+ if (!dai_link->cpus->of_node) {
+ dev_err(&pdev->dev,
+ "Property 'samsung,audio-cpu' missing or invalid\n");
+ return -EINVAL;
+ }
- for (n = 0; np && n < ARRAY_SIZE(arndale_rt5631_dai); n++) {
- if (!arndale_rt5631_dai[n].cpus->dai_name) {
- arndale_rt5631_dai[n].cpus->of_node = of_parse_phandle(np,
- "samsung,audio-cpu", n);
-
- if (!arndale_rt5631_dai[n].cpus->of_node) {
- dev_err(&pdev->dev,
- "Property 'samsung,audio-cpu' missing or invalid\n");
- return -EINVAL;
- }
- }
- if (!arndale_rt5631_dai[n].platforms->name)
- arndale_rt5631_dai[n].platforms->of_node =
- arndale_rt5631_dai[n].cpus->of_node;
-
- arndale_rt5631_dai[n].codecs->name = NULL;
- arndale_rt5631_dai[n].codecs->of_node = of_parse_phandle(np,
- "samsung,audio-codec", n);
- if (!arndale_rt5631_dai[0].codecs->of_node) {
- dev_err(&pdev->dev,
+ if (!dai_link->platforms->name)
+ dai_link->platforms->of_node = dai_link->cpus->of_node;
+
+ dai_link->codecs->of_node = of_parse_phandle(np, "samsung,audio-codec", 0);
+ if (!dai_link->codecs->of_node) {
+ dev_err(&pdev->dev,
"Property 'samsung,audio-codec' missing or invalid\n");
- ret = -EINVAL;
- goto err_put_of_nodes;
- }
+ ret = -EINVAL;
+ goto err_put_of_nodes;
}
ret = devm_snd_soc_register_card(card->dev, card);
--
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 v2 06/10] ASoC: dt-bindings: Document "samsung,arndale-wm1811" compatible
From: Sylwester Nawrocki @ 2019-09-20 13:02 UTC (permalink / raw)
To: broonie, krzk
Cc: devicetree, alsa-devel, linux-samsung-soc, ckeepax, b.zolnierkie,
sbkim73, patches, lgirdwood, robh+dt, Sylwester Nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20190920130218.32690-1-s.nawrocki@samsung.com>
Add compatible string for boards with WM1811 CODEC to the list.
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes since v1:
- none
---
Documentation/devicetree/bindings/sound/arndale.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/arndale.txt b/Documentation/devicetree/bindings/sound/arndale.txt
index 0e76946385ae..17530120ccfc 100644
--- a/Documentation/devicetree/bindings/sound/arndale.txt
+++ b/Documentation/devicetree/bindings/sound/arndale.txt
@@ -1,8 +1,9 @@
Audio Binding for Arndale boards
Required properties:
-- compatible : Can be the following,
- "samsung,arndale-rt5631"
+- compatible : Can be one of the following:
+ "samsung,arndale-rt5631",
+ "samsung,arndale-wm1811"
- samsung,audio-cpu: The phandle of the Samsung I2S controller
- samsung,audio-codec: The phandle of the audio codec
--
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
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