* [PATCH v2 01/30] pinctrl: mediatek: Add missing pinctrl bindings for mt7623
From: sean.wang @ 2017-04-26 9:25 UTC (permalink / raw)
To: robh+dt, matthias.bgg, john, mark.rutland, linux, linus.walleij,
devicetree, linux-mediatek
Cc: linux-gpio, Sean Wang, linux-kernel, linux-arm-kernel
In-Reply-To: <1493198774-4478-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Add missing pinctrl binding these which would be used in
devicetree related files.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
include/dt-bindings/pinctrl/mt7623-pinfunc.h | 30 ++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/include/dt-bindings/pinctrl/mt7623-pinfunc.h b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
index 2f00bdc..436a87b 100644
--- a/include/dt-bindings/pinctrl/mt7623-pinfunc.h
+++ b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
@@ -185,6 +185,12 @@
#define MT7623_PIN_56_SPI0_MO_FUNC_SPI0_MO (MTK_PIN_NO(56) | 1)
#define MT7623_PIN_56_SPI0_MO_FUNC_SPI0_MI (MTK_PIN_NO(56) | 2)
+#define MT7623_PIN_57_SDA1_FUNC_GPIO57 (MTK_PIN_NO(57) | 0)
+#define MT7623_PIN_57_SDA1_FUNC_SDA1 (MTK_PIN_NO(57) | 1)
+
+#define MT7623_PIN_58_SCL1_FUNC_GPIO58 (MTK_PIN_NO(58) | 0)
+#define MT7623_PIN_58_SCL1_FUNC_SCL1 (MTK_PIN_NO(58) | 1)
+
#define MT7623_PIN_60_WB_RSTB_FUNC_GPIO60 (MTK_PIN_NO(60) | 0)
#define MT7623_PIN_60_WB_RSTB_FUNC_WB_RSTB (MTK_PIN_NO(60) | 1)
@@ -244,6 +250,22 @@
#define MT7623_PIN_76_SCL0_FUNC_GPIO76 (MTK_PIN_NO(76) | 0)
#define MT7623_PIN_76_SCL0_FUNC_SCL0 (MTK_PIN_NO(76) | 1)
+#define MT7623_PIN_79_URXD0_FUNC_GPIO79 (MTK_PIN_NO(79) | 0)
+#define MT7623_PIN_79_URXD0_FUNC_URXD0 (MTK_PIN_NO(79) | 1)
+#define MT7623_PIN_79_URXD0_FUNC_UTXD0 (MTK_PIN_NO(79) | 2)
+
+#define MT7623_PIN_80_UTXD0_FUNC_GPIO80 (MTK_PIN_NO(80) | 0)
+#define MT7623_PIN_80_UTXD0_FUNC_UTXD0 (MTK_PIN_NO(80) | 1)
+#define MT7623_PIN_80_UTXD0_FUNC_URXD0 (MTK_PIN_NO(80) | 2)
+
+#define MT7623_PIN_81_URXD1_FUNC_GPIO81 (MTK_PIN_NO(81) | 0)
+#define MT7623_PIN_81_URXD1_FUNC_URXD1 (MTK_PIN_NO(81) | 1)
+#define MT7623_PIN_81_URXD1_FUNC_UTXD1 (MTK_PIN_NO(81) | 2)
+
+#define MT7623_PIN_82_UTXD1_FUNC_GPIO82 (MTK_PIN_NO(82) | 0)
+#define MT7623_PIN_82_UTXD1_FUNC_UTXD1 (MTK_PIN_NO(82) | 1)
+#define MT7623_PIN_82_UTXD1_FUNC_URXD1 (MTK_PIN_NO(82) | 2)
+
#define MT7623_PIN_83_LCM_RST_FUNC_GPIO83 (MTK_PIN_NO(83) | 0)
#define MT7623_PIN_83_LCM_RST_FUNC_LCM_RST (MTK_PIN_NO(83) | 1)
@@ -351,10 +373,10 @@
#define MT7623_PIN_122_GPIO122_FUNC_SDA2 (MTK_PIN_NO(122) | 4)
#define MT7623_PIN_122_GPIO122_FUNC_URXD0 (MTK_PIN_NO(122) | 5)
-#define MT7623_PIN_123_GPIO123_FUNC_GPIO123 (MTK_PIN_NO(123) | 0)
-#define MT7623_PIN_123_GPIO123_FUNC_TEST (MTK_PIN_NO(123) | 1)
-#define MT7623_PIN_123_GPIO123_FUNC_SCL2 (MTK_PIN_NO(123) | 4)
-#define MT7623_PIN_123_GPIO123_FUNC_UTXD0 (MTK_PIN_NO(123) | 5)
+#define MT7623_PIN_123_HTPLG_FUNC_GPIO123 (MTK_PIN_NO(123) | 0)
+#define MT7623_PIN_123_HTPLG_FUNC_HTPLG (MTK_PIN_NO(123) | 1)
+#define MT7623_PIN_123_HTPLG_FUNC_SCL2 (MTK_PIN_NO(123) | 4)
+#define MT7623_PIN_123_HTPLG_FUNC_UTXD0 (MTK_PIN_NO(123) | 5)
#define MT7623_PIN_124_GPIO124_FUNC_GPIO124 (MTK_PIN_NO(124) | 0)
#define MT7623_PIN_124_GPIO124_FUNC_TEST (MTK_PIN_NO(124) | 1)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 00/30] arm: dts: extend mt7623 support
From: sean.wang @ 2017-04-26 9:25 UTC (permalink / raw)
To: robh+dt, matthias.bgg, john, mark.rutland, linux, linus.walleij,
devicetree, linux-mediatek
Cc: linux-gpio, Sean Wang, linux-kernel, linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
Changes since v1:
Continue the upstream journey based on the previous John Crispin's good work.
- add fixes for the v1 suggestion
- fix typo in the commit log
- add missing pinctrl bindings for mt7623
- reuse pinctrl driver for mt7623
- enhance existing nodes since the way for binding is changed e.g USB
- add more nodes which already gets support from the latest tree e.g MT7530 DSA
- add the dts file for Bananapi R2 (BPI-R2) board
This series extends the dts files used for booting mt7623 base boards.
Since support for mt7623 was added around v4.6, many new drivers have
been accepted upstream. The contained patches add several of these to
the devicetree.
Additionally the series does a bit of refactoring. Mediatek pointed out
that the evaluation board is infact a reference design and asked the the
evb files be renamed to rfb.
As with all of the current ARM bases MTK silicon, these boards also have
a PMIC. Instead of adding the nodes to all of the dts files, we add an
intermediate dtsi file that contains the required nodes. This allows us
to reduce the size of the top most dts files.
The RFB comes in various versions and asiarf has even done a crowdfunder
to sell them. We should try to reduce the duplication. This series adds
a common dtsi file for these boards. This results in the topmost dts files
only needing to specify the compatible string, MTD nodes and ethernet setup.
John Crispin (14):
arm: dts: mt7623: add clock controller device nodes
arm: dts: mt7623: add subsystem clock controller device nodes
arm: dts: mt7623: add power domain controller device node
arm: dts: mt7623: add clock-frequency to the a7 timer node to
mt7623.dtsi
arm: dts: mt7623: add pinctrl nodes to the mt7623 dtsi file
arm: dts: mt7623: add pmic wrapper nodes to the mt7623 dtsi file
arm: dts: mt7623: add i2c nodes to the mt7623.dtsi file
arm: dts: mt7623: add nand nodes to the mt7623.dtsi file
arm: dts: mt7623: add mmc nodes to the mt7623.dtsi file
arm: dts: mt7623: add usb nodes to the mt7623.dtsi file
arm: dts: mt7623: add mt7623-mt6323.dtsi file
arm: dts: mt7623: cleanup the mt7623n rfb uart nodes
arm: dts: mt7623: enable the usb device on the mt7623n rfb
arm: dts: mt7623: enable the nand device on the mt7623n nand rfb
Sean Wang (16):
pinctrl: mediatek: Add missing pinctrl bindings for mt7623
pinctrl: mediatek: reuse pinctrl driver for mt7623
arm: dts: mt7623: add spi nodes to the mt7623.dtsi file
arm: dts: mt7623: add pwm nodes to the mt7623.dtsi file
arm: dts: mt7623: add ethernet nodes to the mt7623.dtsi file
arm: dts: mt7623: add crypto engine nodes to the mt7623.dtsi file
arm: dts: mt7623: add ir nodes to the mt7623.dtsi file
arm: dts: mt7623: add afe nodes to the mt7623.dtsi file
arm: dts: mt7623: add rng nodes to the mt7623.dtsi file
arm: dts: mt7623: add auxadc nodes to the mt7623.dtsi file
arm: dts: mt7623: add efuse nodes to the mt7623.dtsi file
arm: dts: mt7623: add thermal nodes to the mt7623.dtsi file
arm: dts: mt7623: add Sean as one of authors for mt7623.dtsi files
arm: dts: mt7623: rename mt7623-evb.dts to
arch/arm/boot/dts/mt7623n-rfb.dtsi
dt-bindings: add vendor prefix for bananapi
arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board
Documentation/devicetree/bindings/arm/mediatek.txt | 8 +-
.../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt | 1 -
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/mt7623-evb.dts | 33 -
arch/arm/boot/dts/mt7623-mt6323.dtsi | 269 +++
arch/arm/boot/dts/mt7623.dtsi | 556 +++++-
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 478 +++++
arch/arm/boot/dts/mt7623n-rfb-nand.dts | 109 ++
arch/arm/boot/dts/mt7623n-rfb.dtsi | 61 +
arch/arm/mach-mediatek/mediatek.c | 4 +-
arch/arm/mach-mediatek/platsmp.c | 2 +-
drivers/pinctrl/mediatek/Kconfig | 9 +-
drivers/pinctrl/mediatek/Makefile | 1 -
drivers/pinctrl/mediatek/pinctrl-mt7623.c | 379 ----
drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h | 1936 --------------------
include/dt-bindings/pinctrl/mt7623-pinfunc.h | 30 +-
17 files changed, 1497 insertions(+), 2383 deletions(-)
delete mode 100644 arch/arm/boot/dts/mt7623-evb.dts
create mode 100644 arch/arm/boot/dts/mt7623-mt6323.dtsi
create mode 100644 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
create mode 100644 arch/arm/boot/dts/mt7623n-rfb-nand.dts
create mode 100644 arch/arm/boot/dts/mt7623n-rfb.dtsi
delete mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7623.c
delete mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h
--
1.9.1
^ permalink raw reply
* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Gregory CLEMENT @ 2017-04-26 9:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, linux-gpio@vger.kernel.org, Rob Herring,
Neta Zur Hershkovits, Victor Gu, Hua Jing, Marcin Wojtas,
Wilson Ding, linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth
In-Reply-To: <CACRpkdZ=mVXBbVf1iHg8nQ6pYUkvpB+egH+stoMrkD8V_vaYpg@mail.gmail.com>
Hi Linus,
On lun., avril 24 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
>> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
>> only manage the edge ones.
>>
>> The way the interrupt are managed are classical so we can use the generic
>> interrupt chip model.
>>
>> The only unusual "feature" is that many interrupts are connected to the
>> parent interrupt controller. But we do not take advantage of this and use
>> the chained irq with all of them.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> There are some issues with this patch.
>
> First:
> You need to add
> select GPIOLIB_IRQCHIP
> to the Kconfig entry. It's only working in your setup
> because something else is selecting this for you, probably.
It is done in patch 2 "arm64: marvell: enable the Armada 37xx pinctrl
driver".
>
> At all places like this:
>
>> + u32 mask = d->mask;
> (...)
>> + if (on)
>> + val |= mask;
>> + else
>> + val &= ~mask;
>
> Isn't it simpler to just use d->mask directly in the code and skip the local
> variable?
>
> if (on)
> val |= d->mask;
> (...)
Yes sure I cand do it.
>
>> +static void armada_37xx_irq_handler(struct irq_desc *desc)
>> +{
>> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>> + struct armada_37xx_pinctrl *info = gpiochip_get_data(gc);
>> + struct irq_domain *d = gc->irqdomain;
>> + int i;
>> +
>> + chained_irq_enter(chip, desc);
>> + for (i = 0; i <= d->revmap_size / GPIO_PER_REG; i++) {
>> + u32 status;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&info->irq_lock, flags);
>> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
>> + /* Manage only the interrupt that was enabled */
>> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
>> + spin_unlock_irqrestore(&info->irq_lock, flags);
>> + while (status) {
>> + u32 hwirq = ffs(status) - 1;
>> + u32 virq = irq_find_mapping(d, hwirq +
>> + i * GPIO_PER_REG);
>> +
>> + generic_handle_irq(virq);
>> + status &= ~BIT(hwirq);
>> + }
>
> You hae a problem here is a new IRQ appears while you are inside
> of this loop. You need to re-read the status register for each iteration
> (and &= with the IRQ_EN I guess).
If a new IRQ appears during the loop, then the irq handler will be
called again because the cause of this new IRQ won't have been acked
yet. So I think we're fine here.
>
>> +static int armada_37xx_irqchip_register(struct platform_device *pdev,
>> + struct armada_37xx_pinctrl *info)
>> +{
>> + struct device_node *np = info->dev->of_node;
>> + int nrirqs = info->data->nr_pins;
>> + struct gpio_chip *gc = &info->gpio_chip;
>> + struct irq_chip *irqchip = &info->irq_chip;
>> + struct resource res;
>> + int ret = -ENODEV, i, nr_irq_parent;
>> +
>
> This warrants a comment:
> /* Check if we have at least one gpio-controller child node */
>
OK
>> + for_each_child_of_node(info->dev->of_node, np) {
>> + if (of_find_property(np, "gpio-controller", NULL)) {
>> + ret = 0;
>> + break;
>> + }
>
> Rewrite:
>
> if (of_property_read_bool(np, "gpio-controller"))
>
OK
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX
From: Pierre Yves MORDRET @ 2017-04-26 9:23 UTC (permalink / raw)
To: Rob Herring, M'boumba Cedric Madianga
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, Pierre Yves MORDRET,
mcoquelin.stm32@gmail.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170320213722.oj3ipmslbw2mp27d@rob-hp-laptop>
On 03/20/2017 10:37 PM, Rob Herring wrote:
> On Mon, Mar 13, 2017 at 03:15:59PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds an optional property needed for STM32 DMA controller
>> addressed via STM32 DMAMUX.
>>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>> ---
>> Documentation/devicetree/bindings/dma/stm32-dma.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt b/Documentation/devicetree/bindings/dma/stm32-dma.txt
>> index 4408af6..7b5e91a 100644
>> --- a/Documentation/devicetree/bindings/dma/stm32-dma.txt
>> +++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt
>> @@ -16,6 +16,9 @@ Optional properties:
>> - resets: Reference to a reset controller asserting the DMA controller
>> - st,mem2mem: boolean; if defined, it indicates that the controller supports
>> memory-to-memory transfer
>> +- st,dmamux: boolean; if defined, it indicates that the controller is behind a
>> + DMA multiplexer. In that case, using dma instances doesn't work for DMA
>> + clients. They have to use dma-router instances.
>
> This should not be needed for the same reason we don't need anything
> like this for chained interrupt controllers.
>
> Also, the compatible string should be specific enough to provide this
> information.
>
> Rob
I don't understand what you're meant here. Our DMAs can work with or
without DMAMUX driver. Driver uses this binding to use it or not.
Py
>
> _______________________________________________
> 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 2/5] dmaengine: Add STM32 DMAMUX driver
From: Pierre Yves MORDRET @ 2017-04-26 9:17 UTC (permalink / raw)
To: Vinod Koul, M'boumba Cedric Madianga
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, linux-kernel@vger.kernel.org,
Pierre Yves MORDRET, robh+dt@kernel.org,
mcoquelin.stm32@gmail.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170406064046.GF4094@localhost>
On 04/06/2017 08:40 AM, Vinod Koul wrote:
> On Mon, Mar 13, 2017 at 03:15:58PM +0100, M'boumba Cedric Madianga wrote:
>> This patch implements the STM32 DMAMUX driver
>
> Can you describe the controller here pls
OK. Will be done in V2
>
>>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>> ---
>> drivers/dma/Kconfig | 9 ++
>> drivers/dma/Makefile | 1 +
>> drivers/dma/stm32-dmamux.c | 231 +++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 241 insertions(+)
>> create mode 100644 drivers/dma/stm32-dmamux.c
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index fc3435c..6ab80c9 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -461,6 +461,15 @@ config STM32_DMA
>> If you have a board based on such a MCU and wish to use DMA say Y
>> here.
>>
>> +config STM32_DMAMUX
>> + bool "STMicroelectronics STM32 dma multiplexer support"
>> + depends on STM32_DMA
>
> can you add compile test here so that we can get better compile coverage
OK. Will be done in V2
>
>> + help
>> + Enable support for the on-chip DMA multiplexer on STMicroelectronics
>> + STM32 MCUs.
>> + If you have a board based on such a MCU and wish to use DMAMUX say Y
>> + here.
>> +
>> config S3C24XX_DMAC
>> bool "Samsung S3C24XX DMA support"
>> depends on ARCH_S3C24XX || COMPILE_TEST
>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>> index 0b723e9..449c7a3 100644
>> --- a/drivers/dma/Makefile
>> +++ b/drivers/dma/Makefile
>> @@ -57,6 +57,7 @@ obj-$(CONFIG_RENESAS_DMA) += sh/
>> obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
>> obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
>> obj-$(CONFIG_STM32_DMA) += stm32-dma.o
>> +obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
>> obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
>> obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
>> obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
>> diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c
>> new file mode 100644
>> index 0000000..3003546
>> --- /dev/null
>> +++ b/drivers/dma/stm32-dmamux.c
>> @@ -0,0 +1,231 @@
>> +/*
>> + * DMA Router driver for STM32 DMA MUX
>> + *
>> + * Copyright (C) 2015 M'Boumba Cedric Madianga <cedric.madianga@gmail.com>
>
> we are in '17 now :)
OK. Will be done in V2
>
>> + *
>> + * Based on LPC18xx/43xx DMA MUX and TI DMA XBAR
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/init.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_dma.h>
>> +#include <linux/reset.h>
>> +#include <linux/slab.h>
>> +
>> +#define STM32_DMAMUX_CCR(x) (0x4 * (x))
>> +#define STM32_DMAMUX_MAX_CHANNELS 32
>> +#define STM32_DMAMUX_MAX_REQUESTS 255
>> +
>> +struct stm32_dmamux {
>> + u32 chan_id;
>> + u32 request;
>> + bool busy;
>> +};
>> +
>> +struct stm32_dmamux_data {
>> + struct dma_router dmarouter;
>> + struct stm32_dmamux *muxes;
>> + struct clk *clk;
>> + void __iomem *iomem;
>> + u32 dmamux_requests; /* number of DMA requests connected to DMAMUX */
>> + u32 dmamux_channels; /* Number of DMA channels supported */
>> +};
>> +
>> +static inline u32 stm32_dmamux_read(void __iomem *iomem, u32 reg)
>> +{
>> + return readl_relaxed(iomem + reg);
>> +}
>> +
>> +static inline void stm32_dmamux_write(void __iomem *iomem, u32 reg, u32 val)
>> +{
>> + writel_relaxed(val, iomem + reg);
>> +}
>> +
>> +static void stm32_dmamux_free(struct device *dev, void *route_data)
>> +{
>> + struct stm32_dmamux_data *dmamux = dev_get_drvdata(dev);
>> + struct stm32_dmamux *mux = route_data;
>> +
>> + /* Clear dma request for the right channel */
>> + stm32_dmamux_write(dmamux->iomem, STM32_DMAMUX_CCR(mux->chan_id), 0);
>> + clk_disable(dmamux->clk);
>> + mux->busy = false;
>> +
>> + dev_dbg(dev, "Unmapping dma-router%dchan%d (was routed to request%d)\n",
>> + dev->id, mux->chan_id, mux->request);
>> +}
>> +
>> +static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec,
>> + struct of_dma *ofdma)
>> +{
>> + struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
>> + struct stm32_dmamux_data *dmamux = platform_get_drvdata(pdev);
>> + struct stm32_dmamux *mux;
>> + u32 chan_id;
>> + int ret;
>> +
>> + if (dma_spec->args_count != 4) {
>> + dev_err(&pdev->dev, "invalid number of dma mux args\n");
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + if (dma_spec->args[0] >= dmamux->dmamux_channels) {
>> + dev_err(&pdev->dev, "invalid channel id: %d\n",
>> + dma_spec->args[0]);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + if (dma_spec->args[1] > dmamux->dmamux_requests) {
>> + dev_err(&pdev->dev, "invalid mux request number: %d\n",
>> + dma_spec->args[1]);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + /* The of_node_put() will be done in of_dma_router_xlate function */
>> + dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
>> + if (!dma_spec->np) {
>> + dev_err(&pdev->dev, "can't get dma master\n");
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + chan_id = dma_spec->args[0];
>> + mux = &dmamux->muxes[chan_id];
>> + mux->chan_id = chan_id;
>> + mux->request = dma_spec->args[1];
>> +
>> + if (mux->busy) {
>> + dev_err(&pdev->dev, "dma channel %d busy with request %d\n",
>> + chan_id, mux->request);
>> + return ERR_PTR(-EBUSY);
>> + }
>> +
>> + ret = clk_enable(dmamux->clk);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "clk_enable failed: %d\n", ret);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + stm32_dmamux_write(dmamux->iomem, STM32_DMAMUX_CCR(mux->chan_id),
>> + mux->request);
>> + mux->busy = true;
>> +
>> + dev_dbg(&pdev->dev, "Mapping dma-router%dchan%d to request%d\n",
>> + pdev->dev.id, mux->chan_id, mux->request);
>> +
>> + return mux;
>> +}
>> +
>> +static int stm32_dmamux_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *dma_node, *node = pdev->dev.of_node;
>> + struct stm32_dmamux_data *dmamux;
>> + struct reset_control *rst;
>> + struct resource *res;
>> + int ret;
>> +
>> + if (!node)
>> + return -ENODEV;
>> +
>> + dmamux = devm_kzalloc(&pdev->dev, sizeof(struct stm32_dmamux_data),
>> + GFP_KERNEL);
>> + if (!dmamux)
>> + return -ENOMEM;
>> +
>> + dma_node = of_parse_phandle(node, "dma-masters", 0);
>> + if (!dma_node) {
>> + dev_err(&pdev->dev, "Can't get DMA master node\n");
>> + return -ENODEV;
>> + }
>> + of_node_put(dma_node);
>> +
>> + ret = of_property_read_u32(node, "dma-channels",
>> + &dmamux->dmamux_channels);
>
> can we have property_xxx calls alone, that way driver is not strictly
> dependent on of
Can you please explain what you are asking for ? Not sure to understand
correctly.
>
>> + if (ret)
>> + dmamux->dmamux_channels = STM32_DMAMUX_MAX_CHANNELS;
>> +
>> + ret = of_property_read_u32(node, "dma-requests",
>> + &dmamux->dmamux_requests);
>> + if (ret)
>> + dmamux->dmamux_requests = STM32_DMAMUX_MAX_REQUESTS;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return -ENODEV;
>> +
>> + dmamux->iomem = devm_ioremap_resource(&pdev->dev, res);
>> + if (!dmamux->iomem)
>> + return -ENOMEM;
>> +
>> + dmamux->clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(dmamux->clk)) {
>> + dev_err(&pdev->dev, "Missing controller clock\n");
>> + return PTR_ERR(dmamux->clk);
>> + }
>> + ret = clk_prepare(dmamux->clk);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "clk_prep failed: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + dmamux->muxes = devm_kcalloc(&pdev->dev, dmamux->dmamux_channels,
>> + sizeof(struct stm32_dmamux),
>> + GFP_KERNEL);
>> + if (!dmamux->muxes)
>> + return -ENOMEM;
>> +
>> + rst = devm_reset_control_get(&pdev->dev, NULL);
>> + if (!IS_ERR(rst)) {
>> + ret = clk_enable(dmamux->clk);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "clk_enable failed: %d\n", ret);
>> + return ret;
>> + }
>> + reset_control_assert(rst);
>> + udelay(2);
>> + reset_control_deassert(rst);
>> + clk_disable(dmamux->clk);
>> + }
>> +
>> + dmamux->dmarouter.dev = &pdev->dev;
>> + dmamux->dmarouter.route_free = stm32_dmamux_free;
>> + platform_set_drvdata(pdev, dmamux);
>> +
>> + ret = of_dma_router_register(node, stm32_dmamux_route_allocate,
>> + &dmamux->dmarouter);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev,
>> + "STM32 DMAMUX DMA OF registration failed %d\n", ret);
>> + return ret;
>> + }
>> +
>> + dev_info(&pdev->dev, "STM32 DMAMUX driver registered\n");
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id stm32_dmamux_match[] = {
>> + { .compatible = "st,stm32-dmamux" },
>> + {},
>> +};
>> +
>> +static struct platform_driver stm32_dmamux_driver = {
>> + .probe = stm32_dmamux_probe,
>> + .driver = {
>> + .name = "stm32-dmamux",
>> + .of_match_table = stm32_dmamux_match,
>> + },
>> +};
>> +
>> +static int __init stm32_dmamux_init(void)
>> +{
>> + return platform_driver_register(&stm32_dmamux_driver);
>> +}
>> +arch_initcall(stm32_dmamux_init);
>
> why not module init, wouldnt defer probe solve the dependencies
>
The reason behind many devices (device_initcall level) rely on DMAs. If
init is deferred DMAMUX driver will be probed twice if dependents rely
on it. This sounds not a good call. This explains arch_initcall level.
^ permalink raw reply
* Re: [PATCH v4 3/9] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: Geert Uytterhoeven @ 2017-04-26 9:02 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Linus Walleij, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491401247-7030-4-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Hi Jacopo,
On Wed, Apr 5, 2017 at 4:07 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
GPIO
> controller.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Thank you for the extensive documentation, incl. good examples!
> ---
> .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 218 +++++++++++++++++++++
> 1 file changed, 218 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> new file mode 100644
> index 0000000..46584ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
> @@ -0,0 +1,218 @@
> +Renesas RZ/A1 combined Pin and GPIO controller
> +
> +The Renesas SoCs of RZ/A1 family feature a combined Pin and GPIO controller,
Renesas SoCs of the RZ/A1 family
> +named "Ports" in the hardware reference manual.
> +Pin multiplexing and GPIO configuration is performed on a per-pin basis
> +writing configuration values to per-port register sets.
> +Each "port" features up to 16 pins, each of them configurable for GPIO
> +function (port mode) or in alternate function mode.
> +Up to 8 different alternate function modes exist for each single pin.
> +
> +Pin controller node
> +-------------------
> +
> +Required properties:
> + - compatible
> + this shall be "renesas,r7s72100-ports".
> +
> + - reg
> + address base and length of the memory area where pin controller
the pin controller hardware
> + hardware is mapped to.
> +
> +Example:
> +Pin controller node for RZ/A1H SoC (r7s72100)
> +
> +pinctrl: pin-controller@fcfe3000 {
> + compatible = "renesas,r7s72100-ports";
> +
> + reg = <0xfcfe3000 0x4230>;
> +};
> +
> +Sub-nodes
> +---------
> +
> +The child nodes of the pin controller node describe a pin multiplexing
> +function or a gpio controller alternatively.
"GPIO", to be consistent (there are more to fix)
> +
> +- Pin multiplexing sub-nodes:
> + A pin multiplexing sub-node describes how to configure a set of
> + (or a single) pin in some desired alternate function mode.
> + A single sub-node may define several pin configurations.
> + Some alternate functions require special pin configuration flags to be
> + supplied along with the alternate function configuration number.
> + When hardware reference manual specifies a pin function to be either
the hardware reference manual
> + "bi-directional" or "software IO driven", use the generic properties from
from the
> + <include/linux/pinctrl/pinconf_generic.h> header file to instruct the
> + pin controller to perform the desired pin configuration operations.
> + Please refer to pinctrl-bindings.txt to get to know more on generic
> + pin properties usage.
> + Supported generic properties:
Optional generic properties?
> + - bi-directional:
> + for pins requiring bi-directional operations.
> + - input-enable:
> + for pins requiring software driven IO input operations.
> + - output-enable:
> + for pins requiring software driver IO output operations.
I think you can move this here:
The hardware reference manual specifies when a pin has to be configured to
work in bi-directional mode.
> +
> + Example:
> + A serial communication interface with a TX output pin and an RX input pin.
[...]
> + Pin #4 on port #1 is configured as alternate function #1.
> + Pin #5 on port #1 is configured as alternate function #1.
> + Both need to work in bi-directional mode.
> + The hardware reference manual specifies when a pin has to be configured to
> + work in bi-directional mode.
... and remove the two lines above here...
> +
> + Example 3:
> + Multi-function timer input and output compare pins.
> + Configure TIOC0A as software driven input and TIOC0B as software driven
> + output.
[...]
> + Pin #0 on port #4 is configured as alternate function #2 with IO direction
> + specified by software as input.
> + Pin #1 on port #4 is configured as alternate function #1 with IO direction
> + specified by software as output.
> + The hardware reference manual specifies when a pin has to be configured with
> + input/output direction specified by software.
... and here.
> +
> +- GPIO controller sub-nodes:
> + Each port of the r7s72100 pin controller hardware is itself a gpio controller.
> + Different SoCs have different number of available pins per port, but
numbers of
> + generally speaking, each of them can be configured in GPIO ("port") mode
> + on this hardware.
> + Describe gpio-controllers using sub-nodes with the following properties.
GPIO controllers
> +
> + Required properties:
> + - gpio-controller
> + empty property as defined by the gpio bindings documentation.
> + - #gpio-cells
> + number of cells required to identify and configure a GPIO.
> + Shall be 2.
> + - gpio-ranges
> + Describes a gpio controller specifying its specific pin base, the pin
> + base in the global pin numbering space, and the number of controlled
> + pins, as defined by the gpio bindings documentation. Refer to this file
Documentation/devicetree/bindings/gpio/gpio.txt
> + for a more detailed description.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: Document the STM32 DMAMUX bindings
From: Pierre Yves MORDRET @ 2017-04-26 8:58 UTC (permalink / raw)
To: Rob Herring, M'boumba Cedric Madianga
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com,
dmaengine@vger.kernel.org, dan.j.williams@intel.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170320213413.4b6uopuilznyr2rl@rob-hp-laptop>
Hi Rob
On 03/20/2017 10:34 PM, Rob Herring wrote:
> On Mon, Mar 13, 2017 at 03:15:57PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds the documentation of device tree bindings for the STM32
>> DMAMUX.
>>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>> ---
>> .../devicetree/bindings/dma/stm32-dmamux.txt | 57 ++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/stm32-dmamux.txt b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>> new file mode 100644
>> index 0000000..1039420
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/stm32-dmamux.txt
>> @@ -0,0 +1,57 @@
>> +STM32 DMA MUX (DMA request router)
>> +
>> +Required properties:
>> +- compatible: "st,stm32-dmamux"
>> +- reg: Memory map for accessing module
>> +- #dma-cells: Should be set to <4>.
>> + For more details about the four cells, please see stm32-dma.txt
>> + documentation binding file
>> +- dma-masters: Phandle pointing to the DMA controller
>> +- clocks: Input clock of the DMAMUX instance.
>> +
>> +Optional properties:
>> +- dma-channels : Number of DMA channels supported.
>> +- dma-requests : Number of DMA requests supported.
>> +- resets: Reference to a reset controller asserting the DMA controller
>> +
>> +Example:
>> +
>> +/* DMA controller */
>> +dma2: dma-controller@40026400 {
>> + compatible = "st,stm32-dma";
>> + reg = <0x40026400 0x400>;
>> + interrupts = <56>,
>> + <57>,
>> + <58>,
>> + <59>,
>> + <60>,
>> + <68>,
>> + <69>,
>> + <70>;
>> + clocks = <&clk_hclk>;
>> + #dma-cells = <4>;
>> + st,mem2mem;
>> + resets = <&rcc 150>;
>> + st,dmamux;
>> + dma-channels = <8>;
>> +};
>> +
>> +/* DMA mux */
>> +dmamux2: dma-router@40020820 {
>> + compatible = "st,stm32-dmamux";
>> + reg = <0x40020800 0x1c>;
>> + #dma-cells = <4>;
>> + dma-requests = <128>;
>> + dma-masters = <&dma2>;
>
> I think this should be modeled after the interrupt-map property (or
> Stephen Boyd's gpio-map support which additionally allows pass thru of
> cell values). Something like this:
>
> dma-map = <0 41 0 0 &dma2 0 <req> 0 0>,
> <1 42 0 0 &dma2 1 <req> 0 0>;
> dma-map-mask = <0xffffffff 0xffffffff 0 0>;
>
> <req> is the request number on dma2 controller.
>
> This is more generic and would work if you have a single mux with
> multiple DMA controllers.
>
Would you mind to detail a little bit more your thoughts please ?
Are dma-map & dma-map-mask part of an existing bindings ? or need to be
developed ?
I'm a little bit confused where come from values you used.
>> +};
>> +
>> +/* DMA client */
>> +usart1: serial@40011000 {
>> + compatible = "st,stm32-usart", "st,stm32-uart";
>> + reg = <0x40011000 0x400>;
>> + interrupts = <37>;
>> + clocks = <&clk_pclk2>;
>> + dmas = <&dmamux2 0 41 0x400 0x00>,
>> + <&dmamux2 1 42 0x400 0x00>;
>> + dma-names = "rx", "tx";
>> +};
>> --
>> 1.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
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-26 8:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdXbe=rkeS+-teg7nqbjULWY0_5pBO1XEzCGdYA4gB57oA@mail.gmail.com>
On Wed, Apr 26, 2017 at 10:11:55AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> CC Vladimir (which I forgot to CC initially, sorry for that)
>
> On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> >> The Renesas Salvator-X and ULCB development board can be equipped with
> >> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> >> use separate DTBs, but currently there's no sharing of board-specific
> >> devices in DTS.
> >>
> >> This series reduces duplication by extracting common board support into
> >> their own .dtsi files. As the level of support varies across boards and
> >> SoCs, this requires the addition of a few external clocks and
> >> placeholder devices on R-Car M3-W, so the common board support DTS can
> >> refer to them.
> >>
> >> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> >> M3-W, which are present in r8a7795.dtsi, and used in
> >> r8a7795-salvator-x.dts,
> >> - RFC patch 3 adds placeholders for devices that are not yet supported
> >> and/or tested on R-Car M3-W, but used on R-Car H3,
> >> - RFC patch 4 extracts common Salvator-X board support,
> >> - RFC patch 5 extracts common ULCB board support.
> >>
> >> For R-Car H3 based boards, there are no functional changes.
> >> For R-Car M3-W based boards, some new devices are now described in DT.
> >>
> >> Dependencies:
> >> - renesas-devel-20170420-v4.11-rc7,
> >> - Patches 1 and 2 can be applied as-is,
> >> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> >> out R-Car H3 and M3-W SiP"
> >> (http://www.spinics.net/lists/devicetree/msg173820.html).
> >>
> >> DTB changes have been inspected using scripts/dtc/dtx_diff.
> >> This has been tested on Salvator-X (both H3 and M3-W).
> >> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
> >>
> >> Thanks for your comments!
> >
> > Thanks for tackling this important problem. I have looked over the changes
> > and they seem nice to me. I would, however, be more comfortable applying
> > them if they were rested on the ULCB boards.
>
> tested?
Yes, tested :)
> I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
^ permalink raw reply
* Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback
From: Jose Abreu @ 2017-04-26 8:55 UTC (permalink / raw)
To: Vineet Gupta,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Carlos Palminha, Alexey Brodkin, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <77599cf5-33e5-2ecd-2b2a-43630195a3b8-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hi Vineet,
On 24-04-2017 18:36, Vineet Gupta wrote:
> On 04/21/2017 03:15 AM, Jose Abreu wrote:
>> This patch adds the necessary DT bindings to get HDMI audio
>> output in ARC AXS10x SDP. The bindings for I2S controller were
>> added as well as the bindings for simple audio card.
> Are these waiting on Rob or is it OK for me to pick these up for 4.12 ?
Yes, I was waiting for Rob ack but he has been silent. It would
be nice if these went for 4.12.
Best regards,
Jose Miguel Abreu
>
> -Vineet
>
>> Signed-off-by: Jose Abreu <joabreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Acked-by: Alexey Brodkin <abrodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: Carlos Palminha <palminha-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: Alexey Brodkin <abrodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Vineet Gupta <vgupta-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> arch/arc/boot/dts/axs10x_mb.dtsi | 22 ++++++++++++++++++----
>> 1 file changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
>> index d6c1bbc..9d882b1 100644
>> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
>> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
>> @@ -149,12 +149,13 @@
>> interrupts = <14>;
>> };
>>
>> - i2c@0x1e000 {
>> - compatible = "snps,designware-i2c";
>> + i2s: i2s@1e000 {
>> + compatible = "snps,designware-i2s";
>> reg = <0x1e000 0x100>;
>> - clock-frequency = <400000>;
>> - clocks = <&i2cclk>;
>> + clocks = <&i2sclk 0>;
>> + clock-names = "i2sclk";
>> interrupts = <15>;
>> + #sound-dai-cells = <0>;
>> };
>>
>> i2c@0x1f000 {
>> @@ -174,6 +175,7 @@
>> adi,input-colorspace = "rgb";
>> adi,input-clock = "1x";
>> adi,clock-delay = <0x03>;
>> + #sound-dai-cells = <0>;
>>
>> ports {
>> #address-cells = <1>;
>> @@ -295,5 +297,17 @@
>> };
>> };
>> };
>> +
>> + sound_playback {
>> + compatible = "simple-audio-card";
>> + simple-audio-card,name = "AXS10x HDMI Audio";
>> + simple-audio-card,format = "i2s";
>> + simple-audio-card,cpu {
>> + sound-dai = <&i2s>;
>> + };
>> + simple-audio-card,codec {
>> + sound-dai = <&adv7511>;
>> + };
>> + };
>> };
>> };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Geert Uytterhoeven @ 2017-04-26 8:11 UTC (permalink / raw)
To: Simon Horman
Cc: Mark Rutland, devicetree@vger.kernel.org, Geert Uytterhoeven,
Kuninori Morimoto, Yoshihiro Shimoda, Magnus Damm,
Vladimir Barinov, Linux-Renesas, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170426080642.GK25517@verge.net.au>
Hi Simon,
CC Vladimir (which I forgot to CC initially, sorry for that)
On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
>> The Renesas Salvator-X and ULCB development board can be equipped with
>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
>> use separate DTBs, but currently there's no sharing of board-specific
>> devices in DTS.
>>
>> This series reduces duplication by extracting common board support into
>> their own .dtsi files. As the level of support varies across boards and
>> SoCs, this requires the addition of a few external clocks and
>> placeholder devices on R-Car M3-W, so the common board support DTS can
>> refer to them.
>>
>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
>> M3-W, which are present in r8a7795.dtsi, and used in
>> r8a7795-salvator-x.dts,
>> - RFC patch 3 adds placeholders for devices that are not yet supported
>> and/or tested on R-Car M3-W, but used on R-Car H3,
>> - RFC patch 4 extracts common Salvator-X board support,
>> - RFC patch 5 extracts common ULCB board support.
>>
>> For R-Car H3 based boards, there are no functional changes.
>> For R-Car M3-W based boards, some new devices are now described in DT.
>>
>> Dependencies:
>> - renesas-devel-20170420-v4.11-rc7,
>> - Patches 1 and 2 can be applied as-is,
>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
>> out R-Car H3 and M3-W SiP"
>> (http://www.spinics.net/lists/devicetree/msg173820.html).
>>
>> DTB changes have been inspected using scripts/dtc/dtx_diff.
>> This has been tested on Salvator-X (both H3 and M3-W).
>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>>
>> Thanks for your comments!
>
> Thanks for tackling this important problem. I have looked over the changes
> and they seem nice to me. I would, however, be more comfortable applying
> them if they were rested on the ULCB boards.
tested?
I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
Thanks!
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
^ permalink raw reply
* Re: [SPAM]Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Ryder Lee @ 2017-04-26 8:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <CAK8P3a1vgi9VBZfRNq0dDKzmfe8FkHQtgz6fEXW9fyUnBHtaQQ@mail.gmail.com>
Hi
On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote:
> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> > Add documentation for PCIe host driver available in MT7623
> > series SoCs.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
> > 1 file changed, 153 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> > new file mode 100644
> > index 0000000..ee93ba2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> > @@ -0,0 +1,153 @@
> > +Mediatek MT7623 PCIe controller
> > +
> > +Required properties:
> > +- compatible: Should contain "mediatek,mt7623-pcie".
>
> Did mediatek license the IP block from someone else or was it
> developed in-house? Is there a name and/or version identifier
> for the block itself other than identifying it as the one in mt7623?
Originally, it license from synopsys. Our designer add a wrapper to hide
the DBI detail so that we cannot use them directly. Perhaps I can call
it "mediatek,gen2v1-pcie", because we have a plan to upstream a in-house
Gen2 IP in the future.
> > +- device_type: Must be "pci"
> > +- reg: Base addresses and lengths of the pcie controller.
> > +- interrupts: A list of interrupt outputs of the controller.
>
> Please be more specific about what each interrupt is for, and how
> many there are.
OK.
> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > + and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
> > + property is sufficient.
> > +- clocks: Must contain an entry for each entry in clock-names.
> > + See ../clocks/clock-bindings.txt for details.
> > +- clock-names: Must include the following entries:
> > + - sys_ck
> > +- resets: Must contain an entry for each entry in reset-names.
> > + See ../reset/reset.txt for details.
>
> This seems odd: you have a device that is simply identified as "pci"
> without any more specific ID, but you require additional properties
> (clocks, reset, ...) that are not part of the standard PCI binding.
>
> Can you clarify how the port devices related to the root device in
> this hardware design?
I will write clarify like this:
PCIe subsys includes one Host/PCI bridge and 3 PCIe MAC port. There
are 3 bus master for data access and 1 slave for configuration and
status register access. Each port has PIPE interface to PHY and
> Have you considered moving the nonstandard properties into the host
> bridge node and having that device deal with setting up the links
> to the other drivers? That way we could use the regular pcie
> port driver for the children.
>
OK, but I still want to use port->reset to catch reset properties in
driver.
> > +- reset-names: Must include the following entries:
> > + - pcie-reset
> > +- num-lanes: Number of lanes to use for this port.
> > +- phys: Must contain an entry for each entry in phy-names.
> > +- phy-names: Must include an entry for each sub node. Entries are of the form
> > + "pcie-phyN": where N ranges from 0 to the value specified for port number.
> > + See ../phy/phy-mt7623-pcie.txt for details.
>
> I think the name should not include the number of the port but rather
> be always the same here.
>
Hmm, I think it's better to keep the name here. It's more readable for
user to understand the relationship between port0 and phy0.
> Arnd
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Ryder Lee @ 2017-04-26 8:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <CAK8P3a39TFkJ5=jp8me+Dyg-Qi-N_1ZKxpJGvnhmPEo4csnFCw@mail.gmail.com>
Hi,
On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote:
> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>
> > +static inline bool mtk_pcie_link_is_up(struct mtk_pcie_port *port)
> > +{
> > + return !!(readl_relaxed(port->base + PCIE_LINK_STATUS) &
> > + PCIE_PORT_LINKUP);
> > +}
>
> If this is not performance critical, please use the regular readl() instead
> of readl_relaxed().
I will correct it.
> > +static bool mtk_pcie_valid_device(struct mtk_pcie *pcie,
> > + struct pci_bus *bus, int devfn)
> > +{
> > + struct mtk_pcie_port *port;
> > + struct pci_dev *dev;
> > + struct pci_bus *pbus;
> > +
> > + /* if there is no link, then there is no device */
> > + list_for_each_entry(port, &pcie->ports, list) {
> > + if (bus->number == 0 && port->index == PCI_SLOT(devfn) &&
> > + mtk_pcie_link_is_up(port)) {
> > + return true;
> > + } else if (bus->number != 0) {
> > + pbus = bus;
> > + do {
> > + dev = pbus->self;
> > + if (port->index == PCI_SLOT(dev->devfn) &&
> > + mtk_pcie_link_is_up(port)) {
> > + return true;
> > + }
> > + pbus = dev->bus;
> > + } while (dev->bus->number != 0);
> > + }
> > + }
> > +
> > + return false;
> > +}
>
>
>
>
> > +static int mtk_pcie_hw_rd_cfg(struct mtk_pcie *pcie, u32 bus, u32 devfn,
> > + int where, int size, u32 *val)
> > +{
> > + writel(PCIE_CONF_ADDR(where, PCI_FUNC(devfn), PCI_SLOT(devfn), bus),
> > + pcie->base + PCIE_CFG_ADDR);
> > +
> > + *val = 0;
> > +
> > + switch (size) {
> > + case 1:
> > + *val = readb(pcie->base + PCIE_CFG_DATA + (where & 3));
> > + break;
> > + case 2:
> > + *val = readw(pcie->base + PCIE_CFG_DATA + (where & 2));
> > + break;
> > + case 4:
> > + *val = readl(pcie->base + PCIE_CFG_DATA);
> > + break;
> > + }
> > +
> > + return PCIBIOS_SUCCESSFUL;
> > +}
>
> This is a fairly standard set of read/write operations. Can you change
> the pci_ops
> to use pci_generic_config_read/pci_generic_config_write and an appropriate
> map function instead?
OK I will add a .map_bus() like this:
{ .
writel(PCIE_CONF_ADDR(where, fun, slot, bus), base + PCIE_CFG_ADDR);
return base + PCIE_CFG_DATA + (where & 3);
}
> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
> > +{
> > + struct device *dev = pcie->dev;
> > + struct mtk_pcie_port *port, *tmp;
> > + int err, linkup = 0;
> > +
> > + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> > + err = clk_prepare_enable(port->sys_ck);
> > + if (err) {
> > + dev_err(dev, "failed to enable port%d clock\n",
> > + port->index);
> > + continue;
> > + }
> > +
> > + /* assert RC */
> > + reset_control_assert(port->reset);
> > + /* de-assert RC */
> > + reset_control_deassert(port->reset);
> > +
> > + /* power on PHY */
> > + err = phy_power_on(port->phy);
> > + if (err) {
> > + dev_err(dev, "failed to power on port%d phy\n",
> > + port->index);
> > + goto err_phy_on;
> > + }
> > +
> > + mtk_pcie_assert_ports(port);
> > +
>
> Similar to the comment I had for the binding, I wonder if it would be
> better to keep all the information about the ports in one place and
> then just deal with it at the root level.
>
> Alternatively, we could decide to standardize on the properties
> you have added to the pcie port node, but then I would handle
> them in the pcieport driver rather than in the host bridge driver.
Sorry, I'm not sure what you want me to do here.
I could move all clock operation in root level. But we need to keep the
reset and PHY operation sequence in the loop, In addition, we could
easily free resources if ports link fail.
How about moving this function to mtk_pcie_parse_and_add_res()?
> > +/*
> > + * This IP lacks interrupt status register to check or map INTx from
> > + * different devices at the same time.
> > + */
> > +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> > +{
> > + struct mtk_pcie *pcie = dev->bus->sysdata;
> > + struct mtk_pcie_port *port;
> > +
> > + list_for_each_entry(port, &pcie->ports, list)
> > + if (port->index == slot)
> > + return port->irq;
> > +
> > + return -1;
> > +}
>
> This looks odd, what is it needed for specifically? It looks like
> it's broken for devices behind bridges, and the interrupt mapping
> should normally come from the interrupt-map property, without
> the need for a driver specific map_irq override.
Our hardware just has a GIC for each port and lacks interrupt status for
host driver to distinguish INTx. So I return port IRQ here.
> > +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
> > +{
> > + struct pci_bus *bus, *child;
> > +
> > + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
> > + &pcie->resources);
>
> Can you use the new pci_register_host_bridge() method instead of
> pci_scan_root_bus() here?
May I know what's difference between pci_scan_root_bus() and using
pci_register_host_bridge() directly? What situation should we use it?
It seems that just tegra use this new method currently.
I'm not sure whether I can still use pci_scan_root_bus() here?
> ARnd
Thanks for the review!
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-26 8:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland, devicetree, Kuninori Morimoto, Yoshihiro Shimoda,
Magnus Damm, linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <1492779321-23939-1-git-send-email-geert+renesas@glider.be>
Hi Geert,
On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> The Renesas Salvator-X and ULCB development board can be equipped with
> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> use separate DTBs, but currently there's no sharing of board-specific
> devices in DTS.
>
> This series reduces duplication by extracting common board support into
> their own .dtsi files. As the level of support varies across boards and
> SoCs, this requires the addition of a few external clocks and
> placeholder devices on R-Car M3-W, so the common board support DTS can
> refer to them.
>
> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> M3-W, which are present in r8a7795.dtsi, and used in
> r8a7795-salvator-x.dts,
> - RFC patch 3 adds placeholders for devices that are not yet supported
> and/or tested on R-Car M3-W, but used on R-Car H3,
> - RFC patch 4 extracts common Salvator-X board support,
> - RFC patch 5 extracts common ULCB board support.
>
> For R-Car H3 based boards, there are no functional changes.
> For R-Car M3-W based boards, some new devices are now described in DT.
>
> Dependencies:
> - renesas-devel-20170420-v4.11-rc7,
> - Patches 1 and 2 can be applied as-is,
> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> out R-Car H3 and M3-W SiP"
> (http://www.spinics.net/lists/devicetree/msg173820.html).
>
> DTB changes have been inspected using scripts/dtc/dtx_diff.
> This has been tested on Salvator-X (both H3 and M3-W).
> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>
> Thanks for your comments!
Thanks for tackling this important problem. I have looked over the changes
and they seem nice to me. I would, however, be more comfortable applying
them if they were rested on the ULCB boards.
^ permalink raw reply
* Re: [PATCH 13/15] drm/sun4i: Add HDMI support
From: Chen-Yu Tsai @ 2017-04-26 7:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Mike Turquette, Stephen Boyd, dri-devel,
Daniel Vetter, David Airlie, Mark Rutland, Rob Herring,
devicetree, linux-clk, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20170426065005.zoewz53q7l7r5e7p@lukather>
On Wed, Apr 26, 2017 at 2:50 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Chen-Yu,
>
> On Fri, Apr 21, 2017 at 11:17:17PM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
>> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
>> > controller.
>> >
>> > That HDMI controller is able to do audio and CEC, but those have been left
>> > out for now.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> > ---
>> > drivers/gpu/drm/sun4i/Makefile | 5 +-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi.h | 124 ++++++-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 128 ++++++-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 449 +++++++++++++++++++++-
>> > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 236 +++++++++++-
>> > 5 files changed, 942 insertions(+), 0 deletions(-)
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>>
>> Applying patch #9608371 using 'git am'
>> Description: [13/15] drm/sun4i: Add HDMI support
>> Applying: drm/sun4i: Add HDMI support
>> .git/rebase-apply/patch:116: trailing whitespace.
>>
>> .git/rebase-apply/patch:531: trailing whitespace.
>>
>> .git/rebase-apply/patch:701: trailing whitespace.
>>
>> warning: 3 lines add whitespace errors.
>
> Fixed.
>
>> > +int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *parent)
>> > +{
>> > + struct clk_init_data init;
>> > + struct sun4i_ddc *ddc;
>> > + const char *parent_name;
>> > +
>> > + parent_name = __clk_get_name(parent);
>> > + if (!parent_name)
>> > + return -ENODEV;
>> > +
>> > + ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
>> > + if (!ddc)
>> > + return -ENOMEM;
>> > +
>> > + init.name = "hdmi-ddc";
>> > + init.ops = &sun4i_ddc_ops;
>> > + init.parent_names = &parent_name;
>> > + init.num_parents = 1;
>> > + init.flags = CLK_SET_RATE_PARENT;
>>
>> I don't think this is really needed. It probably doesn't hurt though,
>> since DDC is used when HDMI is not used for displaying, but it might
>> affect any upstream PLLs, which theoretically may affect other users
>> of said PLLs. The DDC clock is slow enough that we should be able to
>> generate a usable clock rate anyway.
>
> Good point, I removed it.
>
>> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
>> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
>> > +
>> > + x = mode->htotal - mode->hsync_start;
>> > + y = mode->vtotal - mode->vsync_start;
>>
>> I'm a bit skeptical about this one. All the other parameters are not
>> inclusive of other, why would this one be different? Shouldn't it
>> be "Xtotal - Xsync_end" instead?
>
> By the usual meaning of backporch, you're right. However, Allwinner's
> seems to have it's own, which is actually the backporch + sync length.
>
> We also have that on all the other connectors (and TCON), and this was
> confirmed at the time using a scope on an RGB signal.
Yes. On the later SoCs such as the A31, the user manual actually has
timing diagrams showing this.
Unlike the TCON, the HDMI controller's timings lists the front porch
separately, instead of an all inclusive Xtotal. This is what made me
look twice. This should be easy to confirm though. Since the HDMI modes
are well known and can be exactly reproduced on our hardware, we can
just check for any distortions or refresh rate errors.
>
>>
>> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
>> > +
>> > + x = mode->hsync_start - mode->hdisplay;
>> > + y = mode->vsync_start - mode->vdisplay;
>> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
>> > +
>> > + x = mode->hsync_end - mode->hsync_start;
>> > + y = mode->vsync_end - mode->vsync_start;
>> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
>> > + hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
>> > +
>> > + val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
>> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
>> > + val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
>> > +
>> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
>> > + val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
>> > +
>> > + writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
>>
>> You don't handle the interlaced video here, even though you set
>>
>> hdmi->connector.interlace_allowed = true
>>
>> later.
>
> I'll fix that.
>
>> The double clock and double scan flags aren't handled either, though
>> I don't understand which one is supposed to represent the need for the
>> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
>> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
>
> I'm not sure about this one though. I'd like to keep things quite
> simple for now and build up on that once the basis is working. Is it
> common in the wild?
If you drive the display at SDTV resolutions, then yes. Mode lines from
my HDMI monitor:
720x576i 50 720 732 795 864 576 580 586 625 flags: nhsync, nvsync,
interlace, dblclk; type: driver
720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
interlace, dblclk; type: driver
720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
interlace, dblclk; type: driver
AFAIK these are standard modes that all devices should support. Whether
they are used daily is another thing. Maybe block modes with dblclk
in .mode_fixup for now?
>> > + hdmi->base + SUN4I_HDMI_DDC_FIFO_CTRL_REG);
>> > + writel(SUN4I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
>> > + SUN4I_HDMI_DDC_ADDR_EDDC(0x60) |
>> > + SUN4I_HDMI_DDC_ADDR_OFFSET(offset) |
>> > + SUN4I_HDMI_DDC_ADDR_SLAVE(0x50),
>>
>> You can use DDC_ADDR from drm_edid.h.
>
> Done.
There's also DDC_SEGMENT_ADDR (which is 0x30) you can use to replace 0x60.
The 1 bit shift is probably something related to I2C.
>> > +static enum drm_connector_status
>> > +sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
>> > +{
>> > + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
>> > + unsigned long reg;
>> > +
>> > + if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
>> > + reg & SUN4I_HDMI_HPD_HIGH,
>> > + 0, 500000))
>>
>> We shouldn't need to do polling here. It should just return the status
>> at the instance it's called. Instead we should have a worker that does
>> polling to check if something is plugged or unplugged. I don't see any
>> interrupt bits for this though. :(
>
> As far as I know, polling in detect is okay. Why would you want to
> remove it?
Hmm, I guess it only serves to debounce the detection, i.e. extend the
time period of validity from the instance the function is run to the
instance plus 500 ms.
To be clear I'm not against it. However this only really works when
the DRM subsystem is brought up. We still need something else for
hotplugging, which is what I was arguing for.
Regards
ChenYu
>> > + ret = drm_encoder_init(drm,
>> > + &hdmi->encoder,
>> > + &sun4i_hdmi_funcs,
>> > + DRM_MODE_ENCODER_TMDS,
>> > + NULL);
>> > + if (ret) {
>> > + dev_err(dev, "Couldn't initialise the HDMI encoder\n");
>> > + return ret;
>> > + }
>> > +
>> > + hdmi->encoder.possible_crtcs = BIT(0);
>>
>> You can use drm_of_find_possible_crtcs() now. See the TV encoder driver.
>
> Ack.
>
>> > +
>> > + drm_connector_helper_add(&hdmi->connector,
>> > + &sun4i_hdmi_connector_helper_funcs);
>> > + ret = drm_connector_init(drm, &hdmi->connector,
>> > + &sun4i_hdmi_connector_funcs,
>> > + DRM_MODE_CONNECTOR_HDMIA);
>> > + if (ret) {
>> > + dev_err(dev,
>> > + "Couldn't initialise the Composite connector\n");
>>
>> Wrong connector.
>
> Fixed.
>
>> > + ret = sun4i_ddc_create(hdmi, hdmi->tmds_clk);
>> > + if (ret) {
>> > + dev_err(&pdev->dev, "Couldn't create the DDC clock\n");
>> > + return ret;
>> > + }
>>
>> We do all this in the bind function for all the other components.
>> Any particular reason to do it differently here?
>
> Not really, I'll change it.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/2] gpio: DT bindings, move tca9554 from pcf857x to pca953x
From: Geert Uytterhoeven @ 2017-04-26 7:56 UTC (permalink / raw)
To: Anders Darander
Cc: Linus Walleij, Alexandre Courbot, Rob Herring,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Rutland
In-Reply-To: <20170421124631.19269-2-anders@chargestorm.se>
On Fri, Apr 21, 2017 at 2:46 PM, Anders Darander <anders@chargestorm.se> wrote:
> The TCA9554 is similar to the PCA9554. Update the DT binding docs.
>
> Signed-off-by: Anders Darander <anders@chargestorm.se>
> ---
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 +
> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index e63935710011..7f57271df2bc 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -26,6 +26,7 @@ Required properties:
> ti,tca6416
> ti,tca6424
> ti,tca9539
> + ti,tca9554
> onsemi,pca9654
> exar,xra1202
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> index ada4e2973323..7d3bd631d011 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> @@ -25,7 +25,6 @@ Required Properties:
> - "nxp,pcf8574": For the NXP PCF8574
> - "nxp,pcf8574a": For the NXP PCF8574A
> - "nxp,pcf8575": For the NXP PCF8575
> - - "ti,tca9554": For the TI TCA9554
>
> - reg: I2C slave address.
BTW, gpio-pca953x.txt seems to lack lots of gpio-controller-related properties.
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
^ permalink raw reply
* Re: [PATCH] arm64: dts: r8a7795: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-26 7:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, linux-arm-kernel@lists.infradead.org, Magnus Damm,
Sergei Shtylyov, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdVw9OJZarw3SRa7NuuaMtmDKPVN3Om0GFVFm5k_YAqn6g@mail.gmail.com>
On Mon, Apr 24, 2017 at 11:03:54AM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 24, 2017 at 10:51 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > The device trees for Renesas SoCs use either pfc or pin-controller
> > as the node name for the PFC device. This patch is intended to take a step
> > towards unifying the node name used as pin-controller which appears to
> > be more the more generic of the two and thus more in keeping with the DT
>
> s/be more/be/
>
> > specs.
> >
> > My analysis is that this is a user-visible change to the extent that kernel
> > logs, and sysfs entries change from e6060000.pfc and pfc@e6060000 to
> > e6060000.pin-controller and pin-controller@e6060000.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I fixed the typo when queuing this up.
^ permalink raw reply
* Re: [PATCH v2 09/23] MAINTAINERS: Add file patterns for infiniband device tree bindings
From: Geert Uytterhoeven @ 2017-04-26 7:36 UTC (permalink / raw)
To: Doug Ledford
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sean Hefty,
Hal Rosenstock, linux-rdma
In-Reply-To: <1493148079.3041.90.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Doug,
On Tue, Apr 25, 2017 at 9:21 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Sun, 2017-03-26 at 10:45 +0200, Geert Uytterhoeven wrote:
>> On Sat, Mar 25, 2017 at 3:40 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> wrote:
>> >
>> > On Sun, 2017-03-12 at 14:16 +0100, Geert Uytterhoeven wrote:
>> > >
>> > > Submitters of device tree binding documentation may forget to CC
>> > > the subsystem maintainer if this is missing.
>> > >
>> > > Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
>> > > Cc: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> > > Cc: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> > > Cc: Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > > Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> > > ---
>> > > Please apply this patch directly if you want to be involved in
>> > > device
>> > > tree binding documentation for your subsystem.
>> >
>> > I assume this is going through someone else' tree since I only see
>>
>> That wasn't my intention, though, cfr. the quoted paragraph above
>> ("you" and "your subsystem").
>
> Sorry, I didn't catch that in the original message. I've applied it to
> my tree.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards
From: Krzysztof Kozlowski @ 2017-04-26 7:22 UTC (permalink / raw)
To: Hoegeun Kwon
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
kgene-DgEjT+Ai2ygdnm+yROfE0A, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
a.hajda-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <1493085261-3488-1-git-send-email-hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, Apr 25, 2017 at 3:54 AM, Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
> 1 file changed, 1 deletion(-)
>
Looks correct. It is too late for me for v4.12 so I will pick it up
for v4.13. For my reference:
Reviewed-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support
From: Maxime Ripard @ 2017-04-26 6:50 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Mike Turquette, Stephen Boyd,
linux-kernel, dri-devel, linux-sunxi, Rob Herring, Daniel Vetter,
linux-clk, linux-arm-kernel
In-Reply-To: <CAGb2v66n6AXbOAh05V_Gv2UgRp=xEMG9qhJU8JSuy4-F-UOQQQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7563 bytes --]
Hi Chen-Yu,
On Fri, Apr 21, 2017 at 11:17:17PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
> > controller.
> >
> > That HDMI controller is able to do audio and CEC, but those have been left
> > out for now.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/gpu/drm/sun4i/Makefile | 5 +-
> > drivers/gpu/drm/sun4i/sun4i_hdmi.h | 124 ++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 128 ++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 449 +++++++++++++++++++++-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 236 +++++++++++-
> > 5 files changed, 942 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>
> Applying patch #9608371 using 'git am'
> Description: [13/15] drm/sun4i: Add HDMI support
> Applying: drm/sun4i: Add HDMI support
> .git/rebase-apply/patch:116: trailing whitespace.
>
> .git/rebase-apply/patch:531: trailing whitespace.
>
> .git/rebase-apply/patch:701: trailing whitespace.
>
> warning: 3 lines add whitespace errors.
Fixed.
> > +int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *parent)
> > +{
> > + struct clk_init_data init;
> > + struct sun4i_ddc *ddc;
> > + const char *parent_name;
> > +
> > + parent_name = __clk_get_name(parent);
> > + if (!parent_name)
> > + return -ENODEV;
> > +
> > + ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
> > + if (!ddc)
> > + return -ENOMEM;
> > +
> > + init.name = "hdmi-ddc";
> > + init.ops = &sun4i_ddc_ops;
> > + init.parent_names = &parent_name;
> > + init.num_parents = 1;
> > + init.flags = CLK_SET_RATE_PARENT;
>
> I don't think this is really needed. It probably doesn't hurt though,
> since DDC is used when HDMI is not used for displaying, but it might
> affect any upstream PLLs, which theoretically may affect other users
> of said PLLs. The DDC clock is slow enough that we should be able to
> generate a usable clock rate anyway.
Good point, I removed it.
> > + writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> > + SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> > +
> > + x = mode->htotal - mode->hsync_start;
> > + y = mode->vtotal - mode->vsync_start;
>
> I'm a bit skeptical about this one. All the other parameters are not
> inclusive of other, why would this one be different? Shouldn't it
> be "Xtotal - Xsync_end" instead?
By the usual meaning of backporch, you're right. However, Allwinner's
seems to have it's own, which is actually the backporch + sync length.
We also have that on all the other connectors (and TCON), and this was
confirmed at the time using a scope on an RGB signal.
>
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
> > +
> > + x = mode->hsync_start - mode->hdisplay;
> > + y = mode->vsync_start - mode->vdisplay;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
> > +
> > + x = mode->hsync_end - mode->hsync_start;
> > + y = mode->vsync_end - mode->vsync_start;
> > + writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> > + hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
> > +
> > + val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > + val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
> > +
> > + writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
>
> You don't handle the interlaced video here, even though you set
>
> hdmi->connector.interlace_allowed = true
>
> later.
I'll fix that.
> The double clock and double scan flags aren't handled either, though
> I don't understand which one is supposed to represent the need for the
> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
I'm not sure about this one though. I'd like to keep things quite
simple for now and build up on that once the basis is working. Is it
common in the wild?
> > + hdmi->base + SUN4I_HDMI_DDC_FIFO_CTRL_REG);
> > + writel(SUN4I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
> > + SUN4I_HDMI_DDC_ADDR_EDDC(0x60) |
> > + SUN4I_HDMI_DDC_ADDR_OFFSET(offset) |
> > + SUN4I_HDMI_DDC_ADDR_SLAVE(0x50),
>
> You can use DDC_ADDR from drm_edid.h.
Done.
> > +static enum drm_connector_status
> > +sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
> > +{
> > + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
> > + unsigned long reg;
> > +
> > + if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
> > + reg & SUN4I_HDMI_HPD_HIGH,
> > + 0, 500000))
>
> We shouldn't need to do polling here. It should just return the status
> at the instance it's called. Instead we should have a worker that does
> polling to check if something is plugged or unplugged. I don't see any
> interrupt bits for this though. :(
As far as I know, polling in detect is okay. Why would you want to
remove it?
> > + ret = drm_encoder_init(drm,
> > + &hdmi->encoder,
> > + &sun4i_hdmi_funcs,
> > + DRM_MODE_ENCODER_TMDS,
> > + NULL);
> > + if (ret) {
> > + dev_err(dev, "Couldn't initialise the HDMI encoder\n");
> > + return ret;
> > + }
> > +
> > + hdmi->encoder.possible_crtcs = BIT(0);
>
> You can use drm_of_find_possible_crtcs() now. See the TV encoder driver.
Ack.
> > +
> > + drm_connector_helper_add(&hdmi->connector,
> > + &sun4i_hdmi_connector_helper_funcs);
> > + ret = drm_connector_init(drm, &hdmi->connector,
> > + &sun4i_hdmi_connector_funcs,
> > + DRM_MODE_CONNECTOR_HDMIA);
> > + if (ret) {
> > + dev_err(dev,
> > + "Couldn't initialise the Composite connector\n");
>
> Wrong connector.
Fixed.
> > + ret = sun4i_ddc_create(hdmi, hdmi->tmds_clk);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't create the DDC clock\n");
> > + return ret;
> > + }
>
> We do all this in the bind function for all the other components.
> Any particular reason to do it differently here?
Not really, I'll change it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/3] iio: adc: meson-saradc: mark all meson_sar_adc_data static and const
From: Jonathan Cameron @ 2017-04-26 6:31 UTC (permalink / raw)
To: Martin Blumenstingl, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: carlo-KA+7E9HrN00dnm+yROfE0A, khilman-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170417182820.26670-4-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On 17/04/17 19:28, Martin Blumenstingl wrote:
> These are only passed as of_device_id.data and never modified. Thus we
> can mark them as static const, just like the of_device_id instances
> where they are used.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Reordering the patches would make this simpler as you'd only have
to do the existing ones.
Not a bit issue though so you could just not bother...
Jonathan
> ---
> drivers/iio/adc/meson_saradc.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index cf13691009ee..8f742b71b165 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -843,31 +843,31 @@ static const struct iio_info meson_sar_adc_iio_info = {
> .driver_module = THIS_MODULE,
> };
>
> -struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> .has_bl30_integration = false,
> .resolution = 10,
> .name = "meson-meson8b-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> .has_bl30_integration = false,
> .resolution = 10,
> .name = "meson-meson8b-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> .has_bl30_integration = true,
> .resolution = 10,
> .name = "meson-gxbb-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxl-saradc",
> };
>
> -struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> +static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxm-saradc",
>
^ permalink raw reply
* Re: [PATCH 2/3] iio: adc: meson-saradc: add Meson8b SoC compatibility
From: Jonathan Cameron @ 2017-04-26 6:29 UTC (permalink / raw)
To: Martin Blumenstingl, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: carlo-KA+7E9HrN00dnm+yROfE0A, khilman-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170417182820.26670-3-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On 17/04/17 19:28, Martin Blumenstingl wrote:
> Meson GX SoCs however use some magic bits to prevent simultaneous (=
> conflicting, because only consumer should use the FIFO buffer with the
> ADC results) usage by the Linux kernel and the bootloader (the BL30
> bootloader uses the SAR ADC to read the CPU temperature).
> This patch changes guards all BL30 functionality so it is skipped on
> SoCs which don't have it. Since the hardware itself doesn't know whether
> BL30 is available the internal meson_sar_adc_data is extended so this
> information can be provided per of_device_id.data inside the driver.
>
> Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
> clock-controller itself. "adc_sel" is not available at all. "adc_clk"
> is provided by the SAR ADC IP block itself on Meson8b (and earlier).
> This is already supported by the meson_saradc driver.
>
> Finally a new of_device_id for the Meson8b SoC is added so it can be
> wired up in the corresponding DT.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Fine apart from what superficially looks like a cut and paste error inline...
Jonathan
> ---
> drivers/iio/adc/meson_saradc.c | 80 +++++++++++++++++++++++++++++-------------
> 1 file changed, 56 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index dd4190b50df6..cf13691009ee 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
> };
>
> struct meson_sar_adc_data {
> + bool has_bl30_integration;
> unsigned int resolution;
> const char *name;
> };
> @@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>
> mutex_lock(&indio_dev->mlock);
>
> - /* prevent BL30 from using the SAR ADC while we are using it */
> - regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> -
> - /* wait until BL30 releases it's lock (so we can use the SAR ADC) */
> - do {
> - udelay(1);
> - regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> - } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> -
> - if (timeout < 0)
> - return -ETIMEDOUT;
> + if (priv->data->has_bl30_integration) {
> + /* prevent BL30 from using the SAR ADC while we are using it */
> + regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY);
> +
> + /*
> + * wait until BL30 releases it's lock (so we can use the SAR
> + * ADC)
> + */
> + do {
> + udelay(1);
> + regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
> + } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
> +
> + if (timeout < 0)
> + return -ETIMEDOUT;
> + }
>
> return 0;
> }
> @@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
> {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>
> - /* allow BL30 to use the SAR ADC again */
> - regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> - MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> + if (priv->data->has_bl30_integration)
> + /* allow BL30 to use the SAR ADC again */
> + regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> + MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
>
> mutex_unlock(&indio_dev->mlock);
> }
> @@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> */
> meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>
> - /*
> - * leave sampling delay and the input clocks as configured by BL30 to
> - * make sure BL30 gets the values it expects when reading the
> - * temperature sensor.
> - */
> - regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
> - if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> - return 0;
> + if (priv->data->has_bl30_integration) {
> + /*
> + * leave sampling delay and the input clocks as configured by
> + * BL30 to make sure BL30 gets the values it expects when
> + * reading the temperature sensor.
> + */
> + regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
> + if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
> + return 0;
> + }
>
> meson_sar_adc_stop_sample_engine(indio_dev);
>
> @@ -834,23 +843,46 @@ static const struct iio_info meson_sar_adc_iio_info = {
> .driver_module = THIS_MODULE,
> };
>
> +struct meson_sar_adc_data meson_sar_adc_meson8_data = {
> + .has_bl30_integration = false,
> + .resolution = 10,
> + .name = "meson-meson8b-saradc",
Not meson-meson8-saradc?
> +};
> +
> +struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
> + .has_bl30_integration = false,
> + .resolution = 10,
> + .name = "meson-meson8b-saradc",
> +};
> +
> struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
> + .has_bl30_integration = true,
> .resolution = 10,
> .name = "meson-gxbb-saradc",
> };
>
> struct meson_sar_adc_data meson_sar_adc_gxl_data = {
> + .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxl-saradc",
> };
>
> struct meson_sar_adc_data meson_sar_adc_gxm_data = {
> + .has_bl30_integration = true,
> .resolution = 12,
> .name = "meson-gxm-saradc",
> };
>
> static const struct of_device_id meson_sar_adc_of_match[] = {
> {
> + .compatible = "amlogic,meson8-saradc",
> + .data = &meson_sar_adc_meson8_data,
> + },
> + {
> + .compatible = "amlogic,meson8b-saradc",
> + .data = &meson_sar_adc_meson8b_data,
> + },
> + {
> .compatible = "amlogic,meson-gxbb-saradc",
> .data = &meson_sar_adc_gxbb_data,
> }, {
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] drm/sun4i: More cleanups and fixes
From: Maxime Ripard @ 2017-04-26 6:21 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: David Airlie, Rob Herring, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170425152505.6796-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
On Tue, Apr 25, 2017 at 11:25:02PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> The subject is probably getting old. Here are a few more cleanups.
>
> Patch 1 should have been part of the patch
>
> drm/sun4i: Use lists to track registered display backends and TCONs
>
> from my multiple pipeline support series. Please squash it in if you can.
>
> Patch 2 just moves setting the TCON clocks back inside the TCON driver.
>
> Patch 3 cleans up a DRM driver debug message.
Applied all, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window
From: Jonathan Cameron @ 2017-04-26 5:51 UTC (permalink / raw)
To: Lee Jones
Cc: mark.rutland, thomas.petazzoni, lars, linux-pm, liam,
linux-kernel, linux-sunxi, sre, linux-iio, linux, Quentin Schulz,
wens, robh+dt, icenowy, pmeerw, knaack.h, maxime.ripard,
devicetree, linux-arm-kernel
In-Reply-To: <20170424110239.cv5nylgvymhwvg4w@dell>
On 24/04/17 12:02, Lee Jones wrote:
> On Fri, 14 Apr 2017, Jonathan Cameron wrote:
>
>> On 11/04/17 11:05, Lee Jones wrote:
>>> Enjoy!
>>>
>>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
>>>
>>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-v4.12
>>>
>>> for you to fetch changes up to f2499ab450d3052097ba53a7d763f767935c0c59:
>>>
>>> iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs (2017-04-11 11:02:33 +0100)
>>>
>>> ----------------------------------------------------------------
>>> Immutable branch between MFD and IIO due for the v4.12 merge window
>>>
>>> ----------------------------------------------------------------
>>> Quentin Schulz (1):
>>> iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
>>>
>>> drivers/iio/adc/Kconfig | 10 +
>>> drivers/iio/adc/Makefile | 1 +
>>> drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 628 insertions(+)
>>> create mode 100644 drivers/iio/adc/axp20x_adc.c
>>>
>> Hi Lee,
>>
>> Thanks for doing this, but the reason it was going to go through your
>> tree in the first place was a dependency on
>> commit 4707274714ef ("mfd: axp20x: Correct name of temperature data ADC registers")
>>
>> Not present in the immutable branch.
>>
>> There isn't much time for anything else going on around this driver though
>> so other than a possible merge conflict on the Kconfig and Makefile shouldn't
>> matter if this just goes through mfd. (famous last words ;)
>
> It's not as though you committed it to text and sent it out to a
> public mailing list for us all to reference though is it? Doh!
>
It came up in the original discussions (which was the only reason I knew).
Chen-Yu Tsai in email:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/495789.html
Quentin did put a link in his request that you take it, but removing the
need to click would have been better!
Jonathan
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Rajendra Nayak @ 2017-04-26 4:32 UTC (permalink / raw)
To: Sudeep Holla, Viresh Kumar, Mark Brown
Cc: Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <95aa4b97-4e1a-13bb-f4d8-982b778012ba-5wv7dgnIgG8@public.gmane.org>
> On 17/04/17 06:27, Viresh Kumar wrote:
>> On 13-04-17, 14:42, Sudeep Holla wrote:
>>> What I was referring is about power domain provider with multiple power
>>> domains(simply #power-domain-cells=<1> case as explained in the
>>> power-domain specification.
>>
>> I am not sure if we should be looking to target such a situation for now, as
>> that would be like this:
>>
>> Device controlled by Domain A. Domain A itself is controlled by Domain B and
>> Domain C.
>>
>
> No, may be I was not so clear. I am just referring a power controller
> that provides say 3 different power domains and are indexed 0 - 2.
> The consumer just passes the index along with the phandle for the power
> domain info.
>
>> Though we will end up converting the domain-performance-state property to an
>> array if that is required in near future.
>>
>
> OK, better to document that so that we know how to extend it. We have
> #power-domain-cells=<1> on Juno with SCPI.
>
>>> Yes. To simplify what not we just have power-domain for a device and
>>> change state of that domain to change the performance of that device.
>>
>> Consider this case to understand what I have in Mind.
>>
>> The power domain have its states as A, B, C, D. There can be multiple devices
>> regulated by that domain and one of the devices have its power states as: A1,
>> A2, A3, B1, B2, B3, C1, C2, C3, D1, D2, D3 and all these states have different
>> frequency/voltages.
>>
>> IOW, the devices can have regulators as well and may want to fine tune within
>> the domain performance-state.
>>
>
> Understood. I would incline towards reusing regulators we that's what is
> changed behind the scene. Calling this operating performance point
> is misleading and doesn't align well with existing specs/features.
[]...
>>> If we are looking this power-domains with performance as just some
>>> *advanced regulators*, I don't like the complexity added.
+ Mark
I don;t see any public discussions on why we ruled out using regulators to
support this but maybe there were some offline discussions on this.
Mark, this is a long thread, so just summarizing here to give you the context.
At qualcomm, we have an external M3 core (running its own firmware) which controls
a few voltage rails (including AVS on those). The devices vote for the voltage levels
(or performance levels) they need by passing an integer value to the M3 (not actual
voltage values). Since that didn't fit well with the existing regulator apis it was
proposed we look at modeling these as powerdomain performance levels (and reuse genpd
framework) which is what this series from Viresh is about.
Since the discussion now is moving towards 'why not use regulator framework for this
instead of adding all the complexity with powerdomain performance levels since
these are regulators underneath', I looped you in so you can provide some feedback
on can these really be modeled as some *advanced regulators* with some apis to set some
regulator performance levels (instead of voltage levels).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree
From: Ryan Lee @ 2017-04-26 2:51 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
Kuninori Morimoto, Arnd Bergmann,
ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
lars-Qo5EllUWu/uELgA04lAiVw, bardliao-Rasf1IRRPZFBDgjK7y7TUQ,
nh6z-fFIq/eER6g8, KCHSU0-KrzQf0k3Iz9BDgjK7y7TUQ, Axel Lin,
romain.perier-ZGY8ohtN/8qB+jHODAdFcQ, Srinivas Kandagatla,
oder_chiou-Rasf1IRRPZFBDgjK7y7TUQ,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dylan Reid, Ryan Lee
In-Reply-To: <CAN4-oj=+WuNShte3e27XCWNHVTw6dBTUiQ=dmCLcX6nA9zx1eg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Apr 25, 2017 at 9:51 AM, Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org> wrote:
> '
>
> On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> The patch
>>
>> ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>>
>> has been applied to the asoc tree at
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>>
>> 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
>
> I have tried to check MAX98927 driver on linux-next tree and
> 'git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git' but
> have failed.
> So I wanted to check the current status of MAX98927 driver.
> I'm sorry for top-posting.
Please ignore this mail.
I just checked it is on linux-next tree.
I'm sorry again to make people confused.
>
>>
>> From 7c0c2000716e64151b3c0c62026c18f31537ebe9 Mon Sep 17 00:00:00 2001
>> From: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> Date: Tue, 4 Apr 2017 02:23:08 +0900
>> Subject: [PATCH] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>>
>> Signed-off-by: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> .../devicetree/bindings/sound/max98925.txt | 22 -
>> .../devicetree/bindings/sound/max98926.txt | 32 -
>> .../devicetree/bindings/sound/max9892x.txt | 41 +
>> sound/soc/codecs/Kconfig | 5 +
>> sound/soc/codecs/Makefile | 2 +
>> sound/soc/codecs/max98927.c | 841 +++++++++++++++++++++
>> sound/soc/codecs/max98927.h | 272 +++++++
>> 7 files changed, 1161 insertions(+), 54 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/sound/max98925.txt
>> delete mode 100644 Documentation/devicetree/bindings/sound/max98926.txt
>> create mode 100644 Documentation/devicetree/bindings/sound/max9892x.txt
>> create mode 100644 sound/soc/codecs/max98927.c
>> create mode 100644 sound/soc/codecs/max98927.h
>>
>> diff --git a/Documentation/devicetree/bindings/sound/max98925.txt b/Documentation/devicetree/bindings/sound/max98925.txt
>> deleted file mode 100644
>> index 27be63e2aa0d..000000000000
>> --- a/Documentation/devicetree/bindings/sound/max98925.txt
>> +++ /dev/null
>> @@ -1,22 +0,0 @@
>> -max98925 audio CODEC
>> -
>> -This device supports I2C.
>> -
>> -Required properties:
>> -
>> - - compatible : "maxim,max98925"
>> -
>> - - vmon-slot-no : slot number used to send voltage information
>> -
>> - - imon-slot-no : slot number used to send current information
>> -
>> - - reg : the I2C address of the device for I2C
>> -
>> -Example:
>> -
>> -codec: max98925@1a {
>> - compatible = "maxim,max98925";
>> - vmon-slot-no = <0>;
>> - imon-slot-no = <2>;
>> - reg = <0x1a>;
>> -};
>> diff --git a/Documentation/devicetree/bindings/sound/max98926.txt b/Documentation/devicetree/bindings/sound/max98926.txt
>> deleted file mode 100644
>> index 0b7f4e4d5f9a..000000000000
>> --- a/Documentation/devicetree/bindings/sound/max98926.txt
>> +++ /dev/null
>> @@ -1,32 +0,0 @@
>> -max98926 audio CODEC
>> -
>> -This device supports I2C.
>> -
>> -Required properties:
>> -
>> - - compatible : "maxim,max98926"
>> -
>> - - vmon-slot-no : slot number used to send voltage information
>> - or in inteleave mode this will be used as
>> - interleave slot.
>> -
>> - - imon-slot-no : slot number used to send current information
>> -
>> - - interleave-mode : When using two MAX98926 in a system it is
>> - possible to create ADC data that that will
>> - overflow the frame size. Digital Audio Interleave
>> - mode provides a means to output VMON and IMON data
>> - from two devices on a single DOUT line when running
>> - smaller frames sizes such as 32 BCLKS per LRCLK or
>> - 48 BCLKS per LRCLK.
>> -
>> - - reg : the I2C address of the device for I2C
>> -
>> -Example:
>> -
>> -codec: max98926@1a {
>> - compatible = "maxim,max98926";
>> - vmon-slot-no = <0>;
>> - imon-slot-no = <2>;
>> - reg = <0x1a>;
>> -};
>> diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt
>> new file mode 100644
>> index 000000000000..f6171591ddc6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/max9892x.txt
>> @@ -0,0 +1,41 @@
>> +Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier
>> +
>> +This device supports I2C.
>> +
>> +Required properties:
>> +
>> + - compatible : should be one of the following
>> + - "maxim,max98925"
>> + - "maxim,max98926"
>> + - "maxim,max98927"
>> +
>> + - vmon-slot-no : slot number used to send voltage information
>> + or in inteleave mode this will be used as
>> + interleave slot.
>> + MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
>> + MAX98927 slot range : 0 ~ 15, Default : 0
>> +
>> + - imon-slot-no : slot number used to send current information
>> + MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
>> + MAX98927 slot range : 0 ~ 15, Default : 0
>> +
>> + - interleave-mode : When using two MAX9892X in a system it is
>> + possible to create ADC data that that will
>> + overflow the frame size. Digital Audio Interleave
>> + mode provides a means to output VMON and IMON data
>> + from two devices on a single DOUT line when running
>> + smaller frames sizes such as 32 BCLKS per LRCLK or
>> + 48 BCLKS per LRCLK.
>> + Range : 0 (off), 1 (on), Default : 0
>> +
>> + - reg : the I2C address of the device for I2C
>> +
>> +Example:
>> +
>> +codec: max98927@3a {
>> + compatible = "maxim,max98927";
>> + vmon-slot-no = <0>;
>> + imon-slot-no = <1>;
>> + interleave-mode = <0>;
>> + reg = <0x3a>;
>> +};
>> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
>> index 9e1718a8cb1c..65e31ab88280 100644
>> --- a/sound/soc/codecs/Kconfig
>> +++ b/sound/soc/codecs/Kconfig
>> @@ -89,6 +89,7 @@ config SND_SOC_ALL_CODECS
>> select SND_SOC_MAX9867 if I2C
>> select SND_SOC_MAX98925 if I2C
>> select SND_SOC_MAX98926 if I2C
>> + select SND_SOC_MAX98927 if I2C
>> select SND_SOC_MAX9850 if I2C
>> select SND_SOC_MAX9860 if I2C
>> select SND_SOC_MAX9768 if I2C
>> @@ -585,6 +586,10 @@ config SND_SOC_MAX98925
>> config SND_SOC_MAX98926
>> tristate
>>
>> +config SND_SOC_MAX98927
>> + tristate "Maxim Integrated MAX98927 Speaker Amplifier"
>> + depends on I2C
>> +
>> config SND_SOC_MAX9850
>> tristate
>>
>> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
>> index 7e1dad79610b..64656c43200c 100644
>> --- a/sound/soc/codecs/Makefile
>> +++ b/sound/soc/codecs/Makefile
>> @@ -84,6 +84,7 @@ snd-soc-max98371-objs := max98371.o
>> snd-soc-max9867-objs := max9867.o
>> snd-soc-max98925-objs := max98925.o
>> snd-soc-max98926-objs := max98926.o
>> +snd-soc-max98927-objs := max98927.o
>> snd-soc-max9850-objs := max9850.o
>> snd-soc-max9860-objs := max9860.o
>> snd-soc-mc13783-objs := mc13783.o
>> @@ -312,6 +313,7 @@ obj-$(CONFIG_SND_SOC_MAX98357A) += snd-soc-max98357a.o
>> obj-$(CONFIG_SND_SOC_MAX9867) += snd-soc-max9867.o
>> obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
>> obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
>> +obj-$(CONFIG_SND_SOC_MAX98927) += snd-soc-max98927.o
>> obj-$(CONFIG_SND_SOC_MAX9850) += snd-soc-max9850.o
>> obj-$(CONFIG_SND_SOC_MAX9860) += snd-soc-max9860.o
>> obj-$(CONFIG_SND_SOC_MC13783) += snd-soc-mc13783.o
>> diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
>> new file mode 100644
>> index 000000000000..b5ee29499e16
>> --- /dev/null
>> +++ b/sound/soc/codecs/max98927.c
>> @@ -0,0 +1,841 @@
>> +/*
>> + * max98927.c -- MAX98927 ALSA Soc Audio driver
>> + *
>> + * Copyright (C) 2016 Maxim Integrated Products
>> + * Author: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +#include <linux/cdev.h>
>> +#include <sound/pcm.h>
>> +#include <sound/pcm_params.h>
>> +#include <sound/soc.h>
>> +#include <linux/gpio.h>
>> +#include <linux/of_gpio.h>
>> +#include <sound/tlv.h>
>> +#include "max98927.h"
>> +
>> +static struct reg_default max98927_reg[] = {
>> + {MAX98927_R0001_INT_RAW1, 0x00},
>> + {MAX98927_R0002_INT_RAW2, 0x00},
>> + {MAX98927_R0003_INT_RAW3, 0x00},
>> + {MAX98927_R0004_INT_STATE1, 0x00},
>> + {MAX98927_R0005_INT_STATE2, 0x00},
>> + {MAX98927_R0006_INT_STATE3, 0x00},
>> + {MAX98927_R0007_INT_FLAG1, 0x00},
>> + {MAX98927_R0008_INT_FLAG2, 0x00},
>> + {MAX98927_R0009_INT_FLAG3, 0x00},
>> + {MAX98927_R000A_INT_EN1, 0x00},
>> + {MAX98927_R000B_INT_EN2, 0x00},
>> + {MAX98927_R000C_INT_EN3, 0x00},
>> + {MAX98927_R000D_INT_FLAG_CLR1, 0x00},
>> + {MAX98927_R000E_INT_FLAG_CLR2, 0x00},
>> + {MAX98927_R000F_INT_FLAG_CLR3, 0x00},
>> + {MAX98927_R0010_IRQ_CTRL, 0x00},
>> + {MAX98927_R0011_CLK_MON, 0x00},
>> + {MAX98927_R0012_WDOG_CTRL, 0x00},
>> + {MAX98927_R0013_WDOG_RST, 0x00},
>> + {MAX98927_R0014_MEAS_ADC_THERM_WARN_THRESH, 0x00},
>> + {MAX98927_R0015_MEAS_ADC_THERM_SHDN_THRESH, 0x00},
>> + {MAX98927_R0016_MEAS_ADC_THERM_HYSTERESIS, 0x00},
>> + {MAX98927_R0017_PIN_CFG, 0x55},
>> + {MAX98927_R0018_PCM_RX_EN_A, 0x00},
>> + {MAX98927_R0019_PCM_RX_EN_B, 0x00},
>> + {MAX98927_R001A_PCM_TX_EN_A, 0x00},
>> + {MAX98927_R001B_PCM_TX_EN_B, 0x00},
>> + {MAX98927_R001C_PCM_TX_HIZ_CTRL_A, 0x00},
>> + {MAX98927_R001D_PCM_TX_HIZ_CTRL_B, 0x00},
>> + {MAX98927_R001E_PCM_TX_CH_SRC_A, 0x00},
>> + {MAX98927_R001F_PCM_TX_CH_SRC_B, 0x00},
>> + {MAX98927_R0020_PCM_MODE_CFG, 0x40},
>> + {MAX98927_R0021_PCM_MASTER_MODE, 0x00},
>> + {MAX98927_R0022_PCM_CLK_SETUP, 0x22},
>> + {MAX98927_R0023_PCM_SR_SETUP1, 0x00},
>> + {MAX98927_R0024_PCM_SR_SETUP2, 0x00},
>> + {MAX98927_R0025_PCM_TO_SPK_MONOMIX_A, 0x00},
>> + {MAX98927_R0026_PCM_TO_SPK_MONOMIX_B, 0x00},
>> + {MAX98927_R0027_ICC_RX_EN_A, 0x00},
>> + {MAX98927_R0028_ICC_RX_EN_B, 0x00},
>> + {MAX98927_R002B_ICC_TX_EN_A, 0x00},
>> + {MAX98927_R002C_ICC_TX_EN_B, 0x00},
>> + {MAX98927_R002E_ICC_HIZ_MANUAL_MODE, 0x00},
>> + {MAX98927_R002F_ICC_TX_HIZ_EN_A, 0x00},
>> + {MAX98927_R0030_ICC_TX_HIZ_EN_B, 0x00},
>> + {MAX98927_R0031_ICC_LNK_EN, 0x00},
>> + {MAX98927_R0032_PDM_TX_EN, 0x00},
>> + {MAX98927_R0033_PDM_TX_HIZ_CTRL, 0x00},
>> + {MAX98927_R0034_PDM_TX_CTRL, 0x00},
>> + {MAX98927_R0035_PDM_RX_CTRL, 0x00},
>> + {MAX98927_R0036_AMP_VOL_CTRL, 0x00},
>> + {MAX98927_R0037_AMP_DSP_CFG, 0x02},
>> + {MAX98927_R0038_TONE_GEN_DC_CFG, 0x00},
>> + {MAX98927_R0039_DRE_CTRL, 0x01},
>> + {MAX98927_R003A_AMP_EN, 0x00},
>> + {MAX98927_R003B_SPK_SRC_SEL, 0x00},
>> + {MAX98927_R003C_SPK_GAIN, 0x00},
>> + {MAX98927_R003D_SSM_CFG, 0x01},
>> + {MAX98927_R003E_MEAS_EN, 0x00},
>> + {MAX98927_R003F_MEAS_DSP_CFG, 0x04},
>> + {MAX98927_R0040_BOOST_CTRL0, 0x00},
>> + {MAX98927_R0041_BOOST_CTRL3, 0x00},
>> + {MAX98927_R0042_BOOST_CTRL1, 0x00},
>> + {MAX98927_R0043_MEAS_ADC_CFG, 0x00},
>> + {MAX98927_R0044_MEAS_ADC_BASE_MSB, 0x00},
>> + {MAX98927_R0045_MEAS_ADC_BASE_LSB, 0x00},
>> + {MAX98927_R0046_ADC_CH0_DIVIDE, 0x00},
>> + {MAX98927_R0047_ADC_CH1_DIVIDE, 0x00},
>> + {MAX98927_R0048_ADC_CH2_DIVIDE, 0x00},
>> + {MAX98927_R0049_ADC_CH0_FILT_CFG, 0x00},
>> + {MAX98927_R004A_ADC_CH1_FILT_CFG, 0x00},
>> + {MAX98927_R004B_ADC_CH2_FILT_CFG, 0x00},
>> + {MAX98927_R004C_MEAS_ADC_CH0_READ, 0x00},
>> + {MAX98927_R004D_MEAS_ADC_CH1_READ, 0x00},
>> + {MAX98927_R004E_MEAS_ADC_CH2_READ, 0x00},
>> + {MAX98927_R0051_BROWNOUT_STATUS, 0x00},
>> + {MAX98927_R0052_BROWNOUT_EN, 0x00},
>> + {MAX98927_R0053_BROWNOUT_INFINITE_HOLD, 0x00},
>> + {MAX98927_R0054_BROWNOUT_INFINITE_HOLD_CLR, 0x00},
>> + {MAX98927_R0055_BROWNOUT_LVL_HOLD, 0x00},
>> + {MAX98927_R005A_BROWNOUT_LVL1_THRESH, 0x00},
>> + {MAX98927_R005B_BROWNOUT_LVL2_THRESH, 0x00},
>> + {MAX98927_R005C_BROWNOUT_LVL3_THRESH, 0x00},
>> + {MAX98927_R005D_BROWNOUT_LVL4_THRESH, 0x00},
>> + {MAX98927_R005E_BROWNOUT_THRESH_HYSTERYSIS, 0x00},
>> + {MAX98927_R005F_BROWNOUT_AMP_LIMITER_ATK_REL, 0x00},
>> + {MAX98927_R0060_BROWNOUT_AMP_GAIN_ATK_REL, 0x00},
>> + {MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE, 0x00},
>> + {MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT, 0x00},
>> + {MAX98927_R0073_BROWNOUT_LVL1_AMP1_CTRL1, 0x00},
>> + {MAX98927_R0074_BROWNOUT_LVL1_AMP1_CTRL2, 0x00},
>> + {MAX98927_R0075_BROWNOUT_LVL1_AMP1_CTRL3, 0x00},
>> + {MAX98927_R0076_BROWNOUT_LVL2_CUR_LIMIT, 0x00},
>> + {MAX98927_R0077_BROWNOUT_LVL2_AMP1_CTRL1, 0x00},
>> + {MAX98927_R0078_BROWNOUT_LVL2_AMP1_CTRL2, 0x00},
>> + {MAX98927_R0079_BROWNOUT_LVL2_AMP1_CTRL3, 0x00},
>> + {MAX98927_R007A_BROWNOUT_LVL3_CUR_LIMIT, 0x00},
>> + {MAX98927_R007B_BROWNOUT_LVL3_AMP1_CTRL1, 0x00},
>> + {MAX98927_R007C_BROWNOUT_LVL3_AMP1_CTRL2, 0x00},
>> + {MAX98927_R007D_BROWNOUT_LVL3_AMP1_CTRL3, 0x00},
>> + {MAX98927_R007E_BROWNOUT_LVL4_CUR_LIMIT, 0x00},
>> + {MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1, 0x00},
>> + {MAX98927_R0080_BROWNOUT_LVL4_AMP1_CTRL2, 0x00},
>> + {MAX98927_R0081_BROWNOUT_LVL4_AMP1_CTRL3, 0x00},
>> + {MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM, 0x00},
>> + {MAX98927_R0083_ENV_TRACK_BOOST_VOUT_DELAY, 0x00},
>> + {MAX98927_R0084_ENV_TRACK_REL_RATE, 0x00},
>> + {MAX98927_R0085_ENV_TRACK_HOLD_RATE, 0x00},
>> + {MAX98927_R0086_ENV_TRACK_CTRL, 0x00},
>> + {MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ, 0x00},
>> + {MAX98927_R00FF_GLOBAL_SHDN, 0x00},
>> + {MAX98927_R0100_SOFT_RESET, 0x00},
>> + {MAX98927_R01FF_REV_ID, 0x40},
>> +};
>> +
>> +static int max98927_dai_set_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt)
>> +{
>> + struct snd_soc_codec *codec = codec_dai->codec;
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + unsigned int mode = 0;
>> + unsigned int format = 0;
>> + unsigned int invert = 0;
>> +
>> + dev_dbg(codec->dev, "%s: fmt 0x%08X\n", __func__, fmt);
>> +
>> + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
>> + case SND_SOC_DAIFMT_CBS_CFS:
>> + mode = MAX98927_PCM_MASTER_MODE_SLAVE;
>> + break;
>> + case SND_SOC_DAIFMT_CBM_CFM:
>> + max98927->master = true;
>> + mode = MAX98927_PCM_MASTER_MODE_MASTER;
>> + break;
>> + default:
>> + dev_err(codec->dev, "DAI clock mode unsupported");
>> + return -EINVAL;
>> + }
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0021_PCM_MASTER_MODE,
>> + MAX98927_PCM_MASTER_MODE_MASK,
>> + mode);
>> +
>> + switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
>> + case SND_SOC_DAIFMT_NB_NF:
>> + break;
>> + case SND_SOC_DAIFMT_IB_NF:
>> + invert = MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE;
>> + break;
>> + default:
>> + dev_err(codec->dev, "DAI invert mode unsupported");
>> + return -EINVAL;
>> + }
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0020_PCM_MODE_CFG,
>> + MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE,
>> + invert);
>> +
>> + /* interface format */
>> + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
>> + case SND_SOC_DAIFMT_I2S:
>> + max98927->iface |= SND_SOC_DAIFMT_I2S;
>> + format = MAX98927_PCM_FORMAT_I2S;
>> + break;
>> + case SND_SOC_DAIFMT_LEFT_J:
>> + max98927->iface |= SND_SOC_DAIFMT_LEFT_J;
>> + format = MAX98927_PCM_FORMAT_LJ;
>> + break;
>> + case SND_SOC_DAIFMT_PDM:
>> + max98927->iface |= SND_SOC_DAIFMT_PDM;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + /* pcm channel configuration */
>> + if (max98927->iface & (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_LEFT_J)) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0018_PCM_RX_EN_A,
>> + MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN,
>> + MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN);
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0020_PCM_MODE_CFG,
>> + MAX98927_PCM_MODE_CFG_FORMAT_MASK,
>> + format << MAX98927_PCM_MODE_CFG_FORMAT_SHIFT);
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003B_SPK_SRC_SEL,
>> + MAX98927_SPK_SRC_MASK, 0);
>> +
>> + } else
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0018_PCM_RX_EN_A,
>> + MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN, 0);
>> +
>> + /* pdm channel configuration */
>> + if (max98927->iface & SND_SOC_DAIFMT_PDM) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0035_PDM_RX_CTRL,
>> + MAX98927_PDM_RX_EN_MASK, 1);
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003B_SPK_SRC_SEL,
>> + MAX98927_SPK_SRC_MASK, 3);
>> + } else
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0035_PDM_RX_CTRL,
>> + MAX98927_PDM_RX_EN_MASK, 0);
>> + return 0;
>> +}
>> +
>> +/* codec MCLK rate in master mode */
>> +static const int rate_table[] = {
>> + 5644800, 6000000, 6144000, 6500000,
>> + 9600000, 11289600, 12000000, 12288000,
>> + 13000000, 19200000,
>> +};
>> +
>> +static int max98927_set_clock(struct max98927_priv *max98927,
>> + struct snd_pcm_hw_params *params)
>> +{
>> + struct snd_soc_codec *codec = max98927->codec;
>> + /* BCLK/LRCLK ratio calculation */
>> + int blr_clk_ratio = params_channels(params) * max98927->ch_size;
>> + int value;
>> +
>> + if (max98927->master) {
>> + int i;
>> + /* match rate to closest value */
>> + for (i = 0; i < ARRAY_SIZE(rate_table); i++) {
>> + if (rate_table[i] >= max98927->sysclk)
>> + break;
>> + }
>> + if (i == ARRAY_SIZE(rate_table)) {
>> + dev_err(codec->dev, "failed to find proper clock rate.\n");
>> + return -EINVAL;
>> + }
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0021_PCM_MASTER_MODE,
>> + MAX98927_PCM_MASTER_MODE_MCLK_MASK,
>> + i << MAX98927_PCM_MASTER_MODE_MCLK_RATE_SHIFT);
>> + }
>> +
>> + switch (blr_clk_ratio) {
>> + case 32:
>> + value = 2;
>> + break;
>> + case 48:
>> + value = 3;
>> + break;
>> + case 64:
>> + value = 4;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0022_PCM_CLK_SETUP,
>> + MAX98927_PCM_CLK_SETUP_BSEL_MASK,
>> + value);
>> + return 0;
>> +}
>> +
>> +static int max98927_dai_hw_params(struct snd_pcm_substream *substream,
>> + struct snd_pcm_hw_params *params,
>> + struct snd_soc_dai *dai)
>> +{
>> + struct snd_soc_codec *codec = dai->codec;
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> + unsigned int sampling_rate = 0;
>> + unsigned int chan_sz = 0;
>> +
>> + /* pcm mode configuration */
>> + switch (snd_pcm_format_width(params_format(params))) {
>> + case 16:
>> + chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_16;
>> + break;
>> + case 24:
>> + chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_24;
>> + break;
>> + case 32:
>> + chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_32;
>> + break;
>> + default:
>> + dev_err(codec->dev, "format unsupported %d",
>> + params_format(params));
>> + goto err;
>> + }
>> +
>> + max98927->ch_size = snd_pcm_format_width(params_format(params));
>> +
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0020_PCM_MODE_CFG,
>> + MAX98927_PCM_MODE_CFG_CHANSZ_MASK, chan_sz);
>> +
>> + dev_dbg(codec->dev, "format supported %d",
>> + params_format(params));
>> +
>> + /* sampling rate configuration */
>> + switch (params_rate(params)) {
>> + case 8000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_8000;
>> + break;
>> + case 11025:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_11025;
>> + break;
>> + case 12000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_12000;
>> + break;
>> + case 16000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_16000;
>> + break;
>> + case 22050:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_22050;
>> + break;
>> + case 24000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_24000;
>> + break;
>> + case 32000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_32000;
>> + break;
>> + case 44100:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_44100;
>> + break;
>> + case 48000:
>> + sampling_rate = MAX98927_PCM_SR_SET1_SR_48000;
>> + break;
>> + default:
>> + dev_err(codec->dev, "rate %d not supported\n",
>> + params_rate(params));
>> + goto err;
>> + }
>> + /* set DAI_SR to correct LRCLK frequency */
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0023_PCM_SR_SETUP1,
>> + MAX98927_PCM_SR_SET1_SR_MASK,
>> + sampling_rate);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0024_PCM_SR_SETUP2,
>> + MAX98927_PCM_SR_SET2_SR_MASK,
>> + sampling_rate << MAX98927_PCM_SR_SET2_SR_SHIFT);
>> +
>> + /* set sampling rate of IV */
>> + if (max98927->interleave_mode &&
>> + sampling_rate > MAX98927_PCM_SR_SET1_SR_16000)
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0024_PCM_SR_SETUP2,
>> + MAX98927_PCM_SR_SET2_IVADC_SR_MASK,
>> + sampling_rate - 3);
>> + else
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R0024_PCM_SR_SETUP2,
>> + MAX98927_PCM_SR_SET2_IVADC_SR_MASK,
>> + sampling_rate);
>> + return max98927_set_clock(max98927, params);
>> +err:
>> + return -EINVAL;
>> +}
>> +
>> +#define MAX98927_RATES SNDRV_PCM_RATE_8000_48000
>> +
>> +#define MAX98927_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
>> + SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)
>> +
>> +static int max98927_dai_set_sysclk(struct snd_soc_dai *dai,
>> + int clk_id, unsigned int freq, int dir)
>> +{
>> + struct snd_soc_codec *codec = dai->codec;
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> +
>> + max98927->sysclk = freq;
>> + return 0;
>> +}
>> +
>> +static const struct snd_soc_dai_ops max98927_dai_ops = {
>> + .set_sysclk = max98927_dai_set_sysclk,
>> + .set_fmt = max98927_dai_set_fmt,
>> + .hw_params = max98927_dai_hw_params,
>> +};
>> +
>> +static int max98927_dac_event(struct snd_soc_dapm_widget *w,
>> + struct snd_kcontrol *kcontrol, int event)
>> +{
>> + struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> +
>> + switch (event) {
>> + case SND_SOC_DAPM_POST_PMU:
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003A_AMP_EN,
>> + MAX98927_AMP_EN_MASK, 1);
>> + /* enable VMON and IMON */
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003E_MEAS_EN,
>> + MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN,
>> + MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R00FF_GLOBAL_SHDN,
>> + MAX98927_GLOBAL_EN_MASK, 1);
>> + break;
>> + case SND_SOC_DAPM_POST_PMD:
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R00FF_GLOBAL_SHDN,
>> + MAX98927_GLOBAL_EN_MASK, 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003A_AMP_EN,
>> + MAX98927_AMP_EN_MASK, 0);
>> + /* disable VMON and IMON */
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R003E_MEAS_EN,
>> + MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN, 0);
>> + break;
>> + default:
>> + return 0;
>> + }
>> + return 0;
>> +}
>> +
>> +static const char * const max98927_switch_text[] = {
>> + "Left", "Right", "LeftRight"};
>> +
>> +static const struct soc_enum dai_sel_enum =
>> + SOC_ENUM_SINGLE(MAX98927_R0025_PCM_TO_SPK_MONOMIX_A,
>> + MAX98927_PCM_TO_SPK_MONOMIX_CFG_SHIFT,
>> + 3, max98927_switch_text);
>> +
>> +static const struct snd_kcontrol_new max98927_dai_controls =
>> + SOC_DAPM_ENUM("DAI Sel", dai_sel_enum);
>> +
>> +static const struct snd_soc_dapm_widget max98927_dapm_widgets[] = {
>> + SND_SOC_DAPM_AIF_IN("DAI_OUT", "HiFi Playback", 0, SND_SOC_NOPM, 0, 0),
>> + SND_SOC_DAPM_DAC_E("Amp Enable", "HiFi Playback", MAX98927_R003A_AMP_EN,
>> + 0, 0, max98927_dac_event,
>> + SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
>> + SND_SOC_DAPM_MUX("DAI Sel Mux", SND_SOC_NOPM, 0, 0,
>> + &max98927_dai_controls),
>> + SND_SOC_DAPM_OUTPUT("BE_OUT"),
>> +};
>> +
>> +static DECLARE_TLV_DB_SCALE(max98927_spk_tlv, 300, 300, 0);
>> +static DECLARE_TLV_DB_SCALE(max98927_digital_tlv, -1600, 25, 0);
>> +
>> +static bool max98927_readable_register(struct device *dev, unsigned int reg)
>> +{
>> + switch (reg) {
>> + case MAX98927_R0001_INT_RAW1 ... MAX98927_R0028_ICC_RX_EN_B:
>> + case MAX98927_R002B_ICC_TX_EN_A ... MAX98927_R002C_ICC_TX_EN_B:
>> + case MAX98927_R002E_ICC_HIZ_MANUAL_MODE
>> + ... MAX98927_R004E_MEAS_ADC_CH2_READ:
>> + case MAX98927_R0051_BROWNOUT_STATUS
>> + ... MAX98927_R0055_BROWNOUT_LVL_HOLD:
>> + case MAX98927_R005A_BROWNOUT_LVL1_THRESH
>> + ... MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE:
>> + case MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT
>> + ... MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ:
>> + case MAX98927_R00FF_GLOBAL_SHDN:
>> + case MAX98927_R0100_SOFT_RESET:
>> + case MAX98927_R01FF_REV_ID:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +};
>> +
>> +static bool max98927_volatile_reg(struct device *dev, unsigned int reg)
>> +{
>> + switch (reg) {
>> + case MAX98927_R0001_INT_RAW1 ... MAX98927_R0009_INT_FLAG3:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> +static const char * const max98927_boost_voltage_text[] = {
>> + "6.5V", "6.625V", "6.75V", "6.875V", "7V", "7.125V", "7.25V", "7.375V",
>> + "7.5V", "7.625V", "7.75V", "7.875V", "8V", "8.125V", "8.25V", "8.375V",
>> + "8.5V", "8.625V", "8.75V", "8.875V", "9V", "9.125V", "9.25V", "9.375V",
>> + "9.5V", "9.625V", "9.75V", "9.875V", "10V"
>> +};
>> +
>> +static SOC_ENUM_SINGLE_DECL(max98927_boost_voltage,
>> + MAX98927_R0040_BOOST_CTRL0, 0,
>> + max98927_boost_voltage_text);
>> +
>> +static const char * const max98927_current_limit_text[] = {
>> + "1.00A", "1.10A", "1.20A", "1.30A", "1.40A", "1.50A", "1.60A", "1.70A",
>> + "1.80A", "1.90A", "2.00A", "2.10A", "2.20A", "2.30A", "2.40A", "2.50A",
>> + "2.60A", "2.70A", "2.80A", "2.90A", "3.00A", "3.10A", "3.20A", "3.30A",
>> + "3.40A", "3.50A", "3.60A", "3.70A", "3.80A", "3.90A", "4.00A", "4.10A"
>> +};
>> +
>> +static SOC_ENUM_SINGLE_DECL(max98927_current_limit,
>> + MAX98927_R0042_BOOST_CTRL1, 1,
>> + max98927_current_limit_text);
>> +
>> +static const struct snd_kcontrol_new max98927_snd_controls[] = {
>> + SOC_SINGLE_TLV("Speaker Volume", MAX98927_R003C_SPK_GAIN,
>> + 0, 6, 0,
>> + max98927_spk_tlv),
>> + SOC_SINGLE_TLV("Digital Volume", MAX98927_R0036_AMP_VOL_CTRL,
>> + 0, (1<<MAX98927_AMP_VOL_WIDTH)-1, 0,
>> + max98927_digital_tlv),
>> + SOC_SINGLE("Amp DSP Switch", MAX98927_R0052_BROWNOUT_EN,
>> + MAX98927_BROWNOUT_DSP_SHIFT, 1, 0),
>> + SOC_SINGLE("Ramp Switch", MAX98927_R0037_AMP_DSP_CFG,
>> + MAX98927_AMP_DSP_CFG_RMP_SHIFT, 1, 0),
>> + SOC_SINGLE("DRE Switch", MAX98927_R0039_DRE_CTRL,
>> + MAX98927_DRE_EN_SHIFT, 1, 0),
>> + SOC_SINGLE("Volume Location Switch", MAX98927_R0036_AMP_VOL_CTRL,
>> + MAX98927_AMP_VOL_SEL_SHIFT, 1, 0),
>> + SOC_ENUM("Boost Output Voltage", max98927_boost_voltage),
>> + SOC_ENUM("Current Limit", max98927_current_limit),
>> +};
>> +
>> +static const struct snd_soc_dapm_route max98927_audio_map[] = {
>> + {"Amp Enable", NULL, "DAI_OUT"},
>> + {"DAI Sel Mux", "Left", "Amp Enable"},
>> + {"DAI Sel Mux", "Right", "Amp Enable"},
>> + {"DAI Sel Mux", "LeftRight", "Amp Enable"},
>> + {"BE_OUT", NULL, "DAI Sel Mux"},
>> +};
>> +
>> +static struct snd_soc_dai_driver max98927_dai[] = {
>> + {
>> + .name = "max98927-aif1",
>> + .playback = {
>> + .stream_name = "HiFi Playback",
>> + .channels_min = 1,
>> + .channels_max = 2,
>> + .rates = MAX98927_RATES,
>> + .formats = MAX98927_FORMATS,
>> + },
>> + .capture = {
>> + .stream_name = "HiFi Capture",
>> + .channels_min = 1,
>> + .channels_max = 2,
>> + .rates = MAX98927_RATES,
>> + .formats = MAX98927_FORMATS,
>> + },
>> + .ops = &max98927_dai_ops,
>> + }
>> +};
>> +
>> +static int max98927_probe(struct snd_soc_codec *codec)
>> +{
>> + struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
>> +
>> + max98927->codec = codec;
>> + codec->control_data = max98927->regmap;
>> + codec->cache_bypass = 1;
>> +
>> + /* Software Reset */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0100_SOFT_RESET, MAX98927_SOFT_RESET);
>> +
>> + /* IV default slot configuration */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
>> + 0xFF);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
>> + 0xFF);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0025_PCM_TO_SPK_MONOMIX_A,
>> + 0x80);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0026_PCM_TO_SPK_MONOMIX_B,
>> + 0x1);
>> + /* Set inital volume (+13dB) */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0036_AMP_VOL_CTRL,
>> + 0x38);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R003C_SPK_GAIN,
>> + 0x05);
>> + /* Enable DC blocker */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0037_AMP_DSP_CFG,
>> + 0x03);
>> + /* Enable IMON VMON DC blocker */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R003F_MEAS_DSP_CFG,
>> + 0xF7);
>> + /* Boost Output Voltage & Current limit */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0040_BOOST_CTRL0,
>> + 0x1C);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0042_BOOST_CTRL1,
>> + 0x3E);
>> + /* Measurement ADC config */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0043_MEAS_ADC_CFG,
>> + 0x04);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0044_MEAS_ADC_BASE_MSB,
>> + 0x00);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0045_MEAS_ADC_BASE_LSB,
>> + 0x24);
>> + /* Brownout Level */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1,
>> + 0x06);
>> + /* Envelope Tracking configuration */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM,
>> + 0x08);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0086_ENV_TRACK_CTRL,
>> + 0x01);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ,
>> + 0x10);
>> +
>> + /* voltage, current slot configuration */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R001E_PCM_TX_CH_SRC_A,
>> + (max98927->i_l_slot<<MAX98927_PCM_TX_CH_SRC_A_I_SHIFT|
>> + max98927->v_l_slot)&0xFF);
>> +
>> + if (max98927->v_l_slot < 8) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
>> + 1 << max98927->v_l_slot, 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001A_PCM_TX_EN_A,
>> + 1 << max98927->v_l_slot,
>> + 1 << max98927->v_l_slot);
>> + } else {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
>> + 1 << (max98927->v_l_slot - 8), 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001B_PCM_TX_EN_B,
>> + 1 << (max98927->v_l_slot - 8),
>> + 1 << (max98927->v_l_slot - 8));
>> + }
>> +
>> + if (max98927->i_l_slot < 8) {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
>> + 1 << max98927->i_l_slot, 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001A_PCM_TX_EN_A,
>> + 1 << max98927->i_l_slot,
>> + 1 << max98927->i_l_slot);
>> + } else {
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
>> + 1 << (max98927->i_l_slot - 8), 0);
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001B_PCM_TX_EN_B,
>> + 1 << (max98927->i_l_slot - 8),
>> + 1 << (max98927->i_l_slot - 8));
>> + }
>> +
>> + /* Set interleave mode */
>> + if (max98927->interleave_mode)
>> + regmap_update_bits(max98927->regmap,
>> + MAX98927_R001F_PCM_TX_CH_SRC_B,
>> + MAX98927_PCM_TX_CH_INTERLEAVE_MASK,
>> + MAX98927_PCM_TX_CH_INTERLEAVE_MASK);
>> + return 0;
>> +}
>> +
>> +static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
>> + .probe = max98927_probe,
>> + .component_driver = {
>> + .controls = max98927_snd_controls,
>> + .num_controls = ARRAY_SIZE(max98927_snd_controls),
>> + .dapm_widgets = max98927_dapm_widgets,
>> + .num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
>> + .dapm_routes = max98927_audio_map,
>> + .num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
>> + },
>> +};
>> +
>> +static const struct regmap_config max98927_regmap = {
>> + .reg_bits = 16,
>> + .val_bits = 8,
>> + .max_register = MAX98927_R01FF_REV_ID,
>> + .reg_defaults = max98927_reg,
>> + .num_reg_defaults = ARRAY_SIZE(max98927_reg),
>> + .readable_reg = max98927_readable_register,
>> + .volatile_reg = max98927_volatile_reg,
>> + .cache_type = REGCACHE_RBTREE,
>> +};
>> +
>> +static void max98927_slot_config(struct i2c_client *i2c,
>> + struct max98927_priv *max98927)
>> +{
>> + int value;
>> +
>> + if (!of_property_read_u32(i2c->dev.of_node,
>> + "vmon-slot-no", &value))
>> + max98927->v_l_slot = value & 0xF;
>> + else
>> + max98927->v_l_slot = 0;
>> + if (!of_property_read_u32(i2c->dev.of_node,
>> + "imon-slot-no", &value))
>> + max98927->i_l_slot = value & 0xF;
>> + else
>> + max98927->i_l_slot = 1;
>> +}
>> +
>> +static int max98927_i2c_probe(struct i2c_client *i2c,
>> + const struct i2c_device_id *id)
>> +{
>> +
>> + int ret = 0, value;
>> + int reg = 0;
>> + struct max98927_priv *max98927 = NULL;
>> +
>> + max98927 = devm_kzalloc(&i2c->dev,
>> + sizeof(*max98927), GFP_KERNEL);
>> +
>> + if (!max98927) {
>> + ret = -ENOMEM;
>> + return ret;
>> + }
>> + i2c_set_clientdata(i2c, max98927);
>> +
>> + /* update interleave mode info */
>> + if (!of_property_read_u32(i2c->dev.of_node,
>> + "interleave_mode", &value)) {
>> + if (value > 0)
>> + max98927->interleave_mode = 1;
>> + else
>> + max98927->interleave_mode = 0;
>> + } else
>> + max98927->interleave_mode = 0;
>> +
>> + /* regmap initialization */
>> + max98927->regmap
>> + = devm_regmap_init_i2c(i2c, &max98927_regmap);
>> + if (IS_ERR(max98927->regmap)) {
>> + ret = PTR_ERR(max98927->regmap);
>> + dev_err(&i2c->dev,
>> + "Failed to allocate regmap: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + /* Check Revision ID */
>> + ret = regmap_read(max98927->regmap,
>> + MAX98927_R01FF_REV_ID, ®);
>> + if (ret < 0) {
>> + dev_err(&i2c->dev,
>> + "Failed to read: 0x%02X\n", MAX98927_R01FF_REV_ID);
>> + return ret;
>> + }
>> + dev_info(&i2c->dev, "MAX98927 revisionID: 0x%02X\n", reg);
>> +
>> + /* voltage/current slot configuration */
>> + max98927_slot_config(i2c, max98927);
>> +
>> + /* codec registeration */
>> + ret = snd_soc_register_codec(&i2c->dev, &soc_codec_dev_max98927,
>> + max98927_dai, ARRAY_SIZE(max98927_dai));
>> + if (ret < 0)
>> + dev_err(&i2c->dev, "Failed to register codec: %d\n", ret);
>> +
>> + return ret;
>> +}
>> +
>> +static int max98927_i2c_remove(struct i2c_client *client)
>> +{
>> + snd_soc_unregister_codec(&client->dev);
>> + return 0;
>> +}
>> +
>> +static const struct i2c_device_id max98927_i2c_id[] = {
>> + { "max98927", 0},
>> + { },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(i2c, max98927_i2c_id);
>> +
>> +#if defined(CONFIG_OF)
>> +static const struct of_device_id max98927_of_match[] = {
>> + { .compatible = "maxim,max98927", },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, max98927_of_match);
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id max98927_acpi_match[] = {
>> + { "MX98927", 0 },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(acpi, max98927_acpi_match);
>> +#endif
>> +
>> +static struct i2c_driver max98927_i2c_driver = {
>> + .driver = {
>> + .name = "max98927",
>> + .of_match_table = of_match_ptr(max98927_of_match),
>> + .acpi_match_table = ACPI_PTR(max98927_acpi_match),
>> + .pm = NULL,
>> + },
>> + .probe = max98927_i2c_probe,
>> + .remove = max98927_i2c_remove,
>> + .id_table = max98927_i2c_id,
>> +};
>> +
>> +module_i2c_driver(max98927_i2c_driver)
>> +
>> +MODULE_DESCRIPTION("ALSA SoC MAX98927 driver");
>> +MODULE_AUTHOR("Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>");
>> +MODULE_LICENSE("GPL");
>> diff --git a/sound/soc/codecs/max98927.h b/sound/soc/codecs/max98927.h
>> new file mode 100644
>> index 000000000000..ece6a608cbe1
>> --- /dev/null
>> +++ b/sound/soc/codecs/max98927.h
>> @@ -0,0 +1,272 @@
>> +/*
>> + * max98927.h -- MAX98927 ALSA Soc Audio driver
>> + *
>> + * Copyright 2013-15 Maxim Integrated Products
>> + * Author: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + *
>> + */
>> +#ifndef _MAX98927_H
>> +#define _MAX98927_H
>> +
>> +/* Register Values */
>> +#define MAX98927_R0001_INT_RAW1 0x0001
>> +#define MAX98927_R0002_INT_RAW2 0x0002
>> +#define MAX98927_R0003_INT_RAW3 0x0003
>> +#define MAX98927_R0004_INT_STATE1 0x0004
>> +#define MAX98927_R0005_INT_STATE2 0x0005
>> +#define MAX98927_R0006_INT_STATE3 0x0006
>> +#define MAX98927_R0007_INT_FLAG1 0x0007
>> +#define MAX98927_R0008_INT_FLAG2 0x0008
>> +#define MAX98927_R0009_INT_FLAG3 0x0009
>> +#define MAX98927_R000A_INT_EN1 0x000A
>> +#define MAX98927_R000B_INT_EN2 0x000B
>> +#define MAX98927_R000C_INT_EN3 0x000C
>> +#define MAX98927_R000D_INT_FLAG_CLR1 0x000D
>> +#define MAX98927_R000E_INT_FLAG_CLR2 0x000E
>> +#define MAX98927_R000F_INT_FLAG_CLR3 0x000F
>> +#define MAX98927_R0010_IRQ_CTRL 0x0010
>> +#define MAX98927_R0011_CLK_MON 0x0011
>> +#define MAX98927_R0012_WDOG_CTRL 0x0012
>> +#define MAX98927_R0013_WDOG_RST 0x0013
>> +#define MAX98927_R0014_MEAS_ADC_THERM_WARN_THRESH 0x0014
>> +#define MAX98927_R0015_MEAS_ADC_THERM_SHDN_THRESH 0x0015
>> +#define MAX98927_R0016_MEAS_ADC_THERM_HYSTERESIS 0x0016
>> +#define MAX98927_R0017_PIN_CFG 0x0017
>> +#define MAX98927_R0018_PCM_RX_EN_A 0x0018
>> +#define MAX98927_R0019_PCM_RX_EN_B 0x0019
>> +#define MAX98927_R001A_PCM_TX_EN_A 0x001A
>> +#define MAX98927_R001B_PCM_TX_EN_B 0x001B
>> +#define MAX98927_R001C_PCM_TX_HIZ_CTRL_A 0x001C
>> +#define MAX98927_R001D_PCM_TX_HIZ_CTRL_B 0x001D
>> +#define MAX98927_R001E_PCM_TX_CH_SRC_A 0x001E
>> +#define MAX98927_R001F_PCM_TX_CH_SRC_B 0x001F
>> +#define MAX98927_R0020_PCM_MODE_CFG 0x0020
>> +#define MAX98927_R0021_PCM_MASTER_MODE 0x0021
>> +#define MAX98927_R0022_PCM_CLK_SETUP 0x0022
>> +#define MAX98927_R0023_PCM_SR_SETUP1 0x0023
>> +#define MAX98927_R0024_PCM_SR_SETUP2 0x0024
>> +#define MAX98927_R0025_PCM_TO_SPK_MONOMIX_A 0x0025
>> +#define MAX98927_R0026_PCM_TO_SPK_MONOMIX_B 0x0026
>> +#define MAX98927_R0027_ICC_RX_EN_A 0x0027
>> +#define MAX98927_R0028_ICC_RX_EN_B 0x0028
>> +#define MAX98927_R002B_ICC_TX_EN_A 0x002B
>> +#define MAX98927_R002C_ICC_TX_EN_B 0x002C
>> +#define MAX98927_R002E_ICC_HIZ_MANUAL_MODE 0x002E
>> +#define MAX98927_R002F_ICC_TX_HIZ_EN_A 0x002F
>> +#define MAX98927_R0030_ICC_TX_HIZ_EN_B 0x0030
>> +#define MAX98927_R0031_ICC_LNK_EN 0x0031
>> +#define MAX98927_R0032_PDM_TX_EN 0x0032
>> +#define MAX98927_R0033_PDM_TX_HIZ_CTRL 0x0033
>> +#define MAX98927_R0034_PDM_TX_CTRL 0x0034
>> +#define MAX98927_R0035_PDM_RX_CTRL 0x0035
>> +#define MAX98927_R0036_AMP_VOL_CTRL 0x0036
>> +#define MAX98927_R0037_AMP_DSP_CFG 0x0037
>> +#define MAX98927_R0038_TONE_GEN_DC_CFG 0x0038
>> +#define MAX98927_R0039_DRE_CTRL 0x0039
>> +#define MAX98927_R003A_AMP_EN 0x003A
>> +#define MAX98927_R003B_SPK_SRC_SEL 0x003B
>> +#define MAX98927_R003C_SPK_GAIN 0x003C
>> +#define MAX98927_R003D_SSM_CFG 0x003D
>> +#define MAX98927_R003E_MEAS_EN 0x003E
>> +#define MAX98927_R003F_MEAS_DSP_CFG 0x003F
>> +#define MAX98927_R0040_BOOST_CTRL0 0x0040
>> +#define MAX98927_R0041_BOOST_CTRL3 0x0041
>> +#define MAX98927_R0042_BOOST_CTRL1 0x0042
>> +#define MAX98927_R0043_MEAS_ADC_CFG 0x0043
>> +#define MAX98927_R0044_MEAS_ADC_BASE_MSB 0x0044
>> +#define MAX98927_R0045_MEAS_ADC_BASE_LSB 0x0045
>> +#define MAX98927_R0046_ADC_CH0_DIVIDE 0x0046
>> +#define MAX98927_R0047_ADC_CH1_DIVIDE 0x0047
>> +#define MAX98927_R0048_ADC_CH2_DIVIDE 0x0048
>> +#define MAX98927_R0049_ADC_CH0_FILT_CFG 0x0049
>> +#define MAX98927_R004A_ADC_CH1_FILT_CFG 0x004A
>> +#define MAX98927_R004B_ADC_CH2_FILT_CFG 0x004B
>> +#define MAX98927_R004C_MEAS_ADC_CH0_READ 0x004C
>> +#define MAX98927_R004D_MEAS_ADC_CH1_READ 0x004D
>> +#define MAX98927_R004E_MEAS_ADC_CH2_READ 0x004E
>> +#define MAX98927_R0051_BROWNOUT_STATUS 0x0051
>> +#define MAX98927_R0052_BROWNOUT_EN 0x0052
>> +#define MAX98927_R0053_BROWNOUT_INFINITE_HOLD 0x0053
>> +#define MAX98927_R0054_BROWNOUT_INFINITE_HOLD_CLR 0x0054
>> +#define MAX98927_R0055_BROWNOUT_LVL_HOLD 0x0055
>> +#define MAX98927_R005A_BROWNOUT_LVL1_THRESH 0x005A
>> +#define MAX98927_R005B_BROWNOUT_LVL2_THRESH 0x005B
>> +#define MAX98927_R005C_BROWNOUT_LVL3_THRESH 0x005C
>> +#define MAX98927_R005D_BROWNOUT_LVL4_THRESH 0x005D
>> +#define MAX98927_R005E_BROWNOUT_THRESH_HYSTERYSIS 0x005E
>> +#define MAX98927_R005F_BROWNOUT_AMP_LIMITER_ATK_REL 0x005F
>> +#define MAX98927_R0060_BROWNOUT_AMP_GAIN_ATK_REL 0x0060
>> +#define MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE 0x0061
>> +#define MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT 0x0072
>> +#define MAX98927_R0073_BROWNOUT_LVL1_AMP1_CTRL1 0x0073
>> +#define MAX98927_R0074_BROWNOUT_LVL1_AMP1_CTRL2 0x0074
>> +#define MAX98927_R0075_BROWNOUT_LVL1_AMP1_CTRL3 0x0075
>> +#define MAX98927_R0076_BROWNOUT_LVL2_CUR_LIMIT 0x0076
>> +#define MAX98927_R0077_BROWNOUT_LVL2_AMP1_CTRL1 0x0077
>> +#define MAX98927_R0078_BROWNOUT_LVL2_AMP1_CTRL2 0x0078
>> +#define MAX98927_R0079_BROWNOUT_LVL2_AMP1_CTRL3 0x0079
>> +#define MAX98927_R007A_BROWNOUT_LVL3_CUR_LIMIT 0x007A
>> +#define MAX98927_R007B_BROWNOUT_LVL3_AMP1_CTRL1 0x007B
>> +#define MAX98927_R007C_BROWNOUT_LVL3_AMP1_CTRL2 0x007C
>> +#define MAX98927_R007D_BROWNOUT_LVL3_AMP1_CTRL3 0x007D
>> +#define MAX98927_R007E_BROWNOUT_LVL4_CUR_LIMIT 0x007E
>> +#define MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1 0x007F
>> +#define MAX98927_R0080_BROWNOUT_LVL4_AMP1_CTRL2 0x0080
>> +#define MAX98927_R0081_BROWNOUT_LVL4_AMP1_CTRL3 0x0081
>> +#define MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM 0x0082
>> +#define MAX98927_R0083_ENV_TRACK_BOOST_VOUT_DELAY 0x0083
>> +#define MAX98927_R0084_ENV_TRACK_REL_RATE 0x0084
>> +#define MAX98927_R0085_ENV_TRACK_HOLD_RATE 0x0085
>> +#define MAX98927_R0086_ENV_TRACK_CTRL 0x0086
>> +#define MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ 0x0087
>> +#define MAX98927_R00FF_GLOBAL_SHDN 0x00FF
>> +#define MAX98927_R0100_SOFT_RESET 0x0100
>> +#define MAX98927_R01FF_REV_ID 0x01FF
>> +
>> +/* MAX98927_R0018_PCM_RX_EN_A */
>> +#define MAX98927_PCM_RX_CH0_EN (0x1 << 0)
>> +#define MAX98927_PCM_RX_CH1_EN (0x1 << 1)
>> +#define MAX98927_PCM_RX_CH2_EN (0x1 << 2)
>> +#define MAX98927_PCM_RX_CH3_EN (0x1 << 3)
>> +#define MAX98927_PCM_RX_CH4_EN (0x1 << 4)
>> +#define MAX98927_PCM_RX_CH5_EN (0x1 << 5)
>> +#define MAX98927_PCM_RX_CH6_EN (0x1 << 6)
>> +#define MAX98927_PCM_RX_CH7_EN (0x1 << 7)
>> +
>> +/* MAX98927_R001A_PCM_TX_EN_A */
>> +#define MAX98927_PCM_TX_CH0_EN (0x1 << 0)
>> +#define MAX98927_PCM_TX_CH1_EN (0x1 << 1)
>> +#define MAX98927_PCM_TX_CH2_EN (0x1 << 2)
>> +#define MAX98927_PCM_TX_CH3_EN (0x1 << 3)
>> +#define MAX98927_PCM_TX_CH4_EN (0x1 << 4)
>> +#define MAX98927_PCM_TX_CH5_EN (0x1 << 5)
>> +#define MAX98927_PCM_TX_CH6_EN (0x1 << 6)
>> +#define MAX98927_PCM_TX_CH7_EN (0x1 << 7)
>> +
>> +/* MAX98927_R001E_PCM_TX_CH_SRC_A */
>> +#define MAX98927_PCM_TX_CH_SRC_A_V_SHIFT (0)
>> +#define MAX98927_PCM_TX_CH_SRC_A_I_SHIFT (4)
>> +
>> +/* MAX98927_R001F_PCM_TX_CH_SRC_B */
>> +#define MAX98927_PCM_TX_CH_INTERLEAVE_MASK (0x1 << 5)
>> +
>> +/* MAX98927_R0020_PCM_MODE_CFG */
>> +#define MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE (0x1 << 2)
>> +#define MAX98927_PCM_MODE_CFG_FORMAT_MASK (0x7 << 3)
>> +#define MAX98927_PCM_MODE_CFG_FORMAT_SHIFT (3)
>> +#define MAX98927_PCM_FORMAT_I2S (0x0 << 0)
>> +#define MAX98927_PCM_FORMAT_LJ (0x1 << 0)
>> +
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_MASK (0x3 << 6)
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_16 (0x1 << 6)
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_24 (0x2 << 6)
>> +#define MAX98927_PCM_MODE_CFG_CHANSZ_32 (0x3 << 6)
>> +
>> +/* MAX98927_R0021_PCM_MASTER_MODE */
>> +#define MAX98927_PCM_MASTER_MODE_MASK (0x3 << 0)
>> +#define MAX98927_PCM_MASTER_MODE_SLAVE (0x0 << 0)
>> +#define MAX98927_PCM_MASTER_MODE_MASTER (0x3 << 0)
>> +
>> +#define MAX98927_PCM_MASTER_MODE_MCLK_MASK (0xF << 2)
>> +#define MAX98927_PCM_MASTER_MODE_MCLK_RATE_SHIFT (2)
>> +
>> +/* MAX98927_R0022_PCM_CLK_SETUP */
>> +#define MAX98927_PCM_CLK_SETUP_BSEL_MASK (0xF << 0)
>> +
>> +/* MAX98927_R0023_PCM_SR_SETUP1 */
>> +#define MAX98927_PCM_SR_SET1_SR_MASK (0xF << 0)
>> +
>> +#define MAX98927_PCM_SR_SET1_SR_8000 (0x0 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_11025 (0x1 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_12000 (0x2 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_16000 (0x3 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_22050 (0x4 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_24000 (0x5 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_32000 (0x6 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_44100 (0x7 << 0)
>> +#define MAX98927_PCM_SR_SET1_SR_48000 (0x8 << 0)
>> +
>> +/* MAX98927_R0024_PCM_SR_SETUP2 */
>> +#define MAX98927_PCM_SR_SET2_SR_MASK (0xF << 4)
>> +#define MAX98927_PCM_SR_SET2_SR_SHIFT (4)
>> +#define MAX98927_PCM_SR_SET2_IVADC_SR_MASK (0xf << 0)
>> +
>> +/* MAX98927_R0025_PCM_TO_SPK_MONOMIX_A */
>> +#define MAX98927_PCM_TO_SPK_MONOMIX_CFG_MASK (0x3 << 6)
>> +#define MAX98927_PCM_TO_SPK_MONOMIX_CFG_SHIFT (6)
>> +
>> +/* MAX98927_R0035_PDM_RX_CTRL */
>> +#define MAX98927_PDM_RX_EN_MASK (0x1 << 0)
>> +
>> +/* MAX98927_R0036_AMP_VOL_CTRL */
>> +#define MAX98927_AMP_VOL_SEL (0x1 << 7)
>> +#define MAX98927_AMP_VOL_SEL_WIDTH (1)
>> +#define MAX98927_AMP_VOL_SEL_SHIFT (7)
>> +#define MAX98927_AMP_VOL_MASK (0x7f << 0)
>> +#define MAX98927_AMP_VOL_WIDTH (7)
>> +#define MAX98927_AMP_VOL_SHIFT (0)
>> +
>> +/* MAX98927_R0037_AMP_DSP_CFG */
>> +#define MAX98927_AMP_DSP_CFG_DCBLK_EN (0x1 << 0)
>> +#define MAX98927_AMP_DSP_CFG_DITH_EN (0x1 << 1)
>> +#define MAX98927_AMP_DSP_CFG_RMP_BYPASS (0x1 << 4)
>> +#define MAX98927_AMP_DSP_CFG_DAC_INV (0x1 << 5)
>> +#define MAX98927_AMP_DSP_CFG_RMP_SHIFT (4)
>> +
>> +/* MAX98927_R0039_DRE_CTRL */
>> +#define MAX98927_DRE_CTRL_DRE_EN (0x1 << 0)
>> +#define MAX98927_DRE_EN_SHIFT 0x1
>> +
>> +/* MAX98927_R003A_AMP_EN */
>> +#define MAX98927_AMP_EN_MASK (0x1 << 0)
>> +
>> +/* MAX98927_R003B_SPK_SRC_SEL */
>> +#define MAX98927_SPK_SRC_MASK (0x3 << 0)
>> +
>> +/* MAX98927_R003C_SPK_GAIN */
>> +#define MAX98927_SPK_PCM_GAIN_MASK (0x7 << 0)
>> +#define MAX98927_SPK_PDM_GAIN_MASK (0x7 << 4)
>> +#define MAX98927_SPK_GAIN_WIDTH (3)
>> +
>> +/* MAX98927_R003E_MEAS_EN */
>> +#define MAX98927_MEAS_V_EN (0x1 << 0)
>> +#define MAX98927_MEAS_I_EN (0x1 << 1)
>> +
>> +/* MAX98927_R0040_BOOST_CTRL0 */
>> +#define MAX98927_BOOST_CTRL0_VOUT_MASK (0x1f << 0)
>> +#define MAX98927_BOOST_CTRL0_PVDD_MASK (0x1 << 7)
>> +#define MAX98927_BOOST_CTRL0_PVDD_EN_SHIFT (7)
>> +
>> +/* MAX98927_R0052_BROWNOUT_EN */
>> +#define MAX98927_BROWNOUT_BDE_EN (0x1 << 0)
>> +#define MAX98927_BROWNOUT_AMP_EN (0x1 << 1)
>> +#define MAX98927_BROWNOUT_DSP_EN (0x1 << 2)
>> +#define MAX98927_BROWNOUT_DSP_SHIFT (2)
>> +
>> +/* MAX98927_R0100_SOFT_RESET */
>> +#define MAX98927_SOFT_RESET (0x1 << 0)
>> +
>> +/* MAX98927_R00FF_GLOBAL_SHDN */
>> +#define MAX98927_GLOBAL_EN_MASK (0x1 << 0)
>> +
>> +struct max98927_priv {
>> + struct regmap *regmap;
>> + struct snd_soc_codec *codec;
>> + struct max98927_pdata *pdata;
>> + unsigned int spk_gain;
>> + unsigned int sysclk;
>> + unsigned int v_l_slot;
>> + unsigned int i_l_slot;
>> + bool interleave_mode;
>> + unsigned int ch_size;
>> + unsigned int rate;
>> + unsigned int iface;
>> + unsigned int master;
>> + unsigned int digital_gain;
>> +};
>> +#endif
>> --
>> 2.11.0
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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