Re: [alsa-devel] [PATCH 2/2] ASoC: simple-card: Add support for samplerate and samplewidth constraints
On 03/03/2015 05:34 PM, Mark Brown wrote: On Tue, Mar 03, 2015 at 02:00:31PM +0200, Jyri Sarha wrote: On 03/03/2015 01:30 PM, Mark Brown wrote: ...this is more the point. Perhaps the constraints language needs improvement here? Improving constraint functionality would certainly help, however the way that code works is beyond my understanding and I do not believe such an improvement would be coming from anybody else any time soon either. It's probably worth putting together a description of the constraint and asking people like Takashi who understand the code - ideally it'd be easy to implement but I suspect you're right about timescales. Now that Lars-Peter pointed me to the right direction, it seems there is a proper way to deal with issue after all. The trouble with this sort of interface is that it's a quick and dirty way for people to bodge around things rather than actually fixing them properly. Of course sometimes fixing things properly is really hard and that means we want a temporary bodge but having to put them in DT is really unfortunate. I agree with that. However, the simple-card binding goes already now quite a bit beyond just describing the hardware. The binding for instance decides the configuration that is going to be used over the dai-link. These constraints could be seen as an extension to that configuration. I am wondering if there would be some better way to select the dai-link configuration than writing it to DT or creating a custom machine driver for each setup. Continuing this tought. I wonder if it would be better to introduce a new compatible match for each new card, with some clever way to manage the accumulating matches in the code, and hard code DAI-link configurations for each match. This way the old configurations would not be carved to stone in the old dtbs. But about this patch. Should I just give it up, or would you be willing to apply it if I improve the description more and add a warning against using these properties to work around driver bugs to the binding document? I'm not totally against the idea so it's worth continuing. Just not happy either but computer. It just occurred to me that we may be able to sidestep the issue by calling them "suggested rates/widths" so the implementation can ignore them later. That's a *tiny* bit gross but does sidestep the ABI issues. As there is a proper way to deal with this, I'll look into that first. However, if there still is a need for these properties I am happy to finish the patch. Best regards, Jyri -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 2/2] ASoC: simple-card: Add support for samplerate and samplewidth constraints
On 03/03/2015 05:31 PM, Lars-Peter Clausen wrote: On 03/03/2015 01:00 PM, Jyri Sarha wrote: On 03/03/2015 01:30 PM, Mark Brown wrote: On Tue, Mar 03, 2015 at 12:09:14PM +0200, Jyri Sarha wrote: On 03/02/2015 09:58 PM, Lars-Peter Clausen wrote: Can you include a description why this is needed and how and when it is supposed to be used? Would this addition do: These constraints help to disable the sample-format and sample-rate combinations that do not properly work on a specific HW. Not entirely... The reason why we need these is coming from limitations in McASP clock generation. With a simple divider one can only produce certain bit-clocks. With those bit-clocks we can only play/capture some sample-rate and sample-width combinations accurately. The McASP driver could try to set the constraints automatically. However, since the constraint code can not select sample-width and sample-rate combinations there is a compromise to be made between them. Making such compromises automatically does not usually work that well. ...this is more the point. Perhaps the constraints language needs improvement here? Improving constraint functionality would certainly help, however the way that code works is beyond my understanding and I do not believe such an improvement would be coming from anybody else any time soon either. Restricting the available sample formats based on the sample rate and vice versa is possible with the current constraint framework. Take a look at what Peter Rosin recently did to the pcm512x driver. Your restrictions sound very similar to what he did. Interesting. It indeed looks like the rule functionality could do what I want. I'll look into than. Thanks! In our case these properties could of course be added to McASP driver, but then again I would expect that there is a wider need for this kind of functionality. And it may not always be clear if either end of the link alone is responsible for less than perfect operation. The trouble with this sort of interface is that it's a quick and dirty way for people to bodge around things rather than actually fixing them properly. Of course sometimes fixing things properly is really hard and that means we want a temporary bodge but having to put them in DT is really unfortunate. I agree with that. However, the simple-card binding goes already now quite a bit beyond just describing the hardware. The binding for instance decides the configuration that is going to be used over the dai-link. These constraints could be seen as an extension to that configuration. I am wondering if there would be some better way to select the dai-link configuration than writing it to DT or creating a custom machine driver for each setup. But about this patch. Should I just give it up, or would you be willing to apply it if I improve the description more and add a warning against using these properties to work around driver bugs to the binding document? Well, your description is basically saying that you want to use this to work around a driver bug, so... Calling missing feature a bug is a bit harsh, but now that it seems there is a better to deal with this, I'll look into that. Best regards, Jyri -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] ARM: shmobile: r8a7790: Fix HSUSB clock to hp_clk from mp_clk
Hi Geert, On Mon, Feb 16, 2015 at 03:04:16PM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > On Mon, Feb 16, 2015 at 2:57 PM, Simon Horman wrote: > > On Mon, Feb 16, 2015 at 10:20:10AM +0100, Geert Uytterhoeven wrote: > >> Hi Kaneko-san, Mizuguchi-san, > >> > >> On Sun, Feb 15, 2015 at 3:49 PM, Yoshihiro Kaneko > >> wrote: > >> > From: Kazuya Mizuguchi > >> > > >> > HSUSB uses hp_clk for H/W register access. > >> > >> That indeed seems to be true, and that's what this patch is changing. > >> > >> > HSUSB uses mp_clk for USB-DMAC access. > >> > >> However, page 64-2 doesn't mention the MP clock for USB-DMAC: > >>"AXI bus clock (ZSφ: 260 MHz), HPB bus clock (HPφ: 130 MHz). > >> USB local bus clock (48 MHz)" > >> So your statement doesn't seem to be true? > > > > Thanks, I see that too. > > > >> Note that mstp3_clks in dtsi has hp_clk as the parent for both usbdmac0 and > >> usbdmac1, so if your statement would be true, that has to changed, too? > >> > >> The same is true for other members of the R-Car Gen2 family, e.g. your > >> patch > >> for r8a7791. > > > > It seems to me that we could: > > > > 1. Apply this patch with the changelog updated and; > > 2. Follow up on the DMAC clocks > > > > Does that sound reasonable to you? > > Yes, that sounds fine to me. The purpose of this email is to offer a quick status update which I hope will bring this matter to a close. I have submitted and queued up a patch as per 1. above. With regards to item 2. above: I have also followed up on the "HSUSB uses mp_clk for USB-DMAC access" comment in the original changelog (above). Mizuguchi-san has confirmed that statement is not correct and its presence in the changelog was an error. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/8] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On 03/02/2015 06:22 AM, Arnd Bergmann wrote: > On Saturday 28 February 2015 09:47:01 Chanwoo Choi wrote: >> "earlycon=exynos4210,0x14C2" is correct bootparam. You can check >> it on Documentation/kernel-parameters.txt as following. >> >> exynos4210, >> Use early console provided by serial driver available >> on Samsung SoCs, requires selecting proper type and >> a correct base address of the selected UART port. The >> serial port must already be setup and configured. >> Options are not yet supported. >> >> > > But it's crazy to do this when you have a DT. Please fix the existing > devicetree files that use this to just list 'earlycon'. > > The syntax above only makes sense for classic board files that we > do not support for exynos any more. Following earlycon patch for exynos soc was merged in Linux 4.0-rc1. - commit-id: b94ba0328d3b36ff95f5074c0e9b44f90dc56bb5 (serial: samsung: Add support for early console) Almost Exynos SoC use the same UART IP of Exynos4210. If you mean that "earlycon=exynos4210" naming will be changed to "earlycon=exynos", we have to modify the drivers/tty/serial/samsung.c. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] i2c: Support for Netlogic XLP9XX/5XX I2C controller.
From: Subhendu Sekhar Behera
Add an I2C bus driver i2c-xlp9xx.c to support the I2C block in the
XLP9xx/XLP5xx MIPS SoC. Update Kconfig and Makefile to add the
CONFIG_I2C_XLP9XX option.
Also add document Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
for DT compatible string "netlogic,xlp9xx-i2c".
Signed-off-by: Subhendu Sekhar Behera
Signed-off-by: Jayachandran C
---
.../devicetree/bindings/i2c/i2c-xlp9xx.txt | 22 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-xlp9xx.c| 446 +
4 files changed, 479 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
create mode 100644 drivers/i2c/busses/i2c-xlp9xx.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
b/Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
new file mode 100644
index ..f23ae87
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
@@ -0,0 +1,22 @@
+Device tree configuration for the I2C controller on the XLP9xx/5xx SoC
+
+Required properties:
+- compatible : should be "netlogic,xlp9xx-i2c"
+- reg : bus address start and address range size of device
+- interrupts : interrupt number
+
+Optional properties:
+- clock-frequency : frequency of bus clock in Hz
+Defaults to 100 KHz when the property is not specified
+
+Example:
+
+i2c0: i2c@113100 {
+ compatible = "netlogic,xlp9xx-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x113100 0x100>;
+ clock-frequency = <40>;
+ interrupts = <30>;
+ interrupt-parent = <&pic>;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2..dde4648 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -898,6 +898,16 @@ config I2C_XLR
This driver can also be built as a module. If so, the module
will be called i2c-xlr.
+config I2C_XLP9XX
+ tristate "XLP9XX I2C support"
+ depends on CPU_XLP || COMPILE_TEST
+ help
+ This driver enables support for the on-chip I2C interface of
+ the Broadcom XLP9xx/XLP5xx MIPS processors.
+
+ This driver can also be built as a module. If so, the module will
+ be called i2c-xlp9xx.
+
config I2C_RCAR
tristate "Renesas R-Car I2C Controller"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3638feb..f8e0f0e 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_I2C_WMT) += i2c-wmt.o
obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o
obj-$(CONFIG_I2C_XILINX) += i2c-xiic.o
obj-$(CONFIG_I2C_XLR) += i2c-xlr.o
+obj-$(CONFIG_I2C_XLP9XX) += i2c-xlp9xx.o
obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
# External I2C/SMBus adapter drivers
diff --git a/drivers/i2c/busses/i2c-xlp9xx.c b/drivers/i2c/busses/i2c-xlp9xx.c
new file mode 100644
index ..6886add
--- /dev/null
+++ b/drivers/i2c/busses/i2c-xlp9xx.c
@@ -0,0 +1,446 @@
+/*
+ * Copyright (c) 2003-2015 Broadcom Corporation
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define XLP9XX_I2C_DIV 0x0
+#define XLP9XX_I2C_CTRL0x1
+#define XLP9XX_I2C_CMD 0x2
+#define XLP9XX_I2C_STATUS 0x3
+#define XLP9XX_I2C_MTXFIFO 0x4
+#define XLP9XX_I2C_MRXFIFO 0x5
+#define XLP9XX_I2C_MFIFOCTRL 0x6
+#define XLP9XX_I2C_STXFIFO 0x7
+#define XLP9XX_I2C_SRXFIFO 0x8
+#define XLP9XX_I2C_SFIFOCTRL 0x9
+#define XLP9XX_I2C_SLAVEADDR 0xA
+#define XLP9XX_I2C_OWNADDR 0xB
+#define XLP9XX_I2C_FIFOWCNT0xC
+#define XLP9XX_I2C_INTEN 0xD
+#define XLP9XX_I2C_INTST 0xE
+#define XLP9XX_I2C_WAITCNT 0xF
+#define XLP9XX_I2C_TIMEOUT 0X10
+#define XLP9XX_I2C_GENCALLADDR 0x11
+
+#define XLP9XX_I2C_CTRL_MCTLEN_SHIFT 16
+#define XLP9XX_I2C_MFIFOCTRL_HITH_SHIFT8
+#define XLP9XX_I2C_MFIFOCTRL_LOTH_SHIFT0
+#define XLP9XX_I2C_SLAVEADDR_ADDR_SHIFT1
+
+#define XLP9XX_I2C_CMD_START BIT(7)
+#define XLP9XX_I2C_CMD_STOPBIT(6)
+#define XLP9XX_I2C_CMD_READBIT(5)
+#define XLP9XX_I2C_CMD_WRITE BIT(4)
+#define XLP9XX_I2C_CMD_ACK BIT(3)
+
+#define XLP9XX_I2C_CTRL_RSTBIT(8)
+#define XLP9XX_I2C_CTRL_EN BIT(6)
+#define XLP9XX_I2C_CTRL_MASTER BIT(4)
[PATCH v2 0/2] i2c: Support for Netlogic XLP9XX/5XX I2C controller.
Here is an updated version of the i2c controller driver on Broadcom XLP9xx MIPS SoC. We have taken care of the review comments for v1, and have made some additional fixes while going thru the process. The Changelog is below. Please let me know if there are any comments or suggestions. Thanks, JC. Changes v1->v2: * Implement changes from Ray Jui's review - Support for 0 length transfers - remove .owner assignment in platform_driver and .data assignment in of_device_id table - add synchronize_irq and disable interrupt in .remove - Move most prints to dev_dbg - add COMPILE_TEST - align wrapped line in function definitions - IRQ_NONE return if interrupt is not ours. - error check frequency setting in DTB - fix check of return of devm_ioremap_resource() and remove unnecessary prints - fix incorrect irq check - include file ordering fixed - few unneeded variables taken out - use u32 consistently for unsigned 32 bit int - add comment for prescale value calculation * Change clock-frequency parameter to take the bus frequency as expected in i2c subsystem * Rearrage register definitions to group them better * Add I2C_FUNC_10BIT_ADDR to xlp9xx_i2c_functionality() * use reinit_completion before each transfer * use i2c_add_adapter instead of doing i2c_add_numbered_adapter Subhendu Sekhar Behera (2): of: Add vendor prefix 'netlogic' i2c: Support for Netlogic XLP9XX/5XX I2C controller. .../devicetree/bindings/i2c/i2c-xlp9xx.txt | 19 + .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-xlp9xx.c| 446 + 5 files changed, 477 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt create mode 100644 drivers/i2c/busses/i2c-xlp9xx.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] of: Add vendor prefix 'netlogic'
From: Subhendu Sekhar Behera Add vendor name "netlogic" in vendor-prefixes.txt, which will be used for the Netlogic XLP and XLPII MIPS SoCs. These processors were from NetLogic Microsystems which is now part of Broadcom Corporation. Signed-off-by: Subhendu Sekhar Behera Signed-off-by: Jayachandran C --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..a718eb1 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -123,6 +123,7 @@ mxicy Macronix International Co., Ltd. national National Semiconductor neonodeNeonode Inc. netgearNETGEAR +netlogic Broadcom Corporation (formerly NetLogic Microsystems) newhaven Newhaven Display International nintendo Nintendo nokia Nokia -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of: Kconfig: Let OF_UNITTEST depend on "I2C=y" and "I2C_MUX=y"
They need several symbols which are in I2C and I2C_MUX, the related error: drivers/built-in.o: In function `selftest_i2c_mux_remove': unittest.c:(.text+0xb0ce4): undefined reference to `i2c_del_mux_adapter' unittest.c:(.text+0xb0ce8): undefined reference to `i2c_del_mux_adapter' drivers/built-in.o: In function `selftest_i2c_mux_probe': unittest.c:(.text+0xb0f20): undefined reference to `i2c_add_mux_adapter' unittest.c:(.text+0xb0f24): undefined reference to `i2c_add_mux_adapter' unittest.c:(.text+0xb0f94): undefined reference to `i2c_del_mux_adapter' unittest.c:(.text+0xb0f9c): undefined reference to `i2c_del_mux_adapter' drivers/built-in.o: In function `selftest_i2c_bus_remove': unittest.c:(.text+0xb10cc): undefined reference to `i2c_del_adapter' unittest.c:(.text+0xb10d4): undefined reference to `i2c_del_adapter' drivers/built-in.o: In function `selftest_i2c_bus_probe': unittest.c:(.text+0xb1298): undefined reference to `i2c_add_numbered_adapter' unittest.c:(.text+0xb12a0): undefined reference to `i2c_add_numbered_adapter' drivers/built-in.o: In function `of_selftest_overlay': unittest.c:(.init.text+0xc9d0): undefined reference to `i2c_register_driver' unittest.c:(.init.text+0xc9dc): undefined reference to `i2c_register_driver' unittest.c:(.init.text+0xcdb4): undefined reference to `i2c_del_driver' unittest.c:(.init.text+0xcdb8): undefined reference to `i2c_del_driver' drivers/built-in.o: In function `of_selftest_device_exists': unittest.c:(.text.unlikely+0xd70): undefined reference to `of_find_i2c_device_by_node' unittest.c:(.text.unlikely+0xd7c): undefined reference to `of_find_i2c_device_by_node' make: *** [vmlinux] Error 1 Signed-off-by: Chen Gang --- drivers/of/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig index 7bcaeec..b60fc66 100644 --- a/drivers/of/Kconfig +++ b/drivers/of/Kconfig @@ -9,7 +9,7 @@ menu "Device Tree and Open Firmware support" config OF_UNITTEST bool "Device Tree runtime unit tests" - depends on OF_IRQ && OF_EARLY_FLATTREE + depends on OF_IRQ && OF_EARLY_FLATTREE && I2C=y && I2C_MUX=y select OF_RESOLVE help This option builds in test cases for the device tree infrastructure -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
On Mon, 2015-03-02 at 09:42 -0600, Emil Medve wrote: > On 03/02/2015 09:32 AM, Emil Medve wrote: > > From: Igal Liberman > > > > Describe the PHY topology for all configurations supported by each board > > > > Based on prior work by Andy Fleming > > > > Change-Id: I4fbcc5df9ee7c4f784afae9dab5d1e78cdc24f0f > > Bah, I'll remove this... Something like: $ cat .git/hooks/commit-msg #!/bin/sh grep "Change-Id:" $1 > /dev/null if [ $? -eq 0 ]; then echo "***: Error commit message includes Change-Id" >&2 exit 1 fi Ought to do it. cheers -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] ARM: bcm2835: Add the mailbox property channel driver.
On 03/02/2015 01:54 PM, Eric Anholt wrote:
> Many of the operations with the firmware are done through this mailbox
> channel pair with a specific packet format. Notably, it's used for
> clock control, which is apparently not actually totally possible to do
> from the ARM side (some regs aren't addressable). I need clock
> control for the VC4 DRM driver, to turn on the 3D engine.
> diff --git a/drivers/mailbox/bcm2835-mailbox-property.c
> b/drivers/mailbox/bcm2835-mailbox-property.c
> +int bcm_mbox_property(void *data, size_t tag_size)
> + buf = dma_alloc_coherent(NULL, PAGE_ALIGN(size), &bus_addr, GFP_ATOMIC);
> + if (!buf)
> + return -ENOMEM;
Can't the driver (this one or the client) maintain some persistent
buffer rather than allocating/freeing a new one each time. It seems like
the alloc/free might introduce quite some overhead?
> + writel(size, buf);
> + writel(bcm_mbox_status_request, buf + 4);
> + memcpy_toio(buf + 8, data, tag_size);
> + writel(bcm_mbox_property_end, buf + size - 4);
Since this is just a regular chunk of RAM, can't the code just use
regular memory writes and memcpy()?
> +static int bcm2835_mbox_property_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + int ret = 0;
> +
> + mbox_property = devm_kzalloc(dev, sizeof(*mbox_property),
> +GFP_KERNEL);
> + if (!mbox_property) {
> + dev_err(dev, "Failed to allocate device memory\n");
Duplicate error message.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] dt/bindings: Add binding for BCM2835 mailbox property channel driver
On 03/02/2015 01:54 PM, Eric Anholt wrote: > I was tempted to have the mailbox property channel support just be in > the 2835 mailbox driver itself, but mbox_request_channel() wants its > device to have the "mboxes" node, and that appears to be only intended > for mailbox clients, not controllers. This is more of a particular format/protocol of messages you can send over the mailbox HW than a device. I wonder if it actually makes sense to represent it in DT as a device at all? If we do represent this as a device in DT, shouldn't it also look like a mailbox device so that other drivers (clock, display, ...) can bind to it and send messages using the mailbox API? I might have expected to just add property support directly into the basic bcm2835 mailbox driver itself. Perhaps some attempt might be made to isolate the HW register level access in one file/driver, and expose both the regular and property mailbox protocols as a higher level that uses the low-level mailbox functionality? The concept of the lower 4 bits of mailbox data being a channel ID might belong in the higher protocol level rather than the lower HW layer? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: pxa: documentation: trivial: fix typo
fix typo in the document. Signed-off-by: Josh Wu --- Documentation/devicetree/bindings/gpio/mrvl-gpio.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt index b2afdb2..77d0dd0 100644 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt @@ -12,7 +12,7 @@ Required properties: gpio_mux. - interrupt-names : Should be the names of irq resources. Each interrupt uses its own interrupt name, so there should be as many interrupt names - as referenced interrups. + as referenced interrupts. - interrupt-controller : Identifies the node as an interrupt controller. - #interrupt-cells: Specifies the number of cells needed to encode an interrupt source. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10 v2] usb: Make sure that DWC2 initializes after the power channel mailbox driver.
On 03/03/2015 01:32 PM, Eric Anholt wrote:
> This gets USB working on the Raspberry Pi without relying on U-Boot to
> send the power message for us. Without it, you would get warnings
> about fifo sizes and "dwc2_core_reset() HANG! Soft Reset
> GRSTCTL=8001" leading to a failed probe.
>
> v2: Make the export of the has-the-mailbox-driver-loaded bool be
> through a function call defined in include/linux/platform/
>
> Signed-off-by: Eric Anholt
> Cc: John Youn
> ---
>
> This would be the first include file in include/linux/platform/. Is
> that the right place? I see a few
> arch/arm/mach-*/include/mach/platform.h files -- would that or
> arch/arm/mach-bcm/include/mach/bcm2835-platform.h possibly be the right
> place instead?
include/linux/soc might be better?
Even better would be to make this work through a standard kernel
subsystem API. Then, dwc2's probe would do something like:
// probe:
pd = power_domain_get(&pdev->dev, "power-domain");
if (IS_ERR(pd))
return PTR_ERR(pd);
// perhaps in probe, or in PM callbacks, etc.
ret = power_domain_on(pd);
That hypothetical function will go out to DT, find the power-domain
property, look at the DT phandle in the property's value, search for a
power domain provider that was instantiated from the DT node the phandle
points at, and obtain a handle to it.
The benefits of this approach are:
a) Uses a standard API rather than something custom.
b) power_domain_get() will return ERR_PTR(-EPROBE_DEFERRED) if the
"power domain provider (driver) instantiated from the DT node the
phandle points at" has not yet probed. In turn this will prevent DWC2
from probing until the power domain can be turned on. The driver core
will call DWC2's probe over and over until it returns something other
than -EPROBE_DEFERRED (i.e. success, or some other failure).
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> @@ -175,6 +176,13 @@ static int dwc2_driver_probe(struct platform_device *dev)
> defparams.dma_desc_enable = 0;
> }
>
> + /*
> + * Make sure the platform driver for enabling the power has
> + * initialized before we do.
> + */
> + if (params == ¶ms_bcm2835 && !bcm2835_is_usb_powered())
> + return -EPROBE_DEFER;
This should be something more like:
if dt_property_exists("power-domain") {
// The power_domain_get code I wrote above
}
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] usb: Make sure that DWC2 initializes after the power channel mailbox driver.
On 03/03/2015 01:32 AM, Lee Jones wrote:
> On Mon, 02 Mar 2015, Eric Anholt wrote:
>> This gets USB working on the Raspberry Pi without relying on U-Boot to
>> send the power message for us. Without it, you would get warnings
>> about fifo sizes and "dwc2_core_reset() HANG! Soft Reset
>> GRSTCTL=8001" leading to a failed probe.
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> +bool bcm2835_usb_power_enabled(void)
>> +{
>> +#ifdef CONFIG_BCM2835_MBOX
>
> Please don't put #ifdeffery in *.c files. If you have to match on
> CONFIG_* options, please do so using inlines in a header file
> somewhere.
I haven't heard of that restriction before. I'm sure there are many
ifdefs in C files in the kernel. What benefit does moving the ifdefs
into headers have?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] ARM: bcm2835: Add the mailbox power channel driver.
On 03/02/2015 01:54 PM, Eric Anholt wrote:
> This just enables the power to the USB controller, so that DWC2 can
> initialize.
>
> The downstream tree has an interface to this channel for tracking
> enables from multiple clients, except it doesn't have any clients as
> far as I can see. For now, just make the simplest thing that gets USB
> working.
> drivers/mailbox/Makefile| 1 +
> drivers/mailbox/bcm2835-mailbox-power.c | 127
>
Along the lines of my comments on the previous patch, I would expect
this driver to show up within the directory for the subsystem/API that
it implements (power domains, regulators?)
> diff --git a/drivers/mailbox/bcm2835-mailbox-power.c
> b/drivers/mailbox/bcm2835-mailbox-power.c
> +#define BCM_POWER_USB (1 << 3)
I'd expect that to be encoded in DT, in the manner I mentioned in reply
to patch 4, so that this driver can work for arbitrary clients.
> +#define BCM_MBOX_DATA_SHIFT 4
I'd expect that to be defined in some public header that's part of patch
2, so that clients don't have to duplicate the definition.
> +/*
> + * Submits a set of concatenated tags to the VPU firmware through the
> + * mailbox power interface.
> + *
> + * The buffer header and the ending tag are added by this function and
> + * don't need to be supplied, just the actual tags for your operation.
> + * See struct bcm_mbox_power_tag_header for the per-tag structure.
> + */
> +static int bcm_mbox_set_power(uint32_t power_enables)
> +{
> + int ret;
> +
> + reinit_completion(&mbox_power->c);
> + ret = mbox_send_message(mbox_power->chan,
> + (void *)(power_enables << BCM_MBOX_DATA_SHIFT));
> + if (ret >= 0)
> + wait_for_completion(&mbox_power->c);
> +
> + return ret;
> +}
The comment sounds more like the property mailbox interface/channel,
whereas the code appears to be using the non-property channel. In
particular, the code only appears to be sending one "tag"/message,
without the header or ending tag mentioned in the comment.
> +static int bcm2835_mbox_power_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + int ret = 0;
> +
> + mbox_power = devm_kzalloc(dev, sizeof(*mbox_power),
> +GFP_KERNEL);
> + if (!mbox_power) {
> + dev_err(dev, "Failed to allocate device memory\n");
Duplicate error message.
> + /* Enable power to the USB phy. */
> + if (IS_ENABLED(CONFIG_USB_DWC2)) {
> + bcm_mbox_set_power(BCM_POWER_USB);
> + bcm2835_mbox_power_initialized = true;
> + }
Hmm. Shouldn't the DWC2 driver make a call to do that?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] dt/bindings: Add binding for BCM2835 mailbox power channel driver
On 03/02/2015 01:54 PM, Eric Anholt wrote:
> I was tempted to have the mailbox power channel support just be in the
> 2835 mailbox driver itself, but mbox_request_channel() wants its
> device to have the "mboxes" node, and that appears to be only intended
> for mailbox clients, not controllers.
> diff --git
> a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox-power.txt
> b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox-power.txt
> +Broadcom BCM2835 VideoCore mailbox power channel IPC
> +
> +Required properties:
> +
> +- compatible : Should be "brcm,bcm2835-mbox-power"
> +- mboxes: Single-entry list which specifies which mailbox controller
> + and channel is the power channel.
> +
> +Example:
> +
> +mailbox-power {
> + compatible = "brcm,bcm2835-mbox-power";
> + mboxes = <&mailbox 0>
> +};
I think the driver for this device should provide its services to other
drivers using some standard in-kernel API (power domains, regulators?),
which in turn would presumably have some subsystem-level DT binding.
So, I would expect this DT node to implement the server-side of that
binding, and probably have a property like "#power-domain-cells = <1>",
and the client nodes to "consume" this service via a property like
"power-domain = <&mbox_power N>" where N is the ID of the client's power
domain within the firmware protocol.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] mailbox: Enable BCM2835 mailbox support
On 03/02/2015 01:54 PM, Eric Anholt wrote:
> From: Lubomir Rintel
>
> Implement BCM2835 mailbox support as a device registered with the
> general purpose mailbox framework. Implementation based on commits by
> Lubomir Rintel [1], Suman Anna and Jassi Brar [2] on which to base the
> implementation.
> diff --git a/drivers/mailbox/bcm2835-mailbox.c
> b/drivers/mailbox/bcm2835-mailbox.c
> +/* Mailboxes */
> +#define ARM_0_MAIL0 0x00
> +#define ARM_0_MAIL1 0x20
> +
> +/*
> + * Mailbox registers. We basically only support mailbox 0 & 1. We
> + * deliver to the VC in mailbox 1, it delivers to us in mailbox 0. See
> + * BCM2835-ARM-Peripherals.pdf section 1.3 for an explanation about
> + * the placement of memory barriers.
> + */
> +#define MAIL0_RD (ARM_0_MAIL0 + 0x00)
> +#define MAIL0_POL(ARM_0_MAIL0 + 0x10)
> +#define MAIL0_STA(ARM_0_MAIL0 + 0x18)
> +#define MAIL0_CNF(ARM_0_MAIL0 + 0x1C)
> +#define MAIL1_WRT(ARM_0_MAIL1 + 0x00)
That implies there are more mailboxes. I wonder if we should
parameterize which to use via some DT properties? I guess we can defer
that though; we can default to the current values and add properties
later if we want to use something else.
> +static irqreturn_t bcm2835_mbox_irq(int irq, void *dev_id)
> +{
> + struct bcm2835_mbox *mbox = (struct bcm2835_mbox *) dev_id;
> + struct device *dev = mbox->dev;
> +
> + while (!(readl(mbox->regs + MAIL0_STA) & ARM_MS_EMPTY)) {
> + u32 msg = readl(mbox->regs + MAIL0_RD);
> + unsigned int chan = MBOX_CHAN(msg);
> +
> + if (!mbox->channel[chan].started) {
> + dev_err(dev, "Reply on stopped channel %d\n", chan);
> + continue;
> + }
> + dev_dbg(dev, "Reply 0x%08X\n", msg);
> + mbox_chan_received_data(mbox->channel[chan].link,
> + (void *) MBOX_DATA28(msg));
> + }
> + rmb(); /* Finished last mailbox read. */
I know the PDF mentioned in the comment earlier in the patch says to put
in barriers between accesses to different peripherals, which this seems
compliant with, but I don't see quite what this barrier achieves. I
think the PDF is talking generalities, not imposing a rule that must be
blindly followed. Besides, if there's a context-switch you can't
actually implement the rules the PDF suggests. What read operation is
this barrier attempting to ensure happens after reading all mailbox
messages and any associated DRAM buffer?
If any barrier is needed, shouldn't it be between the mailbox read and
the processing of that message (which could at least in some cases read
an SDRAM buffer). So, the producer would do roughly:
p1) Fill in DRAM buffer
p2) Write memory barrier so the MBOX write happens after the above
p3) Send mbox message to tell the consumer to process the buffer
... and the consumer:
c1) Read MBOX register to know which DRAM buffer to handle
c2) rmb() to make sure we read from the DRAM buffer after the MBOX read
c3) Read the DRAM buffer
Even then, since (c3) is data-dependent on (c1), I don't think the rmb()
in (c2) there actually does anything useful.
> +static int bcm2835_send_data(struct mbox_chan *link, void *data)
> +{
> + struct bcm2835_channel *chan = to_channel(link);
> + struct bcm2835_mbox *mbox = chan->mbox;
> + int ret = 0;
> +
> + if (!chan->started)
> + return -ENODEV;
> + spin_lock(&mbox->lock);
Is it safe to read chan->started without the channel lock held?
> + if (readl(mbox->regs + MAIL0_STA) & ARM_MS_FULL) {
> + rmb(); /* Finished last mailbox read. */
This also doesn't seem useful?
> + ret = -EBUSY;
> + goto end;
> + }
> + wmb(); /* About to write to the mail box. */
> + writel(MBOX_MSG(chan->chan_num, (u32) data), mbox->regs + MAIL1_WRT);
This one I agree with, at least if MBOX messages contain pointers to
DRAM buffers.
> +static int bcm2835_startup(struct mbox_chan *link)
> +{
> + struct bcm2835_channel *chan = to_channel(link);
> +
> + chan->started = true;
> + return 0;
> +}
> +
> +static void bcm2835_shutdown(struct mbox_chan *link)
> +{
> + struct bcm2835_channel *chan = to_channel(link);
> +
> + chan->started = false;
> +}
Don't we need to hold chan->lock when adjusting chan->started? Or is
start/stop intended to be asynchronous to any operations currently in
progress on the channel?
> +static bool bcm2835_last_tx_done(struct mbox_chan *link)
> +{
> + struct bcm2835_channel *chan = to_channel(link);
> + struct bcm2835_mbox *mbox = chan->mbox;
> + bool ret;
> +
> + if (!chan->started)
> + return false;
> + spin_lock(&mbox->lock);
> + ret = !(readl(mbox->regs + MAIL0_STA) & ARM_MS_FULL);
> + rmb(); /* Finished last mailbox read. */
That barrier doesn't seem useful?
What are the semantics of "tx done"? This seems to be testing that the
TX mailbox isn't completely full, which is more
[PATCH v4 2/2] ARM: at91: dts: sama5d4: add dts for sama5d4 xplained board
Add at91 sama5d4 xplained board support.
Signed-off-by: Josh Wu
---
Changes in v4:
- Thanks to Bo Shen to find following leds issues:
1. the leds' label is changed in new xplained board.
2. as piod bank is disabled in sama5d4, that will whole led driver
not work. So just disable the led which used piod.
Changes in v3:
- add phy0 child node under macb0
- rebase on top of linux next, re-formated the arch/arm/boot/dts/Makefile
Changes in v2:
- to be sorted by memory address, put the adc dt node after usart4.
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 239
2 files changed, 241 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/at91-sama5d4_xplained.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..5c189a5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -42,7 +42,8 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
sama5d34ek.dtb \
sama5d35ek.dtb \
sama5d36ek.dtb \
- at91-sama5d4ek.dtb
+ at91-sama5d4ek.dtb \
+ at91-sama5d4_xplained.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += \
atlas6-evb.dtb
dtb-$(CONFIG_ARCH_ATLAS7) += \
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
new file mode 100644
index 000..af8f4f5
--- /dev/null
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -0,0 +1,239 @@
+/*
+ * at91-sama5d4_xplained.dts - Device Tree file for SAMA5D4 Xplained board
+ *
+ * Copyright (C) 2015 Atmel,
+ *2015 Josh Wu
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+#include "sama5d4.dtsi"
+
+/ {
+ model = "Atmel SAMA5D4 Xplained";
+ compatible = "atmel,sama5d4-xplained", "atmel,sama5d4", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 ignore_loglevel earlyprintk";
+ };
+
+ memory {
+ reg = <0x2000 0x2000>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ main_clock: clock@0 {
+ compatible = "atmel,osc", "fixed-clock";
+ clock-frequency = <1200>;
+ };
+
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <1200>;
+ };
+ };
+
+ ahb {
+ apb {
+ spi0: spi@f801 {
+ cs-gpios = <&pioC 3 0>, <0>, <0>, <0>;
+ status = "okay";
+ m25p80@0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+ };
+ };
+
+ macb0: ethernet@f8020
[PATCH v4 1/2] ARM: at91: sama5d4/dts: add #{address, size}_cells properties for macb0
macb0 DT node can have phy child nodes, so add the #{address,
size}_cells for macb0 node.
Signed-off-by: Josh Wu
---
Changes in v4:
- fix typo in commit message: cell -> cells
Changes in v3:
- new added
Changes in v2: None
arch/arm/boot/dts/sama5d4.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index d986b41..07953f2 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -852,6 +852,8 @@
interrupts = <54 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_macb0_rmii>;
+ #address-cells = <1>;
+ #size-cells = <0>;
clocks = <&macb0_clk>, <&macb0_clk>;
clock-names = "hclk", "pclk";
status = "disabled";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] dt/bindings: Add binding for BCM2835 mailbox driver
On 03/03/2015 12:28 PM, Eric Anholt wrote:
> Lee Jones writes:
>
>> On Mon, 02 Mar 2015, Eric Anholt wrote:
>>
>>> From: Lubomir Rintel
>>>
>>> v2: Split into a separate patch for submitting to the
>>> devicetree list.
...
>>> ---
Generally, the changelog should go below the --- since most people
don't want to see the changelog committed into the source.
>>> .../devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt | 19
>>> +++ 1 file changed, 19 insertions(+) create
>>> mode 100644
>>> Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>>>
>>>
>>>
>>>
diff --git
a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>>> new file mode 100644 index 000..f5741a0 --- /dev/null +++
>>> b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>>
>>
>>>
>>>
Rename these files to conform to the current naming convention. In
>> -next we currently have 'altera-mailbox.txt' and
>> 'omap-mailbox.txt', so 'bcm2835-mbox.txt' seems appropriate.
>
> Will do.
I believe all the current bcm2835 bindings use the compatible value as
the filename. I personally prefer this to picking a different "random"
name for the filenames. It means you only have to name the thing once,
and then use the same value for the compatible property and binding
document.
>>> +Example: + +mailbox: mailbox@7e00b800 { + compatible =
>>> "brcm,bcm2835-mbox"; + reg = <0x7e00b880 0x40>; + interrupts =
>>> <0 1>; +#mbox-cells = <1>; +};
>>
>> It would be good to see the client examples here as well.
>> Please consider pulling in brcm,bcm2835-mbox-power.txt and
>> brcm,bcm2835-mbox-property.txt.
>
> Oh, so have those two just smashed into this file as one set of
> documentation for everything to do with mailbox on bcm2835? That
> seems good to me. When I was adding the client drivers, the fact
> that the other brcm file was named after the compatible string
> made me generate new files under then new compatible strings, but
> the other drivers already in the tree obviously aren't formatted
> that way.
The HW mailbox seems like a different process to the upper-layer
protocols/message formats running over the top of it. Sure right now
the Pi has a single firmware, but do all bcm2835-based devices share
the same firmware? Is so, we'd be warranted in lumping the HW and
firmware protocol together, but I rather wonder whether e.g. the
bcm2835-based Roku uses the same firmware protocol?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm64: mediatek: Add config option for mt8173.
On Wed, 2015-02-25 at 11:11 +, Catalin Marinas wrote: > On Wed, Feb 25, 2015 at 11:51:57AM +0100, Arnd Bergmann wrote: > > On Wednesday 25 February 2015 17:07:22 Yingjoe Chen wrote: > > > On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote: > > > > From: Hongzhou Yang > > > > > > > > The upcoming MTK pinctrl driver have a big pin table for each SoC, > > > > and we don't want to bloat the kernel binary if we don't need it. > > > > Add config options so we can build for one SoC only. > > > > > > > > Signed-off-by: Hongzhou Yang > > > > --- > > > > arch/arm64/Kconfig | 6 ++ > > > > 1 file changed, 6 insertions(+) > > > > > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > > > index e627ead..6213dac 100644 > > > > --- a/arch/arm64/Kconfig > > > > +++ b/arch/arm64/Kconfig > > > > @@ -151,9 +151,15 @@ menu "Platform selection" > > > > config ARCH_MEDIATEK > > > > bool "Mediatek MT65xx & MT81xx ARMv8 SoC" > > > > select ARM_GIC > > > > + select PINCTRL > > > > help > > > > Support for Mediatek MT65xx & MT81xx ARMv8 SoCs > > > > > > > > +config MACH_MT8173 > > > > + bool "Mediatek 8173 Soc Supprt" > > > > + depends on ARCH_MEDIATEK > > > > + default y > > > > + > > > > config ARCH_SEATTLE > > > > bool "AMD Seattle SoC Family" > > > > help > > > > > > Hi Arnd/Matthias, > > > > > > Any comments on this patch? > > > > Hi Joe, > > > > Actually I just commented on a similar patch from Samsung the other > > day, and I think we should make a more general decision about these: > > > > I would rather see only one Kconfig option per SoC family and use > > ARCH_MEDIATEK without any MACH_* options. We can have other options > > for e.g. networking chips from Mediatek that are not closely related > > but I would group all the phone and tablet chips under one option > > here. Same for the other vendors of course. > > I agree. > Hi, Since we support devicetree, we don't need MACH_* to build a working kernel. This is true even for our v7 soc. We intend to use it to reduce numbers of drivers in product kernel binary. Most drivers are shared among the same SoCs family, but some are not. Currently for pinctrl driver, we are doing this so user don't need to select them one by one: config PINCTRL_MT8173 def_bool MACH_MT8173 select PINCTRL_MTK_COMMON Alternatively, we could add these MACH_* to some other places, eg, drivers/soc/mediatek. Or we don't add MACH_* at all, and have all drivers export their own Kconfig option. User will need to select each of them one-by-one. What do you think? Joe.C -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: imx: Add dr_mode host setting to all host-only usb instances
On Tue, Mar 03, 2015 at 10:08:09AM -0500, Matt Porter wrote: > On Tue, Mar 03, 2015 at 12:43:36PM +0800, Peter Chen wrote: > > On Tue, Mar 03, 2015 at 11:41:35AM +0800, Shawn Guo wrote: > > > > > > On Fri, Feb 27, 2015 at 09:06:00AM -0500, Matt Porter wrote: > > > > The chipidea driver adds an extra line of spam to the log when a > > > > host-only chipidea instance is left set to the default of a dual role > > > > controller. > > > > > > > > [2.010873] ci_hdrc ci_hdrc.1: doesn't support gadget > > > > > > > > Set the dr_mode property to host on all the host-only nodes > > > > to avoid this warning. > > > > It is not an warning, it is dev_info. > > True enough, it's info level but is essentially warning that, in the > case of instances that are restricted to host only (at the SoC level), > that the DT hardware description is incorrect. Yes, it's benign, but > if the dtsi is corrected for those parts we don't have to see that > message. You are right. > > > In fact, imx28, imx6sl and imx6sx's second controller is dual-role > > controller, we only set dr_mode at board's dts according to design > > unless the controller's capability register is incorrect. > > The patch doesn't set dr_mode to host on the second controller for > the imx6sl or imx6sx, only on the third host-only controller. If > imx28's second controller is really dual-role capable then the > reference manual is incorrect and I can drop that hunk in v2. > I only have imx6q and imx6d parts in hand to verify so for the rest > I went by the RM claim of which controllers were host-only. Maybe IC guys don't want to export that imx28's that capabilities, so don't need to change. > > > So, sorry, I don't think this change is necessary. > > I can correct the set of instances that should have dr_mode set to host > in v2 of this. We clearly have some that should have this set in their > SoC .dtsi to have the hardware description correct. Will that work for > you or do you want the SoC-specific cases of this property to be only > reflected in the board level dts? > After thinking more, it is a benefit fix, and doesn't need to do any changes, thanks. Acked-by: Peter Chen -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][Patch V7 04/10] ASoC: qcom: add LPASS header files
From: Kenneth Westfield
Add the LPASS header files for ipq806x SOC. This
includes the register definitions for the ipq806x
LPAIF, and the structure definition for the driver
data.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
sound/soc/qcom/lpass-lpaif-ipq806x.h | 172 +++
sound/soc/qcom/lpass.h | 51 +++
2 files changed, 223 insertions(+)
create mode 100644 sound/soc/qcom/lpass-lpaif-ipq806x.h
create mode 100644 sound/soc/qcom/lpass.h
diff --git a/sound/soc/qcom/lpass-lpaif-ipq806x.h
b/sound/soc/qcom/lpass-lpaif-ipq806x.h
new file mode 100644
index
..dc423b425e60ebb11cd0ce78da2574ed27c2
--- /dev/null
+++ b/sound/soc/qcom/lpass-lpaif-ipq806x.h
@@ -0,0 +1,172 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * lpass-lpaif-ipq806x.h -- Definitions for the QTi LPAIF in the ipq806x LPASS
+ */
+
+#ifndef __LPASS_LPAIF_H__
+#define __LPASS_LPAIF_H__
+
+#define LPAIF_BANK_OFFSET 0x1000
+
+/* LPAIF I2S */
+
+#define LPAIF_I2SCTL_REG_BASE 0x0010
+#define LPAIF_I2SCTL_REG_STRIDE0x4
+#define LPAIF_I2SCTL_REG_ADDR(addr, port) \
+ (LPAIF_I2SCTL_REG_BASE + (addr) + (LPAIF_I2SCTL_REG_STRIDE * (port)))
+
+enum lpaif_i2s_ports {
+ LPAIF_I2S_PORT_MIN = 0,
+
+ LPAIF_I2S_PORT_CODEC_SPK= 0,
+ LPAIF_I2S_PORT_CODEC_MIC= 1,
+ LPAIF_I2S_PORT_SEC_SPK = 2,
+ LPAIF_I2S_PORT_SEC_MIC = 3,
+ LPAIF_I2S_PORT_MI2S = 4,
+
+ LPAIF_I2S_PORT_MAX = 4,
+ LPAIF_I2S_PORT_NUM = 5,
+};
+
+#define LPAIF_I2SCTL_REG(port) LPAIF_I2SCTL_REG_ADDR(0x0, (port))
+
+#define LPAIF_I2SCTL_LOOPBACK_MASK 0x8000
+#define LPAIF_I2SCTL_LOOPBACK_SHIFT15
+#define LPAIF_I2SCTL_LOOPBACK_DISABLE (0 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+#define LPAIF_I2SCTL_LOOPBACK_ENABLE (1 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+
+#define LPAIF_I2SCTL_SPKEN_MASK0x4000
+#define LPAIF_I2SCTL_SPKEN_SHIFT 14
+#define LPAIF_I2SCTL_SPKEN_DISABLE (0 << LPAIF_I2SCTL_SPKEN_SHIFT)
+#define LPAIF_I2SCTL_SPKEN_ENABLE (1 << LPAIF_I2SCTL_SPKEN_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMODE_MASK 0x3C00
+#define LPAIF_I2SCTL_SPKMODE_SHIFT 10
+#define LPAIF_I2SCTL_SPKMODE_NONE (0 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD0 (1 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD1 (2 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD2 (3 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD3 (4 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD01(5 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD23(6 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_6CH (7 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_8CH (8 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMONO_MASK 0x0200
+#define LPAIF_I2SCTL_SPKMONO_SHIFT 9
+#define LPAIF_I2SCTL_SPKMONO_STEREO(0 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+#define LPAIF_I2SCTL_SPKMONO_MONO (1 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+
+#define LPAIF_I2SCTL_WSSRC_MASK0x0004
+#define LPAIF_I2SCTL_WSSRC_SHIFT 2
+#define LPAIF_I2SCTL_WSSRC_INTERNAL(0 << LPAIF_I2SCTL_WSSRC_SHIFT)
+#define LPAIF_I2SCTL_WSSRC_EXTERNAL(1 << LPAIF_I2SCTL_WSSRC_SHIFT)
+
+#define LPAIF_I2SCTL_BITWIDTH_MASK 0x0003
+#define LPAIF_I2SCTL_BITWIDTH_SHIFT0
+#define LPAIF_I2SCTL_BITWIDTH_16 (0 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_24 (1 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_32 (2 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+
+/* LPAIF IRQ */
+
+#define LPAIF_IRQ_REG_BASE 0x3000
+#define LPAIF_IRQ_REG_STRIDE 0x1000
+#define LPAIF_IRQ_REG_ADDR(addr, port) \
+ (LPAIF_IRQ_REG_BASE + (addr) + (LPAIF_IRQ_REG_STRIDE * (port)))
+
+enum lpaif_irq_ports {
+ LPAIF_IRQ_PORT_MIN = 0,
+
+ LPAIF_IRQ_PORT_HOST = 0,
+ LPAIF_IRQ_PORT_ADSP = 1,
+
+ LPAIF_IRQ_PORT_MAX = 2,
+ LPAIF_IRQ_PORT_NUM = 3,
+};
+
+#define LPAIF_IRQEN_REG(port) LPAIF_IRQ_REG_ADDR(0x0, (port))
+#define LPAIF_IRQSTAT_REG(port)LPAIF_IRQ_REG_ADDR(0x4, (port))
+#define LPAIF_IRQCLEAR_REG(port) LPAIF_IRQ_REG_ADD
Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register
On 15-03-03 02:22 AM, Pawel Moll wrote: On Tue, 2015-03-03 at 10:02 +, Pawel Moll wrote: On Mon, 2015-03-02 at 19:09 +, Arun Ramamurthy wrote: The existing bindings intentionally avoided quoting internal registers - they are supposed to describe how the hardware is wired up... So how about something like "arm,pl11x,tft-invert-clac"? Then the driver sets the bit or not, depending on the property existance? Sure, I can change it to two properties called arm,pl11x,tft-invert-clac and arm,pl11x,tft-clksel. Would that be acceptable? That would be fine by me :-) Or (after having a look at the TRM) I should rather say: the invert-clac is fine by me :-) but the tft-clksel doesn't work, I afraid. If I'm not mistaken, there are two problems with it. Number one: it's not TFT-specific, is it? So it certainly should not have the "tft-" bit. Number two: setting this bit says "do not use CLCDCLK for the logic; use HCLK instead", correct? If so, have a look at the clock properties. They say: - clock-names: should contain "clcdclk" and "apb_pclk" - clocks: contains phandle and clock specifier pairs for the entries in the clock-names property. See So if your hardware has the reference clock wired to HCLK, and you defining the clocks as "clcdclk", you are (no offence meant ;-) lying :-) No offense taken :) So how about solving the problem by extending the clock-names definition like this (feel free to use own wording): - clock-names: should contain two clocks, either "clcdclk" or "hclk" (depending on which input is to be used as a reference clock by the controller logic) and "apb_pclk" That way you're precisely describing the way the hardware is wired up. And the driver simply tries to get clcdclk first, if it's defined - cool, set clksel to 1, if not - try hclk and set clksel to 0. If neither of them is present - bail out. Does this make any sense? This makes sense to me, thank you for the suggestions. I will fix it all up in V2 Pawel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
On 15-03-03 02:01 AM, Pawel Moll wrote:
On Mon, 2015-03-02 at 19:09 +, Arun Ramamurthy wrote:
On 15-03-02 08:00 AM, Pawel Moll wrote:
On Wed, 2015-02-25 at 21:01 +, Arun Ramamurthy wrote:
Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC
Also corrected documentation to make interrupts and interrupt-names
optional as they are not required properties.
You may not be aware of this fact, but its the "documentation" what
defines what properties are required...
Pawel, I was not aware of that. Since the driver code did not require
the interrupts or interrupt-names bindings to load properly, I moved it
out of the required properties. I can remove that change.
Cool. Drivers don't have to use all available properties :-) The
interrupt names are required because CLCD can be wired up with a single,
combined interrupt or with 4 separate interrupt lines (see "A.4. On-chip
signals", in the TRM) and the binding has to provide ways of describing
this. Yes, one could say "1 number == combined, 4 numbers == split", but
I personally prefer to be explicit than implicit.
Just request the interrupt by name and you'll be fine.
Ok got it, will make the necessary changes
Any other comments on this change? Thanks
I have no experience with the vsync ioctl, so can't really comment on
it. One minor thing I did spot is your use of curly brackets in one of
the switch cases:
On Wed, 2015-02-25 at 21:01 +, Arun Ramamurthy wrote:
@@ -466,6 +468,73 @@ static int clcdfb_pan_display(struct fb_var_screeninfo
*var,
return 0;
}
+static int clcdfb_ioctl(struct fb_info *info,
+ unsigned int cmd, unsigned long args)
+{
+ struct clcd_fb *fb = to_clcd(info);
+ int retval = 0;
+ u32 val, ienb_val;
+
+ switch (cmd) {
+ case FBIO_WAITFORVSYNC:{
In the line above...
+ if (fb->lcd_irq <= 0) {
+ retval = -EINVAL;
+ break;
+ }
+ /* disable Vcomp interrupts */
+ ienb_val = readl(fb->regs + fb->off_ienb);
+ ienb_val &= ~CLCD_PL111_IENB_VCOMP;
+ writel(ienb_val, fb->regs + fb->off_ienb);
+
+ /* clear Vcomp interrupt */
+ writel(CLCD_PL111_IENB_VCOMP, fb->regs + CLCD_PL111_ICR);
+
+ /* Generate Interrupt at the start of Vsync */
+ reinit_completion(&fb->wait);
+ val = readl(fb->regs + fb->off_cntl);
+ val &= ~(CNTL_LCDVCOMP(3));
+ writel(val, fb->regs + fb->off_cntl);
+
+ /* enable Vcomp interrupt */
+ ienb_val = readl(fb->regs + fb->off_ienb);
+ ienb_val |= CLCD_PL111_IENB_VCOMP;
+ writel(ienb_val, fb->regs + fb->off_ienb);
+ if (!wait_for_completion_interruptible_timeout
+ (&fb->wait, HZ/10))
+ retval = -ETIMEDOUT;
+ break;
+ }
... and here.
Not sure it's needed?
No its not needed, I can remove it.
Pawel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
On 15-03-02 03:29 PM, Rob Herring wrote: On Wed, Feb 25, 2015 at 3:01 PM, Arun Ramamurthy wrote: Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC Also corrected documentation to make interrupts and interrupt-names optional as they are not required properties. Reviewed-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Arun Ramamurthy 0 --- .../devicetree/bindings/video/arm,pl11x.txt| 11 +-- Please split bindings to separate patches. Rob, I looked at the history of patches to this driver and all them included changes to the documentation in the same patch so I followed a similar model. I assumed that a separate patch was only required when the documentation was being added from scratch and not when modifying a few lines. Is this not the case? drivers/video/fbdev/amba-clcd.c| 82 ++ include/linux/amba/clcd.h | 4 ++ 3 files changed, 89 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt index 2262cdb..7d19024 100644 --- a/Documentation/devicetree/bindings/video/arm,pl11x.txt +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt @@ -10,14 +10,6 @@ Required properties: - reg: base address and size of the control registers block -- interrupt-names: either the single entry "combined" representing a - combined interrupt output (CLCDINTR), or the four entries - "mbe", "vcomp", "lnbu", "fuf" representing the individual - CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts - -- interrupts: contains an interrupt specifier for each entry in - interrupt-names - - clock-names: should contain "clcdclk" and "apb_pclk" - clocks: contains phandle and clock specifier pairs for the entries @@ -54,6 +46,9 @@ Optional properties: It can be used to configure a virtual y resolution. It must be a value larger than the actual y resolution. +- interrupts: contains an interrupt specifier for the clcd vcomp interrupt +This is required for the driver to handle FBIO_WAITFORVSYNC ioctls. + What happened to interrupt-names? As mentioned before, these changes to the documentation will be undone in V2. Thanks Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
On 15-03-02 03:27 PM, Rob Herring wrote: On Mon, Mar 2, 2015 at 10:00 AM, Pawel Moll wrote: On Wed, 2015-02-25 at 21:01 +, Arun Ramamurthy wrote: Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC Also corrected documentation to make interrupts and interrupt-names optional as they are not required properties. You may not be aware of this fact, but its the "documentation" what defines what properties are required... Except when docs are wrong. Then dts files win. Reviewed-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Arun Ramamurthy 0 --- .../devicetree/bindings/video/arm,pl11x.txt| 11 +-- drivers/video/fbdev/amba-clcd.c| 82 ++ include/linux/amba/clcd.h | 4 ++ 3 files changed, 89 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt index 2262cdb..7d19024 100644 --- a/Documentation/devicetree/bindings/video/arm,pl11x.txt +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt @@ -10,14 +10,6 @@ Required properties: - reg: base address and size of the control registers block -- interrupt-names: either the single entry "combined" representing a - combined interrupt output (CLCDINTR), or the four entries - "mbe", "vcomp", "lnbu", "fuf" representing the individual - CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts - -- interrupts: contains an interrupt specifier for each entry in - interrupt-names - - clock-names: should contain "clcdclk" and "apb_pclk" - clocks: contains phandle and clock specifier pairs for the entries So no, you can't do that. You can't do the other way around (making optional ones required), but I think this is okay if the h/w interrupt lines are not physically connected. However, if it is simply because the driver doesn't use them, then I agree this should not be changed. Agreed, I will undo this change in V2 Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] video: ARM CLCD: Added support for FBIOPAN_DISPLAY and virtual y resolution
On 15-03-02 03:22 PM, Rob Herring wrote: On Mon, Mar 2, 2015 at 1:09 PM, Arun Ramamurthy wrote: On 15-03-02 08:11 AM, Russell King - ARM Linux wrote: On Mon, Mar 02, 2015 at 04:08:29PM +, Pawel Moll wrote: I'm not sure about this... The word "virtual" never works well with device tree nodes defined as "hardware description". I understand what you're doing, but adding this property to the display controller's node doesn't sound right. How does this describe hardware? If anywhere, it's more like a job for the panel node? I see what you are saying Pawel, I can follow Russell's recommendation of adding a RAM size node called max-memory-available or something similar We've already got a binding for reserved memory regions for this purpose. And there is also simplefb binding. Rob, I am not sure what binding you are referring to, could you be more specific? Also how does the simplefb bindings apply to me considering that is a separate driver? Thanks Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch V7 07/10] ASoC: qcom: Add Storm machine driver
From: Kenneth Westfield
Add machine driver for the Storm board with the
IPQ806X SOC connected to the MAX98357A DAC.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
sound/soc/qcom/storm.c | 162 +
1 file changed, 162 insertions(+)
create mode 100644 sound/soc/qcom/storm.c
diff --git a/sound/soc/qcom/storm.c b/sound/soc/qcom/storm.c
new file mode 100644
index
..5b981af4aa38a6a3bba926b3dd877239eefe8cb0
--- /dev/null
+++ b/sound/soc/qcom/storm.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * storm.c -- ALSA SoC machine driver for QTi ipq806x-based Storm board
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define STORM_SYSCLK_MULT 4
+
+static int storm_ops_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+ struct snd_soc_card *card = soc_runtime->card;
+ snd_pcm_format_t format = params_format(params);
+ unsigned int rate = params_rate(params);
+ unsigned int sysclk_freq;
+ int bitwidth, ret;
+
+ bitwidth = snd_pcm_format_width(format);
+ if (bitwidth < 0) {
+ dev_err(card->dev, "%s() invalid bit width given: %d\n",
+ __func__, bitwidth);
+ return bitwidth;
+ }
+
+ /*
+* as the CPU DAI is the I2S bus master and no system clock is needed by
+* the MAX98357a DAC, simply set the system clock to be a constant
+* multiple of the bit clock for the clock divider
+*/
+ sysclk_freq = rate * bitwidth * 2 * STORM_SYSCLK_MULT;
+
+ ret = snd_soc_dai_set_sysclk(soc_runtime->cpu_dai, 0, sysclk_freq, 0);
+ if (ret) {
+ dev_err(card->dev, "%s() error setting sysclk to %u: %d\n",
+ __func__, sysclk_freq, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct snd_soc_ops storm_soc_ops = {
+ .hw_params = storm_ops_hw_params,
+};
+
+static struct snd_soc_dai_link storm_dai_link = {
+ .name = "Primary",
+ .stream_name= "Primary",
+ .codec_dai_name = "HiFi",
+ .ops= &storm_soc_ops,
+};
+
+static struct snd_soc_card storm_soc_card = {
+ .name = "ipq806x-storm",
+ .dev= NULL,
+};
+
+static int storm_parse_of(struct snd_soc_card *card)
+{
+ struct snd_soc_dai_link *dai_link = card->dai_link;
+ struct device_node *np = card->dev->of_node;
+
+ dai_link->cpu_of_node = of_parse_phandle(np, "cpu", 0);
+ if (!dai_link->cpu_of_node) {
+ dev_err(card->dev, "%s() error getting cpu phandle\n",
+ __func__);
+ return -EINVAL;
+ }
+ dai_link->platform_of_node = dai_link->cpu_of_node;
+
+ dai_link->codec_of_node = of_parse_phandle(np, "codec", 0);
+ if (!dai_link->codec_of_node) {
+ dev_err(card->dev, "%s() error getting codec phandle\n",
+ __func__);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int storm_platform_probe(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = &storm_soc_card;
+ int ret;
+
+ if (card->dev) {
+ dev_err(&pdev->dev, "%s() error, existing soundcard\n",
+ __func__);
+ return -ENODEV;
+ }
+ card->dev = &pdev->dev;
+ platform_set_drvdata(pdev, card);
+
+ ret = snd_soc_of_parse_card_name(card, "qcom,model");
+ if (ret) {
+ dev_err(&pdev->dev, "%s() error parsing card name: %d\n",
+ __func__, ret);
+ return ret;
+ }
+
+ card->dai_link = &storm_dai_link;
+ card->num_links = 1;
+
+ ret = storm_parse_of(card);
+ if (ret) {
+ dev_err(&pdev->dev, "%s() error resolving dai links: %d\n",
+ __func__, ret);
+ return ret;
+ }
+
+ ret = devm_snd_soc_register_card(&pdev->dev, card);
+ if (ret == -EPROBE_DEFER) {
+ card->dev = NULL;
+ return ret;
+ } else if (ret) {
+ dev_err(&pdev->dev, "%s() error registering
[Patch V7 01/10] MAINTAINERS: Add QCOM audio ASoC maintainer
From: Kenneth Westfield Add maintainers for the Qualcomm Technologies sound drivers. Signed-off-by: Kenneth Westfield Acked-by: Banajit Goswami --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddc5a8cf9a8ac0078f8ca1bc99d9c48f8197214a..9514b794b74d7fb93072bbdbaefaaa79df38c5fd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5254,6 +5254,13 @@ F: drivers/char/ipmi/ F: include/linux/ipmi* F: include/uapi/linux/ipmi* +QCOM AUDIO (ASoC) DRIVERS +M: Patrick Lai +M: Banajit Goswami +L: alsa-de...@alsa-project.org (moderated for non-subscribers) +S: Supported +F: sound/soc/qcom/ + IPS SCSI RAID DRIVER M: Adaptec OEM Raid Solutions L: linux-s...@vger.kernel.org -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch V7 08/10] ASoC: qcom: Add ability to build QCOM drivers
From: Kenneth Westfield Define the LPASS platform driver, the LPASS CPU DAI driver and the Storm machine driver configurations, and how to build them. Signed-off-by: Kenneth Westfield Acked-by: Banajit Goswami --- sound/soc/qcom/Kconfig | 25 + sound/soc/qcom/Makefile | 11 +++ 2 files changed, 36 insertions(+) create mode 100644 sound/soc/qcom/Kconfig create mode 100644 sound/soc/qcom/Makefile diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig new file mode 100644 index ..5f58e4f1bca98b5c4c4c951dce24036aafa2d694 --- /dev/null +++ b/sound/soc/qcom/Kconfig @@ -0,0 +1,25 @@ +config SND_SOC_QCOM + tristate "ASoC support for QCOM platforms" + help + Say Y or M if you want to add support to use audio devices + in Qualcomm Technologies SOC-based platforms. + +config SND_SOC_LPASS_CPU + tristate + depends on SND_SOC_QCOM + select REGMAP_MMIO + +config SND_SOC_LPASS_PLATFORM + tristate + depends on SND_SOC_QCOM + select REGMAP_MMIO + +config SND_SOC_STORM + tristate "ASoC I2S support for Storm boards" + depends on (ARCH_QCOM && SND_SOC_QCOM) || COMPILE_TEST + select SND_SOC_LPASS_CPU + select SND_SOC_LPASS_PLATFORM + select SND_SOC_MAX98357A + help + Say Y or M if you want add support for SoC audio on the + Qualcomm Technologies IPQ806X-based Storm board. diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile new file mode 100644 index ..c5ce96c761c47b3a1b98e27d863fe0b5b9bc019e --- /dev/null +++ b/sound/soc/qcom/Makefile @@ -0,0 +1,11 @@ +# Platform +snd-soc-lpass-cpu-objs := lpass-cpu.o +snd-soc-lpass-platform-objs := lpass-platform.o + +obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o +obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o + +# Machine +snd-soc-storm-objs := storm.o + +obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch V7 09/10] ASoC: Allow for building QCOM drivers
From: Kenneth Westfield Allow for the Qualcomm Technologies ASoC drivers to build. Signed-off-by: Kenneth Westfield Acked-by: Banajit Goswami --- sound/soc/Kconfig | 1 + sound/soc/Makefile | 1 + 2 files changed, 2 insertions(+) diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index dcc79aa0236b548bfe5408fe56689241fc597e97..3ba52da18bc69a9bb41c84627cfc7d08f47e3bf0 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -47,6 +47,7 @@ source "sound/soc/kirkwood/Kconfig" source "sound/soc/intel/Kconfig" source "sound/soc/mxs/Kconfig" source "sound/soc/pxa/Kconfig" +source "sound/soc/qcom/Kconfig" source "sound/soc/rockchip/Kconfig" source "sound/soc/samsung/Kconfig" source "sound/soc/sh/Kconfig" diff --git a/sound/soc/Makefile b/sound/soc/Makefile index 5b3c8f67c8db7a29ff7199a6103d445428978125..974ba708b4826a03077a58251434a311542d5e3c 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_SND_SOC) += nuc900/ obj-$(CONFIG_SND_SOC) += omap/ obj-$(CONFIG_SND_SOC) += kirkwood/ obj-$(CONFIG_SND_SOC) += pxa/ +obj-$(CONFIG_SND_SOC) += qcom/ obj-$(CONFIG_SND_SOC) += rockchip/ obj-$(CONFIG_SND_SOC) += samsung/ obj-$(CONFIG_SND_SOC) += sh/ -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch V7 05/10] ASoC: qcom: Add LPASS CPU DAI driver
From: Kenneth Westfield
Add the CPU DAI driver for the Qualcomm
Technologies low-power audio subsystem (LPASS).
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
sound/soc/qcom/lpass-cpu.c | 510 +
1 file changed, 510 insertions(+)
create mode 100644 sound/soc/qcom/lpass-cpu.c
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
new file mode 100644
index
..d5167131787f3a7663665c94dffe6899bd050179
--- /dev/null
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -0,0 +1,510 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * lpass-cpu.c -- ALSA SoC CPU DAI driver for QTi LPASS
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "lpass-lpaif-ipq806x.h"
+#include "lpass.h"
+
+static int lpass_cpu_daiops_set_sysclk(struct snd_soc_dai *dai, int clk_id,
+ unsigned int freq, int dir)
+{
+ struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+ int ret;
+
+ ret = clk_set_rate(drvdata->mi2s_osr_clk, freq);
+ if (ret)
+ dev_err(dai->dev, "%s() error setting mi2s osrclk to %u: %d\n",
+ __func__, freq, ret);
+
+ return ret;
+}
+
+static int lpass_cpu_daiops_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+ int ret;
+
+ ret = clk_prepare_enable(drvdata->mi2s_osr_clk);
+ if (ret) {
+ dev_err(dai->dev, "%s() error in enabling mi2s osr clk: %d\n",
+ __func__, ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(drvdata->mi2s_bit_clk);
+ if (ret) {
+ dev_err(dai->dev, "%s() error in enabling mi2s bit clk: %d\n",
+ __func__, ret);
+ clk_disable_unprepare(drvdata->mi2s_osr_clk);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void lpass_cpu_daiops_shutdown(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+
+ clk_disable_unprepare(drvdata->mi2s_bit_clk);
+ clk_disable_unprepare(drvdata->mi2s_osr_clk);
+}
+
+static int lpass_cpu_daiops_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
+{
+ struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+ snd_pcm_format_t format = params_format(params);
+ unsigned int channels = params_channels(params);
+ unsigned int rate = params_rate(params);
+ unsigned int regval;
+ int bitwidth, ret;
+
+ bitwidth = snd_pcm_format_width(format);
+ if (bitwidth < 0) {
+ dev_err(dai->dev, "%s() invalid bit width given: %d\n",
+ __func__, bitwidth);
+ return bitwidth;
+ }
+
+ regval = LPAIF_I2SCTL_LOOPBACK_DISABLE |
+ LPAIF_I2SCTL_WSSRC_INTERNAL;
+
+ switch (bitwidth) {
+ case 16:
+ regval |= LPAIF_I2SCTL_BITWIDTH_16;
+ break;
+ case 24:
+ regval |= LPAIF_I2SCTL_BITWIDTH_24;
+ break;
+ case 32:
+ regval |= LPAIF_I2SCTL_BITWIDTH_32;
+ break;
+ default:
+ dev_err(dai->dev, "%s() invalid bitwidth given: %d\n",
+ __func__, bitwidth);
+ return -EINVAL;
+ }
+
+ switch (channels) {
+ case 1:
+ regval |= LPAIF_I2SCTL_SPKMODE_SD0;
+ regval |= LPAIF_I2SCTL_SPKMONO_MONO;
+ break;
+ case 2:
+ regval |= LPAIF_I2SCTL_SPKMODE_SD0;
+ regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+ break;
+ case 4:
+ regval |= LPAIF_I2SCTL_SPKMODE_QUAD01;
+ regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+ break;
+ case 6:
+ regval |= LPAIF_I2SCTL_SPKMODE_6CH;
+ regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+ break;
+ case 8:
+ regval |= LPAIF_I2SCTL_SPKMODE_8CH;
+ regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+ break;
+
[Patch V7 06/10] ASoC: qcom: Add LPASS platform driver
From: Kenneth Westfield
Add platform driver for the Qualcomm Technologies
low-power audio subsystem (LPASS) ports.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
sound/soc/qcom/lpass-platform.c | 526
1 file changed, 526 insertions(+)
create mode 100644 sound/soc/qcom/lpass-platform.c
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
new file mode 100644
index
..2fa6280dfb234b213904ad73dfad91c7f575538c
--- /dev/null
+++ b/sound/soc/qcom/lpass-platform.c
@@ -0,0 +1,526 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * lpass-platform.c -- ALSA SoC platform driver for QTi LPASS
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "lpass-lpaif-ipq806x.h"
+#include "lpass.h"
+
+#define LPASS_PLATFORM_BUFFER_SIZE (16 * 1024)
+#define LPASS_PLATFORM_PERIODS 2
+
+static struct snd_pcm_hardware lpass_platform_pcm_hardware = {
+ .info = SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_INTERLEAVED |
+ SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_RESUME,
+ .formats= SNDRV_PCM_FMTBIT_S16 |
+ SNDRV_PCM_FMTBIT_S24 |
+ SNDRV_PCM_FMTBIT_S32,
+ .rates = SNDRV_PCM_RATE_8000_192000,
+ .rate_min = 8000,
+ .rate_max = 192000,
+ .channels_min = 1,
+ .channels_max = 8,
+ .buffer_bytes_max = LPASS_PLATFORM_BUFFER_SIZE,
+ .period_bytes_max = LPASS_PLATFORM_BUFFER_SIZE /
+ LPASS_PLATFORM_PERIODS,
+ .period_bytes_min = LPASS_PLATFORM_BUFFER_SIZE /
+ LPASS_PLATFORM_PERIODS,
+ .periods_min= LPASS_PLATFORM_PERIODS,
+ .periods_max= LPASS_PLATFORM_PERIODS,
+ .fifo_size = 0,
+};
+
+static int lpass_platform_pcmops_open(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+ int ret;
+
+ snd_soc_set_runtime_hwparams(substream, &lpass_platform_pcm_hardware);
+
+ runtime->dma_bytes = lpass_platform_pcm_hardware.buffer_bytes_max;
+
+ ret = snd_pcm_hw_constraint_integer(runtime,
+ SNDRV_PCM_HW_PARAM_PERIODS);
+ if (ret < 0) {
+ dev_err(soc_runtime->dev, "%s() setting constraints failed:
%d\n",
+ __func__, ret);
+ return -EINVAL;
+ }
+
+ snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
+
+ return 0;
+}
+
+static int lpass_platform_pcmops_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+ struct lpass_data *drvdata =
+ snd_soc_platform_get_drvdata(soc_runtime->platform);
+ snd_pcm_format_t format = params_format(params);
+ unsigned int channels = params_channels(params);
+ unsigned int regval;
+ int bitwidth;
+ int ret;
+
+ bitwidth = snd_pcm_format_width(format);
+ if (bitwidth < 0) {
+ dev_err(soc_runtime->dev, "%s() invalid bit width given: %d\n",
+ __func__, bitwidth);
+ return bitwidth;
+ }
+
+ regval = LPAIF_RDMACTL_BURSTEN_INCR4 |
+ LPAIF_RDMACTL_AUDINTF_MI2S |
+ LPAIF_RDMACTL_FIFOWM_8;
+
+ switch (bitwidth) {
+ case 16:
+ switch (channels) {
+ case 1:
+ case 2:
+ regval |= LPAIF_RDMACTL_WPSCNT_ONE;
+ break;
+ case 4:
+ regval |= LPAIF_RDMACTL_WPSCNT_TWO;
+ break;
+ case 6:
+ regval |= LPAIF_RDMACTL
[Patch V7 03/10] ASoC: qcom: Document Storm bindings
From: Kenneth Westfield
Add documentation to the sound directory of the
device-tree bindings for the soundcard of the
Storm board.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
Documentation/devicetree/bindings/sound/storm.txt | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/storm.txt
diff --git a/Documentation/devicetree/bindings/sound/storm.txt
b/Documentation/devicetree/bindings/sound/storm.txt
new file mode 100644
index
..2a308e9c4cd3f9550c0b7078200a14a787f02858
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/storm.txt
@@ -0,0 +1,23 @@
+* Sound complex for Storm boards
+
+Models a soundcard for Storm boards with the Qualcomm Technologies IPQ806x SOC
+connected to a MAX98357A DAC via I2S.
+
+Required properties:
+
+- compatible : "google,storm"
+- cpu : Phandle of the CPU DAI
+- codec: Phandle of the codec DAI
+
+Optional properties:
+
+- qcom,model : The user-visible name of this sound card.
+
+Example:
+
+sound {
+ compatible = "google,storm";
+ qcom,model = "ipq806x-storm";
+ cpu = <&lpass_cpu>;
+ codec = <&max98357a>;
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch V7 02/10] ASoC: qcom: Document LPASS CPU bindings
From: Kenneth Westfield
Add documentation to the sound directory of the
device-tree bindings for the QTi LPASS CPU DAI
device.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
.../devicetree/bindings/sound/qcom,lpass-cpu.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
new file mode 100644
index
..e7c6e9321863f022ebf0d51b75d7bb83c10b9062
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
@@ -0,0 +1,49 @@
+* Qualcomm Technologies LPASS CPU DAI
+
+This node models the Qualcomm Technologies Low-Power Audio SubSystem (LPASS).
+
+Required properties:
+
+- compatible : "qcom,lpass-cpu"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : A list which must include the following entries:
+ * "ahbix-clk"
+ * "mi2s-osr-clk"
+ * "mi2s-bit-clk"
+- interrupts : Must contain an entry for each entry in
+ interrupt-names.
+- interrupt-names : A list which must include the following entries:
+ * "lpass-irq-lpaif"
+- pinctrl-N: One property must exist for each entry in
+ pinctrl-names. See ../pinctrl/pinctrl-bindings.txt
+ for details of the property values.
+- pinctrl-names: Must contain a "default" entry.
+- reg : Must contain an address for each entry in reg-names.
+- reg-names: A list which must include the following entries:
+ * "lpass-lpaif"
+
+Required subnodes:
+
+- qcom,adsp: Audio DSP sub-node
+
+Optional Audio DSP subnode properties:
+
+- status : "disabled" indicates the adsp is not available.
+
+Example:
+
+lpass@2810 {
+ compatible = "qcom,lpass-cpu";
+ clocks = <&lcc AHBIX_CLK>, <&lcc MI2S_OSR_CLK>, <&lcc MI2S_BIT_CLK>;
+ clock-names = "ahbix-clk", "mi2s-osr-clk", "mi2s-bit-clk";
+ interrupts = <0 85 1>;
+ interrupt-names = "lpass-irq-lpaif";
+ pinctrl-names = "default", "idle";
+ pinctrl-0 = <&mi2s_default>;
+ pinctrl-1 = <&mi2s_idle>;
+ reg = <0x2810 0x1>;
+ reg-names = "lpass-lpaif";
+ qcom,adsp {
+ status = "disabled";
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch V7 10/10] ARM: dts: Model IPQ LPASS audio hardware
From: Kenneth Westfield
Model the Qualcomm Technologies LPASS hardware for
the ipq806x SOC.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index
cb225dafe97cd83c9ae4cc19482ed55d4a71b8b3..8902d967463b3d9e6e02c6ec6518e392d8372050
100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -2,6 +2,7 @@
#include "skeleton.dtsi"
#include
+#include
#include
/ {
@@ -96,6 +97,24 @@
cpu-offset = <0x8>;
};
+ lpass@2810 {
+ compatible = "qcom,lpass-cpu";
+ status = "disabled";
+ clocks = <&lcc AHBIX_CLK>,
+ <&lcc MI2S_OSR_CLK>,
+ <&lcc MI2S_BIT_CLK>;
+ clock-names = "ahbix-clk",
+ "mi2s-osr-clk",
+ "mi2s-bit-clk";
+ interrupts = <0 85 1>;
+ interrupt-names = "lpass-irq-lpaif";
+ reg = <0x2810 0x1>;
+ reg-names = "lpass-lpaif";
+ qcom,adsp {
+ status = "disabled";
+ };
+ };
+
acc0: clock-controller@2088000 {
compatible = "qcom,kpss-acc-v1";
reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
@@ -279,5 +298,12 @@
#clock-cells = <1>;
#reset-cells = <1>;
};
+
+ lcc: clock-controller@2800 {
+ compatible = "qcom,lcc-ipq8064";
+ reg = <0x2800 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch V7 04/10] ASoC: qcom: add LPASS header files
From: Kenneth Westfield
Add the LPASS header files for ipq806x SOC. This
includes the register definitions for the ipq806x
LPAIF, and the structure definition for the driver
data.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
sound/soc/qcom/lpass-lpaif-ipq806x.h | 172 +++
sound/soc/qcom/lpass.h | 51 +++
2 files changed, 223 insertions(+)
create mode 100644 sound/soc/qcom/lpass-lpaif-ipq806x.h
create mode 100644 sound/soc/qcom/lpass.h
diff --git a/sound/soc/qcom/lpass-lpaif-ipq806x.h
b/sound/soc/qcom/lpass-lpaif-ipq806x.h
new file mode 100644
index
..dc423b425e60ebb11cd0ce78da2574ed27c2
--- /dev/null
+++ b/sound/soc/qcom/lpass-lpaif-ipq806x.h
@@ -0,0 +1,172 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * lpass-lpaif-ipq806x.h -- Definitions for the QTi LPAIF in the ipq806x LPASS
+ */
+
+#ifndef __LPASS_LPAIF_H__
+#define __LPASS_LPAIF_H__
+
+#define LPAIF_BANK_OFFSET 0x1000
+
+/* LPAIF I2S */
+
+#define LPAIF_I2SCTL_REG_BASE 0x0010
+#define LPAIF_I2SCTL_REG_STRIDE0x4
+#define LPAIF_I2SCTL_REG_ADDR(addr, port) \
+ (LPAIF_I2SCTL_REG_BASE + (addr) + (LPAIF_I2SCTL_REG_STRIDE * (port)))
+
+enum lpaif_i2s_ports {
+ LPAIF_I2S_PORT_MIN = 0,
+
+ LPAIF_I2S_PORT_CODEC_SPK= 0,
+ LPAIF_I2S_PORT_CODEC_MIC= 1,
+ LPAIF_I2S_PORT_SEC_SPK = 2,
+ LPAIF_I2S_PORT_SEC_MIC = 3,
+ LPAIF_I2S_PORT_MI2S = 4,
+
+ LPAIF_I2S_PORT_MAX = 4,
+ LPAIF_I2S_PORT_NUM = 5,
+};
+
+#define LPAIF_I2SCTL_REG(port) LPAIF_I2SCTL_REG_ADDR(0x0, (port))
+
+#define LPAIF_I2SCTL_LOOPBACK_MASK 0x8000
+#define LPAIF_I2SCTL_LOOPBACK_SHIFT15
+#define LPAIF_I2SCTL_LOOPBACK_DISABLE (0 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+#define LPAIF_I2SCTL_LOOPBACK_ENABLE (1 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+
+#define LPAIF_I2SCTL_SPKEN_MASK0x4000
+#define LPAIF_I2SCTL_SPKEN_SHIFT 14
+#define LPAIF_I2SCTL_SPKEN_DISABLE (0 << LPAIF_I2SCTL_SPKEN_SHIFT)
+#define LPAIF_I2SCTL_SPKEN_ENABLE (1 << LPAIF_I2SCTL_SPKEN_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMODE_MASK 0x3C00
+#define LPAIF_I2SCTL_SPKMODE_SHIFT 10
+#define LPAIF_I2SCTL_SPKMODE_NONE (0 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD0 (1 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD1 (2 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD2 (3 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD3 (4 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD01(5 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD23(6 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_6CH (7 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_8CH (8 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMONO_MASK 0x0200
+#define LPAIF_I2SCTL_SPKMONO_SHIFT 9
+#define LPAIF_I2SCTL_SPKMONO_STEREO(0 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+#define LPAIF_I2SCTL_SPKMONO_MONO (1 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+
+#define LPAIF_I2SCTL_WSSRC_MASK0x0004
+#define LPAIF_I2SCTL_WSSRC_SHIFT 2
+#define LPAIF_I2SCTL_WSSRC_INTERNAL(0 << LPAIF_I2SCTL_WSSRC_SHIFT)
+#define LPAIF_I2SCTL_WSSRC_EXTERNAL(1 << LPAIF_I2SCTL_WSSRC_SHIFT)
+
+#define LPAIF_I2SCTL_BITWIDTH_MASK 0x0003
+#define LPAIF_I2SCTL_BITWIDTH_SHIFT0
+#define LPAIF_I2SCTL_BITWIDTH_16 (0 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_24 (1 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_32 (2 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+
+/* LPAIF IRQ */
+
+#define LPAIF_IRQ_REG_BASE 0x3000
+#define LPAIF_IRQ_REG_STRIDE 0x1000
+#define LPAIF_IRQ_REG_ADDR(addr, port) \
+ (LPAIF_IRQ_REG_BASE + (addr) + (LPAIF_IRQ_REG_STRIDE * (port)))
+
+enum lpaif_irq_ports {
+ LPAIF_IRQ_PORT_MIN = 0,
+
+ LPAIF_IRQ_PORT_HOST = 0,
+ LPAIF_IRQ_PORT_ADSP = 1,
+
+ LPAIF_IRQ_PORT_MAX = 2,
+ LPAIF_IRQ_PORT_NUM = 3,
+};
+
+#define LPAIF_IRQEN_REG(port) LPAIF_IRQ_REG_ADDR(0x0, (port))
+#define LPAIF_IRQSTAT_REG(port)LPAIF_IRQ_REG_ADDR(0x4, (port))
+#define LPAIF_IRQCLEAR_REG(port) LPAIF_IRQ_REG_ADD
[Patch V7 00/10] ASoC: QCOM: Add support for ipq806x SOC
From: Kenneth Westfield This patch series adds support for I2S audio playback on the Storm board, which contains a Qualcomm Technologies ipq806x SOC and a Maxim max98357a DAC/amp. The ipq806x SOC has audio-related hardware blocks in its low-power audio subsystem (or LPASS). One of the relevant blocks in the LPASS is its low-power audio interface (or LPAIF). This contains an MI2S port, which is what these drivers are configured to use. The LPAIF also contains a DMA engine that is dedicated to moving audio samples into the transmit FIFO of the MI2S port. One bus from the MI2S port of the SOC is connected to the DAC/amp for stereo playback. This bus is configured so that the SOC is bus master and consists of DATA, LRCLK, and BCLK. The DAC/amp does not need MCLK to operate. In addition, a single GPIO pin from the SOC is connected to the same DAC/amp, which gives enable/disable control over the DAC/amp. The specific drivers added are: * a CPU DAI driver for controlling the MI2S port * a platform driver for controlling the LPAIF DMA engine * a machine driver that instantiates a dai-link for playback The LPASS also contains clocks that need to be controlled. Those drivers have been submitted as several separate patch series: * [PATCH v3 0/8] qcom audio clock control drivers http://lkml.org/lkml/2015/1/19/656 * [PATCH] clk: qcom: Properly change rates for ahbix clock https://lkml.org/lkml/2015/2/25/706 * [PATCH] clk: qcom: Fix ipq806x LCC frequency tables https://lkml.org/lkml/2015/2/26/774 Even though the ipq806x LPASS does not contain an audio DSP, other SOCs do have one. For those SOCs, the audio DSP typically controls the hardware blocks in the LPASS. Hence, different CPU DAI driver(s) would need to be used in order to facilitate audio with the DSP. As such, the LPASS DT contains an adsp subnode, which is disabled for this SOC. The same subnode should be enabled and populated for other SOCs that do contain an audio DSP. Not using the audio DSP would require different CPU DAI driver(s), in addition to possible bootloader and/or firmware changes. Corresponding additions to the device tree for the ipq806x SOC and its documentation has also been added. Also, as this is a new directory, the MAINTAINERS file has been updated as well. = Changes since V6 [Patch V6 00/10] ASoC: QCOM: Add support for ipq806x SOC http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088218.html * Added REGMAP_MMIO selection for the CPU and platform drivers * Modified the AHBIX frequency to match the corresponding LCC fix * Tweaked the logging in the CPU driver probe. = Changes since V5 [Patch V5 00/12] ASoC: QCOM: Add support for ipq806x SOC http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/087832.html * Correctly use Storm as the build target label and DT binding label. * Added audio DSP sub-node to the LPASS device tree, disabled for this SOC. * Added logic to CPU DAI driver to fail the probe() if a DSP is present. * Use the standard naming convention for the DAI link properties. * General code cleanup. = Changes since V4 [Patch V4 00/10] ASoC: QCOM: Add support for ipq806x SOC http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/087499.html * Replaced simple-card with a machine driver to resolve the system clock configuration, rather than having the CPU DAI driver do it. * Added header files to avoid indirect header dependencies and implicit forward declarations. * Tweaked the ISR to match the conventions of the surrounding code. * Removed the usage of the low-power memory as it is not needed. * Removed the use of the DRV_NAME constant. * Added explicit dependency on gpiolib for the codec driver. * Moved the MODULE_DEVICE_TABLE macro inside the CONFIG_OF conditional. * Modified the documentation to reflect the changes. * General code cleanup. = Changes since V3 [Patch V3 00/10] ASoC: QCOM: Add support for ipq806x SOC http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085694.html * Placed the content of the inline functions into the callbacks. * Replaced use of readl/writel register access functions with regmap access functions. Notable exception is the ISR, which uses ioread32/iowrite32. * Rearranged the sequencing of the hardware block enables to fit within the ASoC framework callbacks, while remaining functional. REQ 1: The hardware requires the enable sequence to be: LPAIF-DMA[enable],then LPAIF-MI2S[enable], then DAC-GPIO[enable] REQ 2: The hardware requires the disable sequence to be: DAC-GPIO[disable], then LPAIF-MI2S[disable] * Corrected the implementation of the pointer callback. * Utilize the LPM to buffer audio samples, rather than memory external to LPASS. * Corrected the interrupt clearing in the ISR. * Implemented a default system clock (defined by the simple-card DT node), and optional LPASS
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On Tue, Mar 03, 2015 at 04:01:43PM -0800, Stephen Boyd wrote: > On 03/03/15 15:52, Mark Brown wrote: > > ...but of course we'd never try any operations on it anyway as there > > would be no consumers. > Yes sounds fine. The only concern is that we're probably wasting memory > with things that won't ever "match" something in DT. You still get diagnostic output about what the regulator state is which is useful in itself and the amount of memory involved is really not enough to worry about in the grand scheme of things. signature.asc Description: Digital signature
[PATCH 0/2] pinctrl: Introduce support for iodelay module in TI SoCs
Hi, SoCs such as DRA7 family from Texas Instruments also include a highly configurable hardware block called the IOdelay block. This block allows very specific custom fine tuning for electrical characteristics of IO pins that are necessary for functionality and device lifetime requirements. IODelay module exists on it's own register space with registers allocated for various pins. A set of values (derived from either automated tools OR from device datasheet) is then computed on a per-chip basis(to account for die specific variations) to generate a set of delay parameters that are programmed to one or more registers for the delay path of the io line. This is used in specific instances such as MMC to achieve high-throughput modes, and most pins dont usually need tweaking functionality provided by this driver. Even though this kind of operates similar to a pinctrl model, functionally, it is a characteristics tuning which does not completely fit the standard pinconf model either. In addition to the regular pin muxing modes supported by the pinctrl-single, additional configuration for this block for specific pins may also be mandatory in certain cases. Series based on v4.0-rc1 Nishanth Menon (2): pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration pinctrl: Introduce TI IOdelay configuration driver .../bindings/pinctrl/ti,iodelay-pinctrl.txt| 86 ++ drivers/pinctrl/Kconfig| 11 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-ti-iodelay.c | 963 include/dt-bindings/pinctrl/dra.h |6 + 5 files changed, 1067 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-ti-iodelay.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
SoCs such as DRA7 family from Texas Instruments also include a highly
configurable hardware block called the IOdelay block. This block
allows very specific custom fine tuning for electrical characteristics
of IO pins.
In addition to the regular pin muxing modes supported by the
pinctrl-single, additional configuration for this block for specific
pins may also be mandatory in certain cases.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors, which during mux
or IODelay reconfiguration, has a potential for a significant glitch
which may cause functional impairment to certain hardware. It is hence
recommended to do as little of muxing as absolutely necessary without
IO isolation (which can only be done in initial stages of bootloader).
Even with the above limitation, certain functionality such as MMC may
mandate the need of IODelay reconfiguration depending on speed of
transfer. Hence, introduce a new binding to facilitate programming the
same.
Signed-off-by: Nishanth Menon
---
.../bindings/pinctrl/ti,iodelay-pinctrl.txt| 86
1 file changed, 86 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
new file mode 100644
index ..e12f4e5a3f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ti,iodelay-pinctrl.txt
@@ -0,0 +1,86 @@
+Texas Instruments I/O Delay module configuration pinctrl definition
+
+Used in conjunction with
Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt
+
+Required Properties:
+- compatible: Should be:
+ "ti,dra7-iodelay" - I/O delay configuration for DRA7
+- reg - must be the register address range of IODelay module
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Important note: Use of "ti,dra7-iodelay" compatible definition need to be
+carefully evaluated due to the expectation of glitch during configuration.
+
+Example:
+
+dra7_iodelay_core: padconf@4844a000 {
+ compatible = "ti,dra7-iodelay";
+ reg = <0x4844a000 0x0d1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+Configuration definition follows similar model as the pinctrl-single:
+The groups of pin configuration are defined under "pinctrl-single,pins"
+
+&dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+ pinctrl-single,pins = <
+ 0x18c (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A19_IN */
+ 0x1a4 (A_DELAY(265) | G_DELAY(360)) /*
CFG_GPMC_A20_IN */
+ 0x1b0 (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A21_IN */
+ 0x1bc (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A22_IN */
+ 0x1c8 (A_DELAY(287) | G_DELAY(420)) /*
CFG_GPMC_A23_IN */
+ 0x1d4 (A_DELAY(144) | G_DELAY(240)) /*
CFG_GPMC_A24_IN */
+ 0x1e0 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_A25_IN */
+ 0x1ec (A_DELAY(120) | G_DELAY(0)) /*
CFG_GPMC_A26_IN */
+ 0x1f8 (A_DELAY(120) | G_DELAY(180)) /*
CFG_GPMC_A27_IN */
+ 0x360 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_CS1_IN */
+ >;
+ };
+};
+
+Usage in conjunction with pinctrl single:
+
+For a complete description of the pins both the regular muxing as well as the
+iodelay configuration is necessary. For example:
+
+&dra7_pmx_core {
+ mmc2_pins_default: mmc2_pins_default {
+ pinctrl-single,pins = <
+ 0x9c (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a23.mmc2_clk */
+ 0xb0 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_cs1.mmc2_cmd */
+ 0xa0 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a24.mmc2_dat0 */
+ 0xa4 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a25.mmc2_dat1 */
+ 0xa8 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a26.mmc2_dat2 */
+ 0xac (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a27.mmc2_dat3 */
+ 0x8c (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a19.mmc2_dat4 */
+ 0x90 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a20.mmc2_dat5 */
+ 0x94 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a21.mmc2_dat6 */
+ 0x98 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*
gpmc_a22.mmc2_dat7 */
+ >;
+ };
+};
+
+&dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+ pinctrl-single,pins = <
+ 0x18c (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A19_IN */
+
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On 03/03/15 15:52, Mark Brown wrote: > On Tue, Mar 03, 2015 at 02:32:35PM -0800, Bjorn Andersson wrote: >> On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote: >>> How does this work for the case where we may not want to add all the >>> regulators that a PMIC supports. I'm mostly thinking about the case >>> where we want to use the pm8xxx-regulator driver for a few regulators >>> and so we omit them from the DT for the RPM regulators. >> An empty or non-existing regulator of_node will still be registered, but >> without REGULATOR_CHANGE_STATUS nor REGULATOR_CHANGE_VOLTAGE; so any >> operation on this regulator will fail with an -EPERM. > ...but of course we'd never try any operations on it anyway as there > would be no consumers. Yes sounds fine. The only concern is that we're probably wasting memory with things that won't ever "match" something in DT. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
SoC family such as DRA7 family of processors have, in addition
to the regular muxing of pins (as done by pinctrl-single), an
additional hardware module called IODelay which is also expected to be
configured. This "IODelay" module has it's own register space that is
independent of the control module.
It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay reconfiguration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do as little of muxing as absolutely necessary
without I/O isolation (which can only be done in initial stages of
bootloader).
NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
family, it is not reasonable to do stop all I/O operations for every
such pad configuration scheme. So, we will let it glitch when used in
this mode.
Even with the above limitation, certain functionality such as MMC has
mandatory need for IODelay reconfiguration requirements, depending on
speed of transfer. In these cases, with careful examination of usecase
involved, the expected glitch can be controlled such that it does not
impact functionality.
In short, IODelay module support as a padconf driver being introduced
here is not expected to do SoC wide I/O Isolation and is meant for
a limited subset of IODelay configuration requirements that need to
be dynamic and whose glitchy behavior will not cause functionality
failure for that interface.
Signed-off-by: Nishanth Menon
Signed-off-by: Lokesh Vutla
---
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-ti-iodelay.c | 963 ++
include/dt-bindings/pinctrl/dra.h|6 +
4 files changed, 981 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-ti-iodelay.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ee9f44ad7f02..8e463d75fbb2 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -160,6 +160,17 @@ config PINCTRL_TEGRA_XUSB
select PINCONF
select PINMUX
+config PINCTRL_TI_IODELAY
+ bool "TI IODelay Module pinconf driver"
+ depends on OF
+ select PINCONF
+ select GENERIC_PINCONF
+ select REGMAP_MMIO
+ help
+ Say Y here to support Texas Instruments' IODelay pinconf driver.
+ IODelay module is used for the DRA7 SoC family. This driver is in
+ addition to PINCTRL_SINGLE which controls the mux.
+
config PINCTRL_TZ1090
bool "Toumaz Xenif TZ1090 pin control driver"
depends on SOC_TZ1090
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0475206dd600..e441cd71aedf 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
+obj-$(CONFIG_PINCTRL_TI_IODELAY) += pinctrl-ti-iodelay.o
obj-$(CONFIG_PINCTRL_TZ1090) += pinctrl-tz1090.o
obj-$(CONFIG_PINCTRL_TZ1090_PDC) += pinctrl-tz1090-pdc.o
obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
diff --git a/drivers/pinctrl/pinctrl-ti-iodelay.c
b/drivers/pinctrl/pinctrl-ti-iodelay.c
new file mode 100644
index ..e4c6e25a781c
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-ti-iodelay.c
@@ -0,0 +1,963 @@
+/*
+ * Support for configuration of IO Delay module found on Texas Instruments SoCs
+ * such as DRA7
+ *
+ * Copyright (C) 2015 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IODELAY_REG_NAME_LEN ((sizeof(u32) * 2) + 3)
+#define DRIVER_NAME"ti-io-delay"
+/* Should I change this? Abuse? */
+#define IODELAY_MUX_PINS_NAME "pinctrl-single,pins"
+
+/* Device tree match, populated later */
+static const struct of_device_id ti_iodelay_of_match[];
+
+/**
+ * struct ti_iodelay_conf_vals - Description of each configuration parameters.
+ * @offset:Configuration register offset
+ * @a_delay: Agnostic Delay (in ps)
+ * @g_delay: Gnostic Delay (in ps)
+ */
+struct ti_iodelay_conf_vals {
+ u16 offset;
+ u16 a_delay;
+ u16 g_delay;
+};
+
+/**
+ * struct ti_iodelay_reg_data - Describes the registers for the IOdelay
instance
+ * @signature_mask:Conf reg- mask for the signature bits
+ * @signature_value: Conf reg- signature value to be written (see TRM)
+ * @lock_mask: Conf reg- mask for the lock bits
+ * @lock_val: Conf reg- lock value for t
Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hello, I haven't seen any reply to this e-mail. I know that the combination of IOMMU, DMA mapping and DT doesn't exactly sound like fun, but I think we still need to move on :-) Will and Arnd, could you please confirm that my summary below matches your memories of our discussion ? On Monday 16 February 2015 18:14:45 Laurent Pinchart wrote: > On Thursday 05 February 2015 16:31:58 Laura Abbott wrote: > > Hi, > > > > On the heels of Exynos integrating SMMU in to the DT for probing, > > this series attempts to add support to make SMMU drivers work with > > deferred probing. This has been referenced before[1] but this is > > some actual code to use as a starting point for discussion. > > > > The requirement for this is based on a previous patch to add clock > > support to the ARM SMMU driver[2]. Once we have clock support, it's > > possible that the driver itself may need to be defered which breaks > > a bunch of assumptions about how SMMU probing is supposed to work. > > The concept here is to have the driver call of_dma_configure which > > may return -EPROBE_DEFER. of_dma_configure could possibly be moved > > up to probe level. The existing method of initialization still needs > > to be done as well which might mean we have the worst of both worlds. > > > > Open questions: > > - This still doesn't really address Arnd's concerns[3] about disabling > > IOMMUs > > Arnd, Will and I have discussed IOMMU probe deferral last week. Here's a > summary of the discussion, before the details blur away. > > The discussion covered both higher level concepts and lower level details, > in various directions. I'll try to make the summary clear by filling the > gaps between pieces where needed, so some of the information below might > not be a direct result of the discussions. Arnd and Will, please feel free > to correct me. > > The first question we've discussed was whether probe deferral for IOMMUs is > really needed. Various dependencies between IOMMU devices and other devices > exist, in particular on clocks (as you have mentioned above) and on power > domains (as mentioned by Marek in > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323238. > html). While there are mechanism to handle some of them with probe deferral > (for instance by using the OF_DECLARE macros to register clock drivers), > generalizing those mechanisms would essentially recreate a probe ordering > mechanism similar to link order probe ordering and couldn't really scale. > > Additionally, IOMMUs could also be present hot-pluggable devices and depend > on resources that are thus hot-plugged. OF_DECLARE wouldn't help in that > case. For all those reasons we have concluded that probe deferral for > IOMMUs is desired if it can be implemented cleanly. > > The second question we've discussed was how to implement probe deferral > cleanly :-) > > The current implementation configures DMA at device creation time and sets > the following properties: > > - dma_map_ops (IOMMU, SWIOTLB, linear mapping) > - initial DMA mask > - DMA offset > - DMA coherency > > Additionally the IOMMU group (when an IOMMU is present) will also be > configured at the same time (patches are under review). > > The base idea is to defer probing of bus master devices when their IOMMU > isn't present. Three cases need to be handled. > > 1. No IOMMU is declared by the firmware (through DT, ACPI, ...) for the bus > master device. The bus master device probe doesn't need to be deferred due > to the IOMMU. dma_map_ops must be set to SWIOTLB or linear mapping (the > later should likely be implemented through SWIOTLB). > > 2. An IOMMU is declared for the bus master device and the IOMMU has been > successfully probed and registered. The bus master device probe doesn't need > to be deferred due to the IOMMU. dma_map_ops must be set to IOMMU ops. > > 3. An IOMMU is declared for the bus master device but the IOMMU isn't > registered. This can be caused by different reasons: > > - a. No driver is loaded for this IOMMU (for instance because DT describes > the IOMMU connection, but the IOMMU driver hasn't been developed yet, or an > older kernel is used). If the IOMMU is optional the bus master device probe > should succeed, and dma_map_ops should be set to linear. If the IOMMU is > mandatory the bus master device probe should fail. > > Note that, as we require IOMMU drivers to be compiled in, we don't need to > handle the case of loadable IOMMU drivers that haven't been loaded yet. > > - b. A driver is loaded for this IOMMU but the IOMMU hasn't been probed yet, > or its probe has been deferred. The bus master device probe should be > deferred. > > - c. A driver is loaded for this IOMMU but the IOMMU probe has failed > permanently. It's not clear at the moment whether we should try to recover > from this automatically using the same mechanism as case 3.a, or if we can > considered this as an abnormal failure and disable the bus master device. > > Assuming th
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On Tue, Mar 03, 2015 at 02:32:35PM -0800, Bjorn Andersson wrote: > On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote: > > How does this work for the case where we may not want to add all the > > regulators that a PMIC supports. I'm mostly thinking about the case > > where we want to use the pm8xxx-regulator driver for a few regulators > > and so we omit them from the DT for the RPM regulators. > An empty or non-existing regulator of_node will still be registered, but > without REGULATOR_CHANGE_STATUS nor REGULATOR_CHANGE_VOLTAGE; so any > operation on this regulator will fail with an -EPERM. ...but of course we'd never try any operations on it anyway as there would be no consumers. signature.asc Description: Digital signature
Re: [PATCH 1/4] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On 03/03/15 14:17, Bjorn Andersson wrote: > On Tue 03 Mar 14:02 PST 2015, Stephen Boyd wrote: > >> On 03/03/15 13:54, Bjorn Andersson wrote: >>> On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: >>> On 03/02/15 20:25, Bjorn Andersson wrote: >>> [..] > + > +- vin_l1_l2_l12_l18-supply: > +- vin_l24-supply: > +- vin_l25-supply: > +- vin_l27-supply: > +- vin_l28-supply: > +- vin_lvs_1_3_6-supply: > +- vin_lvs2-supply: > +- vin_lvs_4_5_7-supply: > +- vin_ncp-supply: Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I left out? It looks like you've covered all the inputs for the other pmics. >>> Sorry, I had problems finding the information in the rather sparse >>> documentation I have for the 8921, so I just assumed that I could steal >>> your list. >>> >>> I finally managed to find the pinout diagram, so the correct list for >>> pm8921 seems to be: >>> >>> - vdd_l1_2_12_18-supply >>> - vdd_l3_15_17-supply >>> - vdd_l5_8_16-supply >> vin_l4-supply? >> > Ahh, right, I missed the vdd_l4_l14 pad. > >>> - vdd_l6_7-supply >>> - vdd_l9_11-supply >>> - vdd_l10_22-supply >>> - vdd_l21_23_29-supply >> Also these seem to be vin_l21_l23_l29 where "l" precedes all numbers >> (for all the LDOs). >> > The other pmics name their inputs like that; should we just pick that > naming scheme for all these supplies and be happy? Ok. >>> - vdd_l24-supply >>> - vdd_l25-supply >>> - vdd_l26-supply >>> - vdd_l27-supply >>> - vdd_l28-supply >>> - vdd_ncp-supply >>> - vdd_s1-supply >>> - vdd_s2-supply >>> - vdd_s4-supply >>> - vdd_s5-supply >>> - vdd_s6-supply >>> - vdd_s7-supply >>> - vdd_s8-supply >>> - vin_lvs1_3_6-supply >>> - vin_lvs2-supply >>> - vin_lvs4_5_7-supply >>> >>> I will send out an updated patch with these. >> s/vdd/vin/ seems to match my datasheet. >> > For all of these? Same with the other pmics? > > These are the documented pad names that I have, nice to see that they > are named differently in different documents. Oh. I seem to have been looking at some pre-published doc that was still laying around. vdd seems to match the official documentation so that sounds good to me. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v7] of: Move of_dma_configure() to device.c to help re-use
On 03/03/2015 03:53 PM, Bjorn Helgaas wrote: [+cc linux-pci] On Tue, Mar 3, 2015 at 11:55 AM, Murali Karicheri wrote: On 03/02/2015 10:43 PM, Bjorn Helgaas wrote: On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri wrote: Move of_dma_configure() to device.c so it can be re-used for PCI devices to obtain DMA configuration from DT. Also add a second argument so that for PCI, the DT node of root bus host bridge can be used to obtain the DMA configuration for the slave PCI device. Tested-by: Suravee Suthikulpanit (AMD Seattle) Signed-off-by: Murali Karicheri Signed-off-by: Bjorn Helgaas Reviewed-by: Catalin Marinas Acked-by: Will Deacon CC: Joerg Roedel CC: Grant Likely CC: Rob Herring CC: Russell King CC: Arnd Bergmann --- - Based on the existing patch applied to arm-pci/pci/iommu for pci next (Bjorn) - Fixed the build issue reported on ARCH=x86_64 Hi Murali, Can you please repost the entire series with fixed patches? It's easier for me to reapply the whole thing at once than it is to keep track of and fiddle with individual patches. Bjorn Bjorn, Ok. I have just posted v8 of the series including all patches. Thanks, I put them on a pci/murali-v8 branch for now. I'm assuming you want them to go through my tree. In the cover letter, you mentioned the "arm-pci iommu branch", so if that means you want them via an ARM tree instead of mine, just let me know. I assume the build will be clean and I'll rename it back to pci/iommu. My bad. It should have beem pci/iommu. My remote was named arm-pci and hence the confusion. Please apply it to the pci/iommu branch. Thanks Murali Bjorn -- Murali Karicheri Linux Kernel, Texas Instruments -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote:
> On 03/02/15 20:25, Bjorn Andersson wrote:
> > - config.of_node = pdev->dev.of_node;
> > +static int rpm_reg_probe(struct platform_device *pdev)
> > +{
> > + const struct rpm_regulator_data *reg;
> > + const struct of_device_id *match;
> > + struct regulator_config config = { };
> > + struct regulator_dev *rdev;
> > + struct qcom_rpm_reg *vreg;
> >
> > - ret = rpm_reg_of_parse(pdev->dev.of_node, &vreg->desc,
> > - &config, initdata);
> > - if (ret)
> > - return ret;
> > + match = of_match_device(rpm_of_match, &pdev->dev);
> > + for (reg = match->data; reg->name; reg++) {
>
> How does this work for the case where we may not want to add all the
> regulators that a PMIC supports. I'm mostly thinking about the case
> where we want to use the pm8xxx-regulator driver for a few regulators
> and so we omit them from the DT for the RPM regulators.
>
An empty or non-existing regulator of_node will still be registered, but
without REGULATOR_CHANGE_STATUS nor REGULATOR_CHANGE_VOLTAGE; so any
operation on this regulator will fail with an -EPERM.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On Tue 03 Mar 14:02 PST 2015, Stephen Boyd wrote: > On 03/03/15 13:54, Bjorn Andersson wrote: > > On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: > > > >> On 03/02/15 20:25, Bjorn Andersson wrote: > > [..] > >>> + > >>> +- vin_l1_l2_l12_l18-supply: > >>> +- vin_l24-supply: > >>> +- vin_l25-supply: > >>> +- vin_l27-supply: > >>> +- vin_l28-supply: > >>> +- vin_lvs_1_3_6-supply: > >>> +- vin_lvs2-supply: > >>> +- vin_lvs_4_5_7-supply: > >>> +- vin_ncp-supply: > >> Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I > >> left out? It looks like you've covered all the inputs for the other pmics. > >> > > Sorry, I had problems finding the information in the rather sparse > > documentation I have for the 8921, so I just assumed that I could steal > > your list. > > > > I finally managed to find the pinout diagram, so the correct list for > > pm8921 seems to be: > > > > - vdd_l1_2_12_18-supply > > - vdd_l3_15_17-supply > > - vdd_l5_8_16-supply > > vin_l4-supply? > Ahh, right, I missed the vdd_l4_l14 pad. > > - vdd_l6_7-supply > > - vdd_l9_11-supply > > - vdd_l10_22-supply > > - vdd_l21_23_29-supply > > Also these seem to be vin_l21_l23_l29 where "l" precedes all numbers > (for all the LDOs). > The other pmics name their inputs like that; should we just pick that naming scheme for all these supplies and be happy? > > - vdd_l24-supply > > - vdd_l25-supply > > - vdd_l26-supply > > - vdd_l27-supply > > - vdd_l28-supply > > - vdd_ncp-supply > > - vdd_s1-supply > > - vdd_s2-supply > > - vdd_s4-supply > > - vdd_s5-supply > > - vdd_s6-supply > > - vdd_s7-supply > > - vdd_s8-supply > > - vin_lvs1_3_6-supply > > - vin_lvs2-supply > > - vin_lvs4_5_7-supply > > > > I will send out an updated patch with these. > > s/vdd/vin/ seems to match my datasheet. > For all of these? Same with the other pmics? These are the documented pad names that I have, nice to see that they are named differently in different documents. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 6/8] v4l: xilinx: Add Xilinx Video IP core
Hi Hans,
Thank you for the review.
On Tuesday 03 March 2015 12:28:24 Hans Verkuil wrote:
> Hi Laurent,
>
> Thanks for this patch. I do have a few comments, see below. Note that I am
> OK with the new DT format description.
>
> On 03/02/2015 02:48 AM, Laurent Pinchart wrote:
> > Xilinx platforms have no hardwired video capture or video processing
> > interface. Users create capture and memory to memory processing
> > pipelines in the FPGA fabric to suit their particular needs, by
> > instantiating video IP cores from a large library.
> >
> > The Xilinx Video IP core is a framework that models a video pipeline
> > described in the device tree and expose the pipeline to userspace
> > through the media controller and V4L2 APIs.
> >
> > Signed-off-by: Laurent Pinchart
> > Signed-off-by: Hyun Kwon
> > Signed-off-by: Radhey Shyam Pandey
> > Signed-off-by: Michal Simek
> >
> > ---
>
>
>
> > diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
> > b/drivers/media/platform/xilinx/xilinx-dma.c new file mode 100644
> > index 000..afed6c3
> > --- /dev/null
> > +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> > @@ -0,0 +1,753 @@
[snip]
> > +static void xvip_dma_complete(void *param)
> > +{
> > + struct xvip_dma_buffer *buf = param;
> > + struct xvip_dma *dma = buf->dma;
> > +
> > + spin_lock(&dma->queued_lock);
> > + list_del(&buf->queue);
> > + spin_unlock(&dma->queued_lock);
> > +
> > + buf->buf.v4l2_buf.sequence = dma->sequence++;
>
> buf->buf.v4l2_buf.field isn't set. I think you only support progressive
> formats at the moment, so this should be set to V4L2_FIELD_NONE.
Agreed, that was an oversight. I'll fix it.
> > + v4l2_get_timestamp(&buf->buf.v4l2_buf.timestamp);
> > + vb2_set_plane_payload(&buf->buf, 0, dma->format.sizeimage);
> > + vb2_buffer_done(&buf->buf, VB2_BUF_STATE_DONE);
> > +}
> > +
> > +static int
> > +xvip_dma_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
> > +unsigned int *nbuffers, unsigned int *nplanes,
> > +unsigned int sizes[], void *alloc_ctxs[])
> > +{
> > + struct xvip_dma *dma = vb2_get_drv_priv(vq);
> > +
> > + *nplanes = 1;
> > +
> > + sizes[0] = dma->format.sizeimage;
>
> I would suggest that you add support for vb2_ioctl_create_bufs by changing
> this code to:
>
> if (fmt && fmt->fmt.pix.sizeimage < dma->format.sizeimage)
> return -EINVAL;
> sizes[0] = fmt ? fmt->fmt.pix.sizeimage : dma->format.sizeimage;
Looks good, I'll fix that.
> > + alloc_ctxs[0] = dma->alloc_ctx;
> > +
> > + return 0;
> > +}
[snip]
> > +static int xvip_dma_start_streaming(struct vb2_queue *vq, unsigned int
> > count) +{
> > + struct xvip_dma *dma = vb2_get_drv_priv(vq);
> > + struct xvip_dma_buffer *buf, *nbuf;
> > + struct xvip_pipeline *pipe;
> > + int ret;
> > +
> > + dma->sequence = 0;
> > +
> > + /*
> > +* Start streaming on the pipeline. No link touching an entity in the
> > +* pipeline can be activated or deactivated once streaming is
started.
> > +*
> > +* Use the pipeline object embedded in the first DMA object that
starts
> > +* streaming.
> > +*/
> > + pipe = dma->video.entity.pipe
> > +? to_xvip_pipeline(&dma->video.entity) : &dma->pipe;
> > +
> > + ret = media_entity_pipeline_start(&dma->video.entity, &pipe->pipe);
> > + if (ret < 0)
> > + goto error;
> > +
> > + /* Verify that the configured format matches the output of the
> > +* connected subdev.
> > +*/
> > + ret = xvip_dma_verify_format(dma);
> > + if (ret < 0)
> > + goto error_stop;
> > +
> > + ret = xvip_pipeline_prepare(pipe, dma);
> > + if (ret < 0)
> > + goto error_stop;
> > +
> > + /* Start the DMA engine. This must be done before starting the blocks
> > +* in the pipeline to avoid DMA synchronization issues.
> > +*/
> > + dma_async_issue_pending(dma->dma);
>
> Question: can the DMA engine be started without any buffers queued?
Yes. In that case the dma_async_issue_pending() call will be a no-op, as there
will be no pending DMA transfer queued.
> The vb2_queue struct has a min_buffers_needed field that can be set to a
> non-zero value. In that case start_streaming won't be called until at least
> that many buffers have been queued. Many DMA engines need that so this was
> added to the vb2 core to avoid having to hack around this in the driver.
I don't see a need for that here. I actually think the min_buffers_needed
field shouldn't be set, even if it could be set to 1, to avoid reporting
VIDIOC_STREAMON errors at VIDIOC_QBUF time. The alternative would be to move
the validation code to a custom .video_streamon handler, but that seems
pointless to me.
> > +
> > + /* Start the pipeline. */
> > + xvip_pipeline_set_stream(pipe, true);
> > +
> > + return 0;
> > +
> > +error_stop:
> > + media_entity_pipeline_stop(&dma->video.entity);
> > +
> > +error:
> > + /* Give back all que
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On 03/02/15 20:25, Bjorn Andersson wrote:
> - config.of_node = pdev->dev.of_node;
> +static int rpm_reg_probe(struct platform_device *pdev)
> +{
> + const struct rpm_regulator_data *reg;
> + const struct of_device_id *match;
> + struct regulator_config config = { };
> + struct regulator_dev *rdev;
> + struct qcom_rpm_reg *vreg;
>
> - ret = rpm_reg_of_parse(pdev->dev.of_node, &vreg->desc,
> -&config, initdata);
> - if (ret)
> - return ret;
> + match = of_match_device(rpm_of_match, &pdev->dev);
> + for (reg = match->data; reg->name; reg++) {
How does this work for the case where we may not want to add all the
regulators that a PMIC supports. I'm mostly thinking about the case
where we want to use the pm8xxx-regulator driver for a few regulators
and so we omit them from the DT for the RPM regulators.
-Stephen
> + vreg = devm_kmalloc(&pdev->dev, sizeof(*vreg), GFP_KERNEL);
> + if (!vreg) {
> + dev_err(&pdev->dev, "failed to allocate vreg\n");
> + return -ENOMEM;
> + }
> + memcpy(vreg, reg->template, sizeof(*vreg));
> + mutex_init(&vreg->lock);
> +
> + vreg->dev = &pdev->dev;
> + vreg->resource = reg->resource;
> +
> + vreg->desc.id = -1;
> + vreg->desc.owner = THIS_MODULE;
> + vreg->desc.type = REGULATOR_VOLTAGE;
> + vreg->desc.name = reg->name;
> + vreg->desc.supply_name = reg->supply;
> + vreg->desc.of_match = reg->name;
> + vreg->desc.of_parse_cb = rpm_reg_of_parse;
> +
> + vreg->rpm = dev_get_drvdata(pdev->dev.parent);
> + if (!vreg->rpm) {
> + dev_err(&pdev->dev, "unable to retrieve handle to
> rpm\n");
> + return -ENODEV;
> + }
>
> - rdev = devm_regulator_register(&pdev->dev, &vreg->desc, &config);
> - if (IS_ERR(rdev)) {
> - dev_err(&pdev->dev, "can't register regulator\n");
> - return PTR_ERR(rdev);
> + config.dev = &pdev->dev;
> + config.driver_data = vreg;
> + rdev = devm_regulator_register(&pdev->dev, &vreg->desc,
> &config);
> + if (IS_ERR(rdev)) {
> + dev_err(&pdev->dev, "can't register regulator\n");
> + return PTR_ERR(rdev);
> + }
> }
>
> return 0;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] regulator: qcom: Refactor of-parsing code
On Tue 03 Mar 10:56 PST 2015, Stephen Boyd wrote:
> On 03/02/15 20:25, Bjorn Andersson wrote:
> > +
> > +static int rpm_reg_probe(struct platform_device *pdev)
> > +{
> > + struct regulator_init_data *initdata;
> > + const struct qcom_rpm_reg *template;
> > + const struct of_device_id *match;
> > + struct regulator_config config = { };
> > + struct regulator_dev *rdev;
> > + struct qcom_rpm_reg *vreg;
> > + const char *key;
> > + u32 val;
> > + int ret;
> > +
> > + match = of_match_device(rpm_of_match, &pdev->dev);
> > + template = match->data;
> > +
> > + vreg = devm_kmalloc(&pdev->dev, sizeof(*vreg), GFP_KERNEL);
> > + if (!vreg) {
> > + dev_err(&pdev->dev, "failed to allocate vreg\n");
>
> We don't need error messages on allocation failures.
>
Right, it's just that I wanted to keep these patches free from any
unrelated changes. I can add an extra patch at the end removing this and
moving the retrieval of rpm out of the for loop.
> > + return -ENOMEM;
> > + }
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On 03/03/15 13:54, Bjorn Andersson wrote: > On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: > >> On 03/02/15 20:25, Bjorn Andersson wrote: > [..] >>> + >>> +- vin_l1_l2_l12_l18-supply: >>> +- vin_l24-supply: >>> +- vin_l25-supply: >>> +- vin_l27-supply: >>> +- vin_l28-supply: >>> +- vin_lvs_1_3_6-supply: >>> +- vin_lvs2-supply: >>> +- vin_lvs_4_5_7-supply: >>> +- vin_ncp-supply: >> Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I >> left out? It looks like you've covered all the inputs for the other pmics. >> > Sorry, I had problems finding the information in the rather sparse > documentation I have for the 8921, so I just assumed that I could steal > your list. > > I finally managed to find the pinout diagram, so the correct list for > pm8921 seems to be: > > - vdd_l1_2_12_18-supply > - vdd_l3_15_17-supply > - vdd_l5_8_16-supply vin_l4-supply? > - vdd_l6_7-supply > - vdd_l9_11-supply > - vdd_l10_22-supply > - vdd_l21_23_29-supply Also these seem to be vin_l21_l23_l29 where "l" precedes all numbers (for all the LDOs). > - vdd_l24-supply > - vdd_l25-supply > - vdd_l26-supply > - vdd_l27-supply > - vdd_l28-supply > - vdd_ncp-supply > - vdd_s1-supply > - vdd_s2-supply > - vdd_s4-supply > - vdd_s5-supply > - vdd_s6-supply > - vdd_s7-supply > - vdd_s8-supply > - vin_lvs1_3_6-supply > - vin_lvs2-supply > - vin_lvs4_5_7-supply > > I will send out an updated patch with these. s/vdd/vin/ seems to match my datasheet. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: > On 03/02/15 20:25, Bjorn Andersson wrote: [..] > > + > > +- vin_l1_l2_l12_l18-supply: > > +- vin_l24-supply: > > +- vin_l25-supply: > > +- vin_l27-supply: > > +- vin_l28-supply: > > +- vin_lvs_1_3_6-supply: > > +- vin_lvs2-supply: > > +- vin_lvs_4_5_7-supply: > > +- vin_ncp-supply: > > Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I > left out? It looks like you've covered all the inputs for the other pmics. > Sorry, I had problems finding the information in the rather sparse documentation I have for the 8921, so I just assumed that I could steal your list. I finally managed to find the pinout diagram, so the correct list for pm8921 seems to be: - vdd_l1_2_12_18-supply - vdd_l3_15_17-supply - vdd_l5_8_16-supply - vdd_l6_7-supply - vdd_l9_11-supply - vdd_l10_22-supply - vdd_l21_23_29-supply - vdd_l24-supply - vdd_l25-supply - vdd_l26-supply - vdd_l27-supply - vdd_l28-supply - vdd_ncp-supply - vdd_s1-supply - vdd_s2-supply - vdd_s4-supply - vdd_s5-supply - vdd_s6-supply - vdd_s7-supply - vdd_s8-supply - vin_lvs1_3_6-supply - vin_lvs2-supply - vin_lvs4_5_7-supply I will send out an updated patch with these. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v7] of: Move of_dma_configure() to device.c to help re-use
[+cc linux-pci] On Tue, Mar 3, 2015 at 11:55 AM, Murali Karicheri wrote: > On 03/02/2015 10:43 PM, Bjorn Helgaas wrote: >> >> On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri >> wrote: >>> >>> Move of_dma_configure() to device.c so it can be re-used for PCI devices >>> to >>> obtain DMA configuration from DT. Also add a second argument so that for >>> PCI, the DT node of root bus host bridge can be used to obtain the DMA >>> configuration for the slave PCI device. >>> >>> Tested-by: Suravee Suthikulpanit (AMD >>> Seattle) >>> Signed-off-by: Murali Karicheri >>> Signed-off-by: Bjorn Helgaas >>> Reviewed-by: Catalin Marinas >>> Acked-by: Will Deacon >>> CC: Joerg Roedel >>> CC: Grant Likely >>> CC: Rob Herring >>> CC: Russell King >>> CC: Arnd Bergmann >>> --- >>> - Based on the existing patch applied to arm-pci/pci/iommu for pci next >>> (Bjorn) >>> - Fixed the build issue reported on ARCH=x86_64 >> >> >> Hi Murali, >> >> Can you please repost the entire series with fixed patches? It's >> easier for me to reapply the whole thing at once than it is to keep >> track of and fiddle with individual patches. >> >> Bjorn > > Bjorn, > > Ok. I have just posted v8 of the series including all patches. Thanks, I put them on a pci/murali-v8 branch for now. I'm assuming you want them to go through my tree. In the cover letter, you mentioned the "arm-pci iommu branch", so if that means you want them via an ARM tree instead of mine, just let me know. I assume the build will be clean and I'll rename it back to pci/iommu. Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] of: calculate masks of the device based on dma-range size
On Tue, Mar 03, 2015 at 12:59:52PM -0500, Murali Karicheri wrote: > On 02/25/2015 07:20 PM, Bjorn Helgaas wrote: > >[+cc Catalin] > > > >On Wed, Feb 11, 2015 at 12:53:35PM -0500, Murali Karicheri wrote: > >>This patch update of_dma_configure() API to calculate the > >>masks (dma_mask and coherent_dma_mask) based on the dma-range > >>values set in DT for the device. Also limit the mask to lower > >>of the default mask and mask calculated. > >> > >>Cc: Joerg Roedel > >>Cc: Grant Likely > >>Cc: Rob Herring > >>Cc: Bjorn Helgaas > >>Cc: Will Deacon > >>Cc: Russell King > >>Cc: Arnd Bergmann > >>Cc: Suravee Suthikulpanit > >> > >>Signed-off-by: Murali Karicheri > > > >Applied with Catalin's reviewed-by to pci/iommu for v4.1, thanks! > Bjorn, > > Could you point me to this? I didn't see it on pci/iommu of your repo below. > > arm-pci git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > (fetch) > > a0868495@ula0868495 ~/Project/linux-keystone $ gitlog arm-pci/pci/iommu > dd8a11b0f0d4ed0ad87c8d09e650f354021d7953 arm: dma-mapping: limit > IOMMU mapping size > 2a101e79dcd8733e3a353b0df2fa384980f94e1e PCI: Update DMA > configuration from DT > 3fd29d06e9aa92d9a4513e14b2dd3f0d69d4d2b7 of/pci: Add > of_pci_dma_configure() to update DMA configuration > 8243352097c468f982a9f386cb1f455672b473a2 PCI: Add helper functions > pci_get[put]_host_bridge_device() > 039f346ac880d4f894425ef6c540f3ff5c1b8dcf of: Fix size when dma-range > is not used > 2743a957f6a6317be06d02cc93d78bb2a847e427 of: Move of_dma_configure() > to device.c to help re-use > f454cd01b5bdffb1bf26a5cddac30439fa5f27a1 of: iommu: Add ptr to OF > node arg to of_iommu_configure() > c517d838eb7d07bbe9507871fab3931deccff539 Linux 4.0-rc1 I had applied it to my local branch, but not pushed it to kernel.org. I applied it along with the "get DMA configuration from parent device" series to pci/murali-v8 and pushed it for build testing. Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10 v2] usb: Make sure that DWC2 initializes after the power channel mailbox driver.
This gets USB working on the Raspberry Pi without relying on U-Boot to
send the power message for us. Without it, you would get warnings
about fifo sizes and "dwc2_core_reset() HANG! Soft Reset
GRSTCTL=8001" leading to a failed probe.
v2: Make the export of the has-the-mailbox-driver-loaded bool be
through a function call defined in include/linux/platform/
Signed-off-by: Eric Anholt
Cc: John Youn
---
This would be the first include file in include/linux/platform/. Is
that the right place? I see a few
arch/arm/mach-*/include/mach/platform.h files -- would that or
arch/arm/mach-bcm/include/mach/bcm2835-platform.h possibly be the right
place instead?
Also, Lee, since you mostly typed the contents of that header, should
your SoB go on this?
drivers/mailbox/bcm2835-mailbox-power.c | 11 +++
drivers/usb/dwc2/platform.c | 8
include/linux/platform/bcm2835.h| 18 ++
3 files changed, 37 insertions(+)
create mode 100644 include/linux/platform/bcm2835.h
diff --git a/drivers/mailbox/bcm2835-mailbox-power.c
b/drivers/mailbox/bcm2835-mailbox-power.c
index f09c855..a3ed773 100644
--- a/drivers/mailbox/bcm2835-mailbox-power.c
+++ b/drivers/mailbox/bcm2835-mailbox-power.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define BCM_POWER_USB (1 << 3)
#define BCM_MBOX_DATA_SHIFT 4
@@ -31,6 +32,14 @@ struct bcm_mbox_power {
uint32_t response;
};
+static bool bcm2835_mbox_power_initialized;
+
+bool bcm2835_mbox_is_usb_powered(void)
+{
+ return bcm2835_mbox_power_initialized;
+}
+EXPORT_SYMBOL_GPL(bcm2835_mbox_is_usb_powered);
+
struct bcm_mbox_power *mbox_power;
static void response_callback(struct mbox_client *cl, void *mssg)
@@ -92,6 +101,7 @@ static int bcm2835_mbox_power_probe(struct platform_device
*pdev)
bcm_mbox_set_power(BCM_POWER_USB);
bcm2835_mbox_power_initialized = true;
}
+ bcm2835_mbox_power_initialized = true;
return ret;
}
@@ -99,6 +109,7 @@ static int bcm2835_mbox_power_probe(struct platform_device
*pdev)
static int bcm2835_mbox_power_remove(struct platform_device *pdev)
{
bcm_mbox_set_power(0);
+ bcm2835_mbox_power_initialized = false;
mbox_free_channel(mbox_power->chan);
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index ae095f0..caca216 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
@@ -175,6 +176,13 @@ static int dwc2_driver_probe(struct platform_device *dev)
defparams.dma_desc_enable = 0;
}
+ /*
+* Make sure the platform driver for enabling the power has
+* initialized before we do.
+*/
+ if (params == ¶ms_bcm2835 && !bcm2835_is_usb_powered())
+ return -EPROBE_DEFER;
+
hsotg = devm_kzalloc(&dev->dev, sizeof(*hsotg), GFP_KERNEL);
if (!hsotg)
return -ENOMEM;
diff --git a/include/linux/platform/bcm2835.h b/include/linux/platform/bcm2835.h
new file mode 100644
index 000..a97d938
--- /dev/null
+++ b/include/linux/platform/bcm2835.h
@@ -0,0 +1,18 @@
+#ifdef CONFIG_BCM2835_MBOX
+bool bcm2835_mbox_is_usb_powered(void);
+
+static inline bool bcm2835_is_usb_powered(void)
+{
+ return bcm2835_mbox_is_usb_powered();
+}
+#else
+static inline bool bcm2835_is_usb_powered(void)
+{
+ /*
+* If BCM2835 isn't using its Mailbox driver, the bootloader
+* is charged with powering up USB.
+*/
+ return true;
+}
+#endif
+
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: sun7i: dt: Add new MK808C device
Thanks for the review Maxime,
On 3 March 2015 at 08:13, Maxime Ripard
wrote:
> Hi,
>
> On Sat, Feb 28, 2015 at 02:43:24PM +0100, codekip...@gmail.com wrote:
>> From: Marcus Cooper
>>
>> The MK808C is an A20 based android stick, with 1G RAM, 8G NAND flash,
>> a RTL8723au wifi + bt combo chip, a USB host ports using USB-A receptacles,
>> a mini USB-B receptacle for USB OTG, mini HDMI and a TRS connector for AV.
>>
>> This patch adds basic support for the device, more information can be found
>> here (http://linux-sunxi.org/MK808C).
>>
>> Signed-off-by: Marcus Cooper
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/sun7i-a20-mk808c.dts | 146
>> +
>> 2 files changed, 147 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-mk808c.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 9544768..eae7706 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -542,6 +542,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-hummingbird.dtb \
>> sun7i-a20-i12-tvbox.dtb \
>> sun7i-a20-m3.dtb \
>> + sun7i-a20-mk808c.dtb \
>> sun7i-a20-olinuxino-lime.dtb \
>> sun7i-a20-olinuxino-lime2.dtb \
>> sun7i-a20-olinuxino-micro.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-mk808c.dts
>> b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
>> new file mode 100644
>> index 000..5722a03
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
>> @@ -0,0 +1,146 @@
>> +/*
>> + * Copyright 2015 Marcus Cooper
>> + *
>> + * Marcus Cooper
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file 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.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public
>> + * License along with this file; if not, write to the Free
>> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
>> + * MA 02110-1301 USA
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include
>> +#include
>> +#include
>
> You don't seem to be using the pinctrl header.
>
I'll remove this
>> +
>> +/ {
>> + model = "mk808c";
>> + compatible = "mk808c", "allwinner,sun7i-a20";
>
> the compatible must be of the format "vendor,device". Please add the
> vendor name.
AhhhI've searched high and low for a vendors name. I listed it as
unknown on the wiki page,
would 'odm' be considered valid?
CK
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/18] clocksource: Add ARM System timer driver
Maxime Coquelin schreef op ma 02-03-2015 om 17:53 [+0100]: > Do you agree if I define it like this: > > config ARMV7M_SYSTICK > bool "Clocksource driver for ARMv7-M System timer" > depends on OF && (CPU_V7M || COMPILE_TEST) > select CLKSRC_OF > select CLKSRC_MMIO > help > This options enables clocksource support for the ARMv7-M system > timer unit. I don't really have strong feelings on whatever way you choose to fix the, well, minor problem I pointed out. Having said that, if a Kconfig entry without a prompt (and therefor, without help) actually does what you want it to do, why bother adding a prompt and a one line help text? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] dtb: change binding name to match with newer firmware DT
This patch fixes the backward compatibility of the older driver with the
newer firmware by making the binding unique so that the older driver won't
recognize the non-supported interfaces.
The new bindings are in sync with the newer firmware.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Keyur Chudgar
Tested-by: Mark Langsdorf
---
arch/arm64/boot/dts/apm/apm-storm.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index f1ad9c2..a857794 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -622,7 +622,7 @@
};
sgenet0: ethernet@1f21 {
- compatible = "apm,xgene-enet";
+ compatible = "apm,xgene1-sgenet";
status = "disabled";
reg = <0x0 0x1f21 0x0 0xd100>,
<0x0 0x1f20 0x0 0Xc300>,
@@ -636,7 +636,7 @@
};
xgenet: ethernet@1f61 {
- compatible = "apm,xgene-enet";
+ compatible = "apm,xgene1-xgenet";
status = "disabled";
reg = <0x0 0x1f61 0x0 0xd100>,
<0x0 0x1f60 0x0 0Xc300>,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] drivers: net: xgene: fix new firmware backward compatibility with older driver
This patch fixes the backward compatibile of the older driver with the
newer firmware by making the binding unique so that the older driver won't
recognize the non-supported interfaces.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Keyur Chudgar
Tested-by: Mark Langsdorf
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 4de62b2..635a83b 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1025,6 +1025,8 @@ static int xgene_enet_remove(struct platform_device *pdev)
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgene_enet_acpi_match[] = {
{ "APMC0D05", },
+ { "APMC0D30", },
+ { "APMC0D31", },
{ }
};
MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
@@ -1033,6 +1035,8 @@ MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
#ifdef CONFIG_OF
static struct of_device_id xgene_enet_of_match[] = {
{.compatible = "apm,xgene-enet",},
+ {.compatible = "apm,xgene1-sgenet",},
+ {.compatible = "apm,xgene1-xgenet",},
{},
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] Documentation: dts: Update compatible field description for APM X-Gene
Signed-off-by: Iyappan Subramanian Signed-off-by: Keyur Chudgar Tested-by: Mark Langsdorf --- Documentation/devicetree/bindings/net/apm-xgene-enet.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt index cfcc527..6151999 100644 --- a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt +++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt @@ -4,7 +4,10 @@ Ethernet nodes are defined to describe on-chip ethernet interfaces in APM X-Gene SoC. Required properties for all the ethernet interfaces: -- compatible: Should be "apm,xgene-enet" +- compatible: Should state binding information from the following list, + - "apm,xgene-enet":RGMII based 1G interface + - "apm,xgene1-sgenet": SGMII based 1G interface + - "apm,xgene1-xgenet": XFI based 10G interface - reg: Address and length of the register set for the device. It contains the information of registers in the same order as described by reg-names - reg-names: Should contain the register set names -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] drivers: net: xgene: Fix backward compatibility of newer firmware with older kernel
Kernel 3.17 driver supports only RGMII ethernet interface. Since the Tianocore DT contains same compatibility string for RGMII, SGMII based 1G and XFI based 10G interfaces, crash happens when probe called on SGMII based 1G and XFI based 10G interface. This patch fixes the backward compatibility of the older driver with the newer firmware by making the binding unique so that the older driver won't recognize the non-supported interfaces. v2: Address comments from v1 * updated cover letter subject line with net: xgene * Documentation: formatted compatible string values as list v1: * Initial version --- Iyappan Subramanian (3): Documentation: dts: Update compatible field description for APM X-Gene dtb: change binding name to match with newer firmware DT drivers: net: xgene: fix new firmware backward compatibility with older driver Documentation/devicetree/bindings/net/apm-xgene-enet.txt | 5 - arch/arm64/boot/dts/apm/apm-storm.dtsi | 4 ++-- drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 4 3 files changed, 10 insertions(+), 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] dt/bindings: Add binding for BCM2835 mailbox driver
Lee Jones writes:
> On Mon, 02 Mar 2015, Eric Anholt wrote:
>
>> From: Lubomir Rintel
>>
>> v2: Split into a separate patch for submitting to the devicetree list.
>
> When you say that you've split them, do you mean each DT doc, as I
> don't think this is the way to go. I'm happy to listen to other
> people's opinions, but I think all of the .../mailbox/brcm,bcm2835-
> files should be amalgamated.
I just meant that I split this patch out of the patch that followed
(because of review feeback and
Documentation/devicetree/bindings/submitting-patches.txt rules).
>> ---
>> .../devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt | 19
>> +++
>> 1 file changed, 19 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>> b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>> new file mode 100644
>> index 000..f5741a0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
>
> Rename these files to conform to the current naming convention. In
> -next we currently have 'altera-mailbox.txt' and 'omap-mailbox.txt',
> so 'bcm2835-mbox.txt' seems appropriate.
Will do.
>> @@ -0,0 +1,19 @@
>> +Broadcom BCM2835 VideoCore mailbox IPC
>> +
>> +Required properties:
>> +
>> +- compatible : Should be "brcm,bcm2835-mbox"
>> +- reg : Specifies base physical address and size of the registers.
>> +- interrupts : The interrupt number. See
>> + bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>> +- #mbox-cells : Specifies the number of cells needed to encode a
>> + mailbox channel. The value shall be 1.
>
> Binding documents are much easier to read if the property names and
> descriptions are seperated with tabs.
>
> - compatible : Should be "brcm,bcm2835-mbox"
> - reg : Specifies base physical address and size of the
> registers
> - interrupts : The interrupt number
> [See
> ../interrupt-controller/brcm,bcm2835-armctrl-ic.txt]
> - #mbox-cells : Specifies the number of cells needed to encode a
> mailbox channel. The value shall be 1
>
> ... don't you think? Also notice the consistency of no '.'s and the
> bracketing of the [See ...] statement.
The tree seems inconsistent on formatting of these files, but I like
your suggestion for nicer formatting so I'll do it.
>> +Example:
>> +
>> +mailbox: mailbox@7e00b800 {
>> +compatible = "brcm,bcm2835-mbox";
>> +reg = <0x7e00b880 0x40>;
>> +interrupts = <0 1>;
>> +#mbox-cells = <1>;
>> +};
>
> It would be good to see the client examples here as well. Please consider
> pulling in brcm,bcm2835-mbox-power.txt and brcm,bcm2835-mbox-property.txt.
Oh, so have those two just smashed into this file as one set of
documentation for everything to do with mailbox on bcm2835? That seems
good to me. When I was adding the client drivers, the fact that the
other brcm file was named after the compatible string made me generate
new files under then new compatible strings, but the other drivers
already in the tree obviously aren't formatted that way.
signature.asc
Description: PGP signature
Re: [PATCH 3/4] regulator: qcom: Refactor of-parsing code
On 03/02/15 20:25, Bjorn Andersson wrote:
> +
> +static int rpm_reg_probe(struct platform_device *pdev)
> +{
> + struct regulator_init_data *initdata;
> + const struct qcom_rpm_reg *template;
> + const struct of_device_id *match;
> + struct regulator_config config = { };
> + struct regulator_dev *rdev;
> + struct qcom_rpm_reg *vreg;
> + const char *key;
> + u32 val;
> + int ret;
> +
> + match = of_match_device(rpm_of_match, &pdev->dev);
> + template = match->data;
> +
> + vreg = devm_kmalloc(&pdev->dev, sizeof(*vreg), GFP_KERNEL);
> + if (!vreg) {
> + dev_err(&pdev->dev, "failed to allocate vreg\n");
We don't need error messages on allocation failures.
> + return -ENOMEM;
> + }
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On 03/02/15 20:25, Bjorn Andersson wrote: > > += SUBNODES > + > +The RPM exposes resources to its subnodes. The below bindings specify the set > +of valid subnodes that can operate on these resources. > + > +== Regulators > + > +Regulator notes are identified by their compatible: > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be one of: > + "qcom,rpm-pm8058-regulators" > + "qcom,rpm-pm8901-regulators" > + "qcom,rpm-pm8921-regulators" > + > +- vdd_l0_l1_lvs-supply: > +- vdd_l10-supply: > +- vdd_l13_l16-supply: > +- vdd_l14_l15-supply: > +- vdd_l17_l18-supply: > +- vdd_l19_l20-supply: > +- vdd_l21-supply: > +- vdd_l22-supply: > +- vdd_l23_l24_l25-supply: > +- vdd_l2_l11_l12-supply: > +- vdd_l3_l4_l5-supply: > +- vdd_l6_l7-supply: > +- vdd_l8-supply: > +- vdd_l9-supply: > +- vdd_ncp-supply: > +- vdd_s0-supply: > +- vdd_s1-supply: > +- vdd_s2-supply: > +- vdd_s3-supply: > +- vdd_s4-supply: > + Usage: optional (pm8058 only) > + Value type: > + Definition: reference to regulator supplying the input pin, as > + described in the data sheet > + > +- vdd_l0-supply: > +- vdd_l1-supply: > +- vdd_l2-supply: > +- vdd_l3-supply: > +- vdd_l4-supply: > +- vdd_l5-supply: > +- vdd_l6-supply: > +- vdd_s0-supply: > +- vdd_s1-supply: > +- vdd_s2-supply: > +- vdd_s3-supply: > +- vdd_s4-supply: > +- lvs0_in-supply: > +- lvs1_in-supply: > +- lvs2_in-supply: > +- lvs3_in-supply: > +- mvs_in-supply: > + Usage: optional (pm8901 only) > + Value type: > + Definition: reference to regulator supplying the input pin, as > + described in the data sheet > + > +- vin_l1_l2_l12_l18-supply: > +- vin_l24-supply: > +- vin_l25-supply: > +- vin_l27-supply: > +- vin_l28-supply: > +- vin_lvs_1_3_6-supply: > +- vin_lvs2-supply: > +- vin_lvs_4_5_7-supply: > +- vin_ncp-supply: Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I left out? It looks like you've covered all the inputs for the other pmics. > + Usage: optional (pm8921 only) > + Value type: > + Definition: reference to regulator supplying the input pin, as > + described in the data sheet > + > +The regulator node houses sub-nodes for each regulator within the device. > Each > +sub-node is identified using the node's name, with valid values listed for > each > +of the pmics below. > + -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: at91sam9263/dt: Fixup sram1 device tree node
Le 25/02/2015 09:35, Alexander Stein a écrit :
> Commit ff04660e48b20 ("ARM: at91/dt: add SRAM nodes") used the same base
> address for sram0 and sram1 leading to the following warning:
> WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x50/0x70()
> sysfs: cannot create duplicate filename '/devices/platform/30.sram'
> Fix the base address for sram1.
>
> Signed-off-by: Alexander Stein
Acked-by: Nicolas Ferre
Added to at91-4.0-fixes. Thanks.
> ---
> arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi
> b/arch/arm/boot/dts/at91sam9263.dtsi
> index cdb7d03..76bb849 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -69,7 +69,7 @@
>
> sram1: sram@0050 {
> compatible = "mmio-sram";
> - reg = <0x0030 0x4000>;
> + reg = <0x0050 0x4000>;
> };
>
> ahb {
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 16/18] ARM: dts: Introduce STM32F429 MCU
Hi Andreas,
Thanks for this detailed review.
2015-03-02 18:42 GMT+01:00 Andreas Färber :
> Hi Maxime,
>
> Please don't put the whole world in To, that makes replying to you much
> harder. You can put maintainers in CC instead.
Ok.
>
> Am 20.02.2015 um 19:01 schrieb Maxime Coquelin:
>> The STMicrolectornics's STM32F419 MCU has the following main features:
>> - Cortex-M4 core running up to @180MHz
>> - 2MB internal flash, 256KBytes internal RAM
>> - FMC controller to connect SDRAM, NOR and NAND memories
>> - SD/MMC/SDIO support
>> - Ethernet controller
>> - USB OTFG FS & HS controllers
>> - I2C, SPI, CAN busses support
>> - Several 16 & 32 bits general purpose timers
>> - Serial Audio interface
>> - LCD controller
>>
>> Signed-off-by: Maxime Coquelin
>> ---
>> arch/arm/boot/dts/Makefile| 1 +
>> arch/arm/boot/dts/stm32f429-disco.dts | 41
>> arch/arm/boot/dts/stm32f429.dtsi | 396
>> ++
>> 3 files changed, 438 insertions(+)
>> create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
>> create mode 100644 arch/arm/boot/dts/stm32f429.dtsi
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 91bd5bd..d7da0ef 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -442,6 +442,7 @@ dtb-$(CONFIG_ARCH_STI)+= stih407-b2120.dtb \
>> stih416-b2000.dtb \
>> stih416-b2020.dtb \
>> stih416-b2020e.dtb
>> +dtb-$(CONFIG_ARCH_STM32)+= stm32f429-disco.dtb
>> dtb-$(CONFIG_MACH_SUN4I) += \
>> sun4i-a10-a1000.dtb \
>> sun4i-a10-ba10-tvbox.dtb \
>> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
>> b/arch/arm/boot/dts/stm32f429-disco.dts
>> new file mode 100644
>> index 000..0e79cc1
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
>> @@ -0,0 +1,41 @@
>
> Add a suitable license header here? There had been attempts to
> dual-license as GPL and MIT/X11.
I agree to add the dual GPL and MIT/X11 licence.
>
>> +/dts-v1/;
>> +#include "stm32f429.dtsi"
>> +
>> +/ {
>> + model = "STMicroelectronics's STM32F429i-DISCO board";
>
> "'s" seems uncommon here and "s's" looks wrong. Just use
> "STMicroelectronics STM32F429I-DISCO board"?
Ok, it will be fixed in v3.
>
>> + compatible = "st,stm32f429i-disco", "st,stm32f429";
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200 root=/dev/ram
>> rdinit=/linuxrc";
>> + linux,stdout-path = &usart1;
>
> I have actually been using USART3, following a guide I found on GitHub.
> Which pins do you use for USART1, and is one better than the other?
I used U-boot from Emcraft, which uses USART1, that is the only reason
I used this one.
Regarding USART3, I had a look at your boot-wrapper, and you configure
the USART3 to PC10/PC11 pins.
>From the schematics, I see the PC10 pin is connected to the LCD.
>
>> + };
>> +
>> + memory {
>> + reg = <0xd000 0x80>;
>
> I have it at 0x9000!
Ok. But you use a specific setting:
https://github.com/afaerber/afboot-stm32/blob/master/foo.c#L338
By default this is the PC Card bank (Bank 4) at 0x9000.
Maybe you could change your boot-wrapper to use also the default setting?
>
>> + };
>> +
>> + aliases {
>> + ttyS0 = &usart1;
>
> Why ttyS0 here? Shouldn't that be serial0 by convention?
I was not aware of this. Do you know whether it is documented somewhere?
Anyway, I will change to serial0 in next version.
>
>> + };
>> +
>> + soc {
>> + usart1: usart@40011000 {
>> + status = "okay";
>> + };
>
> This is a new target, so please use the new-style &usart1 {...};
> reference rather than replicating the hierarchy.
Ok.
>
>> +
>> + leds {
>
> These LEDs are definitely not on the SoC, they're on the board. Please
> move one level up.
Ok.
>
>> + compatible = "gpio-leds";
>
> In this file you're being parsimonious with newline, yet in the .dtsi
> you unnecessarily add newlines before the trailing status property.
>
>> + red {
>> + #gpio-cells = <2>;
>
> This looks weird. Drop it?
Yes.
>
>> + label = "Front Panel LED";
>
> "Front Panel"? Both LEDs are on the front, and several other
> architectures avoid spaces in the label for accessing it from /sys.
That's an unfortunate copy/paste. For sure it has no meaning here.
>
>> + gpios = <&gpiog 14 0>;
>
> GPIO_ACTIVE_HIGH
Ok.
>
>> + linux,default-trigger = "heartbeat";
>
> Suggest to leave both off by default.
Ok.
>
>> + };
>> + green {
>> + #gpio-cells = <2>;
>
> Ditto.
>
>> + gpios = <&gpiog 13 0>;
>
> Ditto.
>
>> + default-state = "off";
>> + };
>> + };
>> + };
>> +};
>> dif
Re: [PATCH v1] of: calculate masks of the device based on dma-range size
On 02/25/2015 07:20 PM, Bjorn Helgaas wrote: [+cc Catalin] On Wed, Feb 11, 2015 at 12:53:35PM -0500, Murali Karicheri wrote: This patch update of_dma_configure() API to calculate the masks (dma_mask and coherent_dma_mask) based on the dma-range values set in DT for the device. Also limit the mask to lower of the default mask and mask calculated. Cc: Joerg Roedel Cc: Grant Likely Cc: Rob Herring Cc: Bjorn Helgaas Cc: Will Deacon Cc: Russell King Cc: Arnd Bergmann Cc: Suravee Suthikulpanit Signed-off-by: Murali Karicheri Applied with Catalin's reviewed-by to pci/iommu for v4.1, thanks! Bjorn, Could you point me to this? I didn't see it on pci/iommu of your repo below. arm-pci git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git (fetch) a0868495@ula0868495 ~/Project/linux-keystone $ gitlog arm-pci/pci/iommu dd8a11b0f0d4ed0ad87c8d09e650f354021d7953 arm: dma-mapping: limit IOMMU mapping size 2a101e79dcd8733e3a353b0df2fa384980f94e1e PCI: Update DMA configuration from DT 3fd29d06e9aa92d9a4513e14b2dd3f0d69d4d2b7 of/pci: Add of_pci_dma_configure() to update DMA configuration 8243352097c468f982a9f386cb1f455672b473a2 PCI: Add helper functions pci_get[put]_host_bridge_device() 039f346ac880d4f894425ef6c540f3ff5c1b8dcf of: Fix size when dma-range is not used 2743a957f6a6317be06d02cc93d78bb2a847e427 of: Move of_dma_configure() to device.c to help re-use f454cd01b5bdffb1bf26a5cddac30439fa5f27a1 of: iommu: Add ptr to OF node arg to of_iommu_configure() c517d838eb7d07bbe9507871fab3931deccff539 Linux 4.0-rc1 Murali I agree with Catalin's comment about the "size = 1ULL<< 32" line. I don't see how that will make a difference, so I dropped it. The patch I merged is below. Let me know if you think we do need that line or any other tweaks. Bjorn commit a5a1dd69080dfcf53bfd6e179f3db68e824aeaae Author: Murali Karicheri Date: Wed Feb 25 17:21:04 2015 -0600 of: Calculate device DMA masks based on DT dma-range size Calculate the dma_mask and coherent_dma_mask based on the dma-range values set in DT for the device. Limit the mask to lower of the default mask and mask calculated. Signed-off-by: Murali Karicheri Signed-off-by: Bjorn Helgaas Reviewed-by: Catalin Marinas CC: Joerg Roedel CC: Grant Likely CC: Rob Herring CC: Will Deacon CC: Russell King CC: Arnd Bergmann CC: Suravee Suthikulpanit diff --git a/drivers/of/device.c b/drivers/of/device.c index 28e743888402..20c1332a0018 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -90,10 +90,11 @@ void of_dma_configure(struct device *dev, struct device_node *np) struct iommu_ops *iommu; /* -* Set default dma-mask to 32 bit. Drivers are expected to setup -* the correct supported dma_mask. +* Set default coherent_dma_mask to 32 bit. Drivers are expected to +* setup the correct supported mask. */ - dev->coherent_dma_mask = DMA_BIT_MASK(32); + if (!dev->coherent_dma_mask) + dev->coherent_dma_mask = DMA_BIT_MASK(32); /* * Set it to coherent_dma_mask by default if the architecture @@ -128,6 +129,15 @@ void of_dma_configure(struct device *dev, struct device_node *np) dev->dma_pfn_offset = offset; + /* +* Limit coherent and dma mask based on size and default mask +* set by the driver. +*/ + dev->coherent_dma_mask = min(dev->coherent_dma_mask, +DMA_BIT_MASK(ilog2(dma_addr + size))); + *dev->dma_mask = min((*dev->dma_mask), +DMA_BIT_MASK(ilog2(dma_addr + size))); + coherent = of_dma_is_coherent(np); dev_dbg(dev, "device is%sdma coherent\n", coherent ? " " : " not "); -- Murali Karicheri Linux Kernel, Texas Instruments -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
On Tue, 03 Mar 2015, Rob Herring wrote: > On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij > wrote: > > This defines a new compatible option for MFD devices "simple-mfd" that will > > make the OF core spawn child devices for all subnodes of that MFD device. > > It is optional but handy for things like syscon and possibly other > > simpler MFD devices. > > > > Since there was no file to put the documentation in, I took this opportunity > > to make a small writeup on MFD devices and add the compatible definition > > there. > > > > Suggested-by: Lee Jones > > Cc: Arnd Bergmann > > Cc: Devicetree > > Cc: Rob Herring > > Cc: Benjamin Herrenschmidt > > Cc: Grant Likely > > Cc: Pawel Moll > > Cc: Mark Rutland > > Cc: Ian Campbell > > Cc: Kumar Gala > > Signed-off-by: Linus Walleij > > --- > > I make the patch to the OF core in this one, it makes much more sense since > > it's a oneliner > > > > Lee: this is a (tested!) implementation of your suggestion for simple-mfd. > > If you can eventually ACK this from the MFD side, I think it should be > > funneled through the ARM SoC tree. > > > > Grant/Rob: if either of you can ACK the change to the OF core likewise it > > can > > be taken through ARM SoC. > > > > DT binings maintainers: there is some background discussion on this here: > > http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2 > > http://marc.info/?l=devicetree&m=142166313621469&w=2 > > --- > > Documentation/devicetree/bindings/mfd/mfd.txt | 40 > > +++ > > drivers/of/platform.c | 1 + > > 2 files changed, 41 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt > > > > diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt > > b/Documentation/devicetree/bindings/mfd/mfd.txt > > new file mode 100644 > > index ..cc057438abe8 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/mfd.txt > > @@ -0,0 +1,40 @@ > > +Multi-Function Devices (MFD) > > + > > +These devices comprise a nexus for heterogeneous hardware blocks spawning > > +multiple child devices. > > + > > +A typical MFD can be: > > + > > +- A mixed signal ASIC on an external bus, sometimes a PMIC (power > > management > > + integrated circuit) that is manufactured in a lower technology node > > (rough > > + silicon) that handles analog drivers for things like audio amplifiers, > > LED > > + drivers, level shifters, PHY (physical interfaces to things like USB or > > + ethernet), regulators etc. > > + > > +- A range of memory registers containing "miscellaneous system registers" > > also > > + known as a system controller "syscon" or any other memory range > > containing a > > + mix of unrelated registers. > > + > > +Optional properties: > > + > > +- compatible : "simple-mfd" - this signifies that the operating system > > should > > + spawn child devices for all the subnodes of the MFD device akin to how > > + "simple-bus" inidicates when to spawn children for a simple memory-mapped > > + bus. For more complex devices, when the nexus driver has to probe > > registers > > + to figure out what children exist etc, this should not be used. In the > > latter > > + case the child devices will be instantiated by the operating system. > > If you point of_platform_populate to the parent node, it should > instantiate all children regardless of "simple-bus" or any other > match. The match is to probe the grandchildren. I could be mistaken, > but that's how it works at the root level. You don't have a driver > probe for the parent, so you want the top level of_platform_populate > call to instantiate these devices? > > Why does simple-bus not work for you? After all, it is not > "simple-memory-map-bus." simple-bus does 'work'. There are even some (3 I think) platforms actively making use of it. However, there was some controversy over using it, as syscon isn't really a bus. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v7] of: Move of_dma_configure() to device.c to help re-use
On 03/02/2015 10:43 PM, Bjorn Helgaas wrote: On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri wrote: Move of_dma_configure() to device.c so it can be re-used for PCI devices to obtain DMA configuration from DT. Also add a second argument so that for PCI, the DT node of root bus host bridge can be used to obtain the DMA configuration for the slave PCI device. Tested-by: Suravee Suthikulpanit (AMD Seattle) Signed-off-by: Murali Karicheri Signed-off-by: Bjorn Helgaas Reviewed-by: Catalin Marinas Acked-by: Will Deacon CC: Joerg Roedel CC: Grant Likely CC: Rob Herring CC: Russell King CC: Arnd Bergmann --- - Based on the existing patch applied to arm-pci/pci/iommu for pci next (Bjorn) - Fixed the build issue reported on ARCH=x86_64 Hi Murali, Can you please repost the entire series with fixed patches? It's easier for me to reapply the whole thing at once than it is to keep track of and fiddle with individual patches. Bjorn Bjorn, Ok. I have just posted v8 of the series including all patches. FYI. -- Murali Karicheri Linux Kernel, Texas Instruments -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/7] of: iommu: Add ptr to OF node arg to of_iommu_configure()
of_iommu_configure() is called from of_dma_configure() to setup iommu ops
using DT property. This API is currently used for platform devices for
which DMA configuration (including IOMMU ops) may come from the device's
parent. To extend this functionality for PCI devices, this API needs to
take a parent node ptr as an argument instead of assuming device's parent.
This is needed since for PCI, the DMA configuration may be defined in the
DT node of the root bus bridge's parent device. Currently only dma-range
is used for PCI and IOMMU is not supported. Return error if the device is
PCI.
Add "parent" parameter (a struct device_node *) to of_iommu_configure().
Tested-by: Suravee Suthikulpanit (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Rob Herring
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Russell King
CC: Arnd Bergmann
---
drivers/iommu/of_iommu.c | 10 --
drivers/of/platform.c|2 +-
include/linux/of_iommu.h |6 --
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index af1dc6a..43429ab 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct device_node *np)
return ops;
}
-struct iommu_ops *of_iommu_configure(struct device *dev)
+struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *master_np)
{
struct of_phandle_args iommu_spec;
struct device_node *np;
struct iommu_ops *ops = NULL;
int idx = 0;
+ if (dev_is_pci(dev)) {
+ dev_err(dev, "IOMMU is currently not supported for PCI\n");
+ return NULL;
+ }
+
/*
* We don't currently walk up the tree looking for a parent IOMMU.
* See the `Notes:' section of
* Documentation/devicetree/bindings/iommu/iommu.txt
*/
- while (!of_parse_phandle_with_args(dev->of_node, "iommus",
+ while (!of_parse_phandle_with_args(master_np, "iommus",
"#iommu-cells", idx,
&iommu_spec)) {
np = iommu_spec.np;
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b189733..667c6f1 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -196,7 +196,7 @@ static void of_dma_configure(struct device *dev)
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");
- iommu = of_iommu_configure(dev);
+ iommu = of_iommu_configure(dev, dev->of_node);
dev_dbg(dev, "device is%sbehind an iommu\n",
iommu ? " " : " not ");
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 16c7554..ffbe470 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -12,7 +12,8 @@ extern int of_get_dma_window(struct device_node *dn, const
char *prefix,
size_t *size);
extern void of_iommu_init(void);
-extern struct iommu_ops *of_iommu_configure(struct device *dev);
+extern struct iommu_ops *of_iommu_configure(struct device *dev,
+ struct device_node *master_np);
#else
@@ -24,7 +25,8 @@ static inline int of_get_dma_window(struct device_node *dn,
const char *prefix,
}
static inline void of_iommu_init(void) { }
-static inline struct iommu_ops *of_iommu_configure(struct device *dev)
+static inline struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *master_np)
{
return NULL;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/7] of/pci: Add of_pci_dma_configure() to update DMA configuration
Add of_pci_dma_configure() to allow updating the DMA configuration of the
PCI device using the configuration from DT of the parent of the root bridge
device. Use the newly added APIs pci_get/put_host_bridge_device() for
implementing this.
Tested-by: Suravee Suthikulpanit (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Rob Herring
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Russell King
CC: Arnd Bergmann
---
drivers/of/of_pci.c| 18 ++
include/linux/of_pci.h |3 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 62426d8..86d3c38 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
#include
@@ -116,6 +117,23 @@ int of_get_pci_domain_nr(struct device_node *node)
}
EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
+/**
+ * of_pci_dma_configure - Setup DMA configuration
+ * @dev: ptr to pci_dev struct of the pci device
+ *
+ * Function to update PCI devices's DMA configuration using the same
+ * info from the OF node of root host bridge's parent.
+ */
+void of_pci_dma_configure(struct pci_dev *pci_dev)
+{
+ struct device *dev = &pci_dev->dev;
+ struct device *bridge = pci_get_host_bridge_device(pci_dev);
+
+ of_dma_configure(dev, bridge->parent->of_node);
+ pci_put_host_bridge_device(bridge);
+}
+EXPORT_SYMBOL_GPL(of_pci_dma_configure);
+
#if defined(CONFIG_OF_ADDRESS)
/**
* of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index ce0e5ab..29fd3fe 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
int of_get_pci_domain_nr(struct device_node *node);
+void of_pci_dma_configure(struct pci_dev *pci_dev);
#else
static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct
of_phandle_args *out_irq)
{
@@ -50,6 +51,8 @@ of_get_pci_domain_nr(struct device_node *node)
{
return -1;
}
+
+static inline void of_pci_dma_configure(struct pci_dev *pci_dev) { }
#endif
#if defined(CONFIG_OF_ADDRESS)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 6/7] PCI: Update DMA configuration from DT
If there is a DT node available for the root bridge's parent device, use the DMA configuration from that device node. For example, Keystone PCI devices would require dma_pfn_offset to be set correctly in the device structure of the PCI device in order to have the correct DMA mask. The DT node will have dma-ranges defined for this. Also support using the DT property dma-coherent to allow coherent DMA operation by the PCI device. Use the new helper function of_pci_dma_configure() to update the device DMA configuration. This fixes DMA on systems where DMA addresses are a constant offset from CPU physical addresses. Tested-by: Suravee Suthikulpanit (AMD Seattle) Signed-off-by: Murali Karicheri Signed-off-by: Bjorn Helgaas Reviewed-by: Catalin Marinas Acked-by: Will Deacon CC: Joerg Roedel CC: Grant Likely CC: Rob Herring CC: Russell King CC: Arnd Bergmann --- drivers/pci/probe.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 8d2f400..413c1dd 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #include @@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus) dev->dev.dma_mask = &dev->dma_mask; dev->dev.dma_parms = &dev->dma_parms; dev->dev.coherent_dma_mask = 0xull; + of_pci_dma_configure(dev); pci_set_dma_max_seg_size(dev, 65536); pci_set_dma_seg_boundary(dev, 0x); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 7/7] arm: dma-mapping: limit IOMMU mapping size
arm_iommu_create_mapping() has size parameter of size_t and
arm_setup_iommu_dma_ops() can take a value higher than that
when this is called from the OF code. So limit the size to
SIZE_MAX.
Tested-by: Suravee Suthikulpanit (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Rob Herring
CC: Russell King
CC: Arnd Bergmann
---
arch/arm/mm/dma-mapping.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 170a116..fc81a38 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2027,6 +2027,13 @@ static bool arm_setup_iommu_dma_ops(struct device *dev,
u64 dma_base, u64 size,
if (!iommu)
return false;
+ /*
+* currently arm_iommu_create_mapping() takes a max of size_t
+* for size param. So check this limit for now.
+*/
+ if (size > SIZE_MAX)
+ return false;
+
mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
if (IS_ERR(mapping)) {
pr_warn("Failed to create %llu-byte IOMMU mapping for device
%s\n",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/7] of: Move of_dma_configure() to device.c to help re-use
Move of_dma_configure() to device.c so it can be re-used for PCI devices to
obtain DMA configuration from DT. Also add a second argument so that for
PCI, the DT node of root bus host bridge can be used to obtain the DMA
configuration for the slave PCI device.
Tested-by: Suravee Suthikulpanit (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Will Deacon
Acked-by: Rob Herring
CC: Joerg Roedel
CC: Grant Likely
CC: Russell King
CC: Arnd Bergmann
---
drivers/of/device.c | 59 +
drivers/of/platform.c | 58 ++--
include/linux/of_device.h |3 +++
3 files changed, 64 insertions(+), 56 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 46d6c75c..31a7875 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -2,6 +2,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -66,6 +69,62 @@ int of_device_add(struct platform_device *ofdev)
return device_add(&ofdev->dev);
}
+/**
+ * of_dma_configure - Setup DMA configuration
+ * @dev: Device to apply DMA configuration
+ * @np:Pointer to OF node having DMA configuration
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ *
+ * If platform code needs to use its own special DMA configuration, it
+ * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
+ * to fix up DMA configuration.
+ */
+void of_dma_configure(struct device *dev, struct device_node *np)
+{
+ u64 dma_addr, paddr, size;
+ int ret;
+ bool coherent;
+ unsigned long offset;
+ struct iommu_ops *iommu;
+
+ /*
+* Set default dma-mask to 32 bit. Drivers are expected to setup
+* the correct supported dma_mask.
+*/
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+ /*
+* Set it to coherent_dma_mask by default if the architecture
+* code has not set it.
+*/
+ if (!dev->dma_mask)
+ dev->dma_mask = &dev->coherent_dma_mask;
+
+ ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ if (ret < 0) {
+ dma_addr = offset = 0;
+ size = dev->coherent_dma_mask;
+ } else {
+ offset = PFN_DOWN(paddr - dma_addr);
+ dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
+ }
+
+ dev->dma_pfn_offset = offset;
+
+ coherent = of_dma_is_coherent(np);
+ dev_dbg(dev, "device is%sdma coherent\n",
+ coherent ? " " : " not ");
+
+ iommu = of_iommu_configure(dev, np);
+ dev_dbg(dev, "device is%sbehind an iommu\n",
+ iommu ? " " : " not ");
+
+ arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
+}
+EXPORT_SYMBOL_GPL(of_dma_configure);
+
int of_device_register(struct platform_device *pdev)
{
device_initialize(&pdev->dev);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 667c6f1..a01f57c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -150,59 +149,6 @@ struct platform_device *of_device_alloc(struct device_node
*np,
}
EXPORT_SYMBOL(of_device_alloc);
-/**
- * of_dma_configure - Setup DMA configuration
- * @dev: Device to apply DMA configuration
- *
- * Try to get devices's DMA configuration from DT and update it
- * accordingly.
- *
- * In case if platform code need to use own special DMA configuration,it
- * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
- * to fix up DMA configuration.
- */
-static void of_dma_configure(struct device *dev)
-{
- u64 dma_addr, paddr, size;
- int ret;
- bool coherent;
- unsigned long offset;
- struct iommu_ops *iommu;
-
- /*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
-*/
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
-
- /*
-* Set it to coherent_dma_mask by default if the architecture
-* code has not set it.
-*/
- if (!dev->dma_mask)
- dev->dma_mask = &dev->coherent_dma_mask;
-
- ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
- if (ret < 0) {
- dma_addr = offset = 0;
- size = dev->coherent_dma_mask;
- } else {
- offset = PFN_DOWN(paddr - dma_addr);
- dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
- }
- dev->dma_pfn_offset = offset;
-
- coherent = of_dma_is_coherent(dev->of_node);
- dev_dbg(dev, "device is%sdma coherent\n",
- coherent ? " " : " not ");
-
- iommu = of_iommu_configure(dev, dev->of_node);
- dev_dbg(dev, "device is%sbehind an iom
[PATCH v8 4/7] PCI: Add helper functions pci_get[put]_host_bridge_device()
Add helper functions to get/put the root bus's host bridge device.
Tested-by: Suravee Suthikulpanit (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Rob Herring
CC: Russell King
CC: Arnd Bergmann
---
drivers/pci/host-bridge.c | 14 ++
include/linux/pci.h |3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 39b2dbe..3e5bbf9 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -23,6 +23,20 @@ static struct pci_host_bridge *find_pci_host_bridge(struct
pci_bus *bus)
return to_pci_host_bridge(root_bus->bridge);
}
+struct device *pci_get_host_bridge_device(struct pci_dev *dev)
+{
+ struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
+ struct device *bridge = root_bus->bridge;
+
+ kobject_get(&bridge->kobj);
+ return bridge;
+}
+
+void pci_put_host_bridge_device(struct device *dev)
+{
+ kobject_put(&dev->kobj);
+}
+
void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
void (*release_fn)(struct pci_host_bridge *),
void *release_data)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 211e9da..a379513 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -510,6 +510,9 @@ static inline struct pci_dev *pci_upstream_bridge(struct
pci_dev *dev)
return dev->bus->self;
}
+struct device *pci_get_host_bridge_device(struct pci_dev *dev);
+void pci_put_host_bridge_device(struct device *dev);
+
#ifdef CONFIG_PCI_MSI
static inline bool pci_dev_msi_enabled(struct pci_dev *pci_dev)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/7] of: Fix size when dma-range is not used
Fix the dma-range size when the DT attribute is missing, i.e., set size to
dev->coherent_dma_mask + 1 instead of dev->coherent_dma_mask. Also add
code to check invalid values of size configured in DT and log error.
Tested-by: Suravee Suthikulpanit (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Rob Herring
CC: Russell King
CC: Arnd Bergmann
---
drivers/of/device.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 31a7875..28e74388 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,9 +105,24 @@ void of_dma_configure(struct device *dev, struct
device_node *np)
ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
if (ret < 0) {
dma_addr = offset = 0;
- size = dev->coherent_dma_mask;
+ size = dev->coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
+
+ /*
+* Add a work around to treat the size as mask + 1 in case
+* it is defined in DT as a mask.
+*/
+ if (size & 1) {
+ dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
+size);
+ size = size + 1;
+ }
+
+ if (!size) {
+ dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
+ return;
+ }
dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/7] PCI: get DMA configuration from parent device
This series is already applied on arm-pci iommu branch for next, but kbuild test robot reported build errors on x86_64 and sparc. So I am sending v8 to help apply on arm-pci iommu branch. Here is the original cover letter of the series. This patch add an important capability to PCI driver on Keystone. I hope to have this merged to the upstream branch so that it is available for v3.20. Also would like thank everyone for the contribution. PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch add capability to set the dma configuration such as dma-mask, dma_pfn_offset, and dma ops etc using the information from DT. The prior RFCs and discussions are available at [1] and [2] below. [2] : https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg790244.html [1] : http://www.gossamer-threads.com/lists/linux/kernel/2024591 Change history: v8 - On request from Bjorn, I am resending the whole series with also ack from Rob Herring against 2/7 v7 - Used for re-spinning 2/7 and 6/7. Fixed build issues on x86_64 and sparc reported by kbuild test robot v6 - Rebased to v3.19-v7 - Addressed some minor comments about node name and DT size validation. - Pulled out 8/8 of v5 and plan to send a patch for enhancing of_dma_configure() to use size to calculate dma mask. - Added Acks from reviewers. v5 - moved the dma_mask update in device from ARM specific API to of_dma_configure to allow this across other architecture as well - improved sanity check for DT dma-range size in of_dma_configure() - moved API to get parent bridge device to PCI (host-bridge.c) v4 - moved size adjustments in of_iommu_configure() to a separate patch - consistent node name comment from Rob - patch 6 added for dma_mask adjustment and iommu mapping size limiting. v3 - addressed comments to re-use of_dma_configure() for PCI - To help re-use, change of_iommu_configure() function argument - Move of_dma_configure to of/device.c - Limit the of_iommu_configure to non pci devices v2 - update size to coherent_dma_mask + 1 if dma-range info is missing - also check the np for null. v1 - updates based on the comments against initial RFC. - Added a helper function to get the OF node of the parent - Added an API in of_pci.c to update DMA configuration of the pci device. Cc: Joerg Roedel Cc: Grant Likely Cc: Rob Herring Cc: Bjorn Helgaas Cc: Will Deacon Cc: Russell King Cc: Arnd Bergmann Cc: Suravee Suthikulpanit Acked-by: Bjorn Helgaas Acked-by: Murali Karicheri Murali Karicheri (7): of: iommu: Add ptr to OF node arg to of_iommu_configure() of: Move of_dma_configure() to device.c to help re-use of: Fix size when dma-range is not used PCI: Add helper functions pci_get[put]_host_bridge_device() of/pci: Add of_pci_dma_configure() to update DMA configuration PCI: Update DMA configuration from DT arm: dma-mapping: limit IOMMU mapping size arch/arm/mm/dma-mapping.c |7 + drivers/iommu/of_iommu.c | 10 -- drivers/of/device.c | 74 + drivers/of/of_pci.c | 18 +++ drivers/of/platform.c | 58 ++- drivers/pci/host-bridge.c | 14 + drivers/pci/probe.c |2 ++ include/linux/of_device.h |3 ++ include/linux/of_iommu.h |6 ++-- include/linux/of_pci.h|3 ++ include/linux/pci.h |3 ++ 11 files changed, 138 insertions(+), 60 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] MFD/OF: document MFD devices and handle simple-mfd
On Tue, Mar 3, 2015 at 3:32 AM, Linus Walleij wrote: > This defines a new compatible option for MFD devices "simple-mfd" that will > make the OF core spawn child devices for all subnodes of that MFD device. > It is optional but handy for things like syscon and possibly other > simpler MFD devices. > > Since there was no file to put the documentation in, I took this opportunity > to make a small writeup on MFD devices and add the compatible definition > there. > > Suggested-by: Lee Jones > Cc: Arnd Bergmann > Cc: Devicetree > Cc: Rob Herring > Cc: Benjamin Herrenschmidt > Cc: Grant Likely > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Kumar Gala > Signed-off-by: Linus Walleij > --- > I make the patch to the OF core in this one, it makes much more sense since > it's a oneliner > > Lee: this is a (tested!) implementation of your suggestion for simple-mfd. > If you can eventually ACK this from the MFD side, I think it should be > funneled through the ARM SoC tree. > > Grant/Rob: if either of you can ACK the change to the OF core likewise it can > be taken through ARM SoC. > > DT binings maintainers: there is some background discussion on this here: > http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2 > http://marc.info/?l=devicetree&m=142166313621469&w=2 > --- > Documentation/devicetree/bindings/mfd/mfd.txt | 40 > +++ > drivers/of/platform.c | 1 + > 2 files changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt > > diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt > b/Documentation/devicetree/bindings/mfd/mfd.txt > new file mode 100644 > index ..cc057438abe8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/mfd.txt > @@ -0,0 +1,40 @@ > +Multi-Function Devices (MFD) > + > +These devices comprise a nexus for heterogeneous hardware blocks spawning > +multiple child devices. > + > +A typical MFD can be: > + > +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management > + integrated circuit) that is manufactured in a lower technology node (rough > + silicon) that handles analog drivers for things like audio amplifiers, LED > + drivers, level shifters, PHY (physical interfaces to things like USB or > + ethernet), regulators etc. > + > +- A range of memory registers containing "miscellaneous system registers" > also > + known as a system controller "syscon" or any other memory range containing > a > + mix of unrelated registers. > + > +Optional properties: > + > +- compatible : "simple-mfd" - this signifies that the operating system should > + spawn child devices for all the subnodes of the MFD device akin to how > + "simple-bus" inidicates when to spawn children for a simple memory-mapped > + bus. For more complex devices, when the nexus driver has to probe registers > + to figure out what children exist etc, this should not be used. In the > latter > + case the child devices will be instantiated by the operating system. If you point of_platform_populate to the parent node, it should instantiate all children regardless of "simple-bus" or any other match. The match is to probe the grandchildren. I could be mistaken, but that's how it works at the root level. You don't have a driver probe for the parent, so you want the top level of_platform_populate call to instantiate these devices? Why does simple-bus not work for you? After all, it is not "simple-memory-map-bus." Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] (gpio-fan): Add thermal control hooks
On 03/03/2015 09:09 AM, Nishanth Menon wrote: On 02/24/2015 02:06 PM, Nishanth Menon wrote: On Tue, Feb 24, 2015 at 1:55 PM, Guenter Roeck wrote: On Tue, Feb 24, 2015 at 03:29:35PM -0400, Eduardo Valentin wrote: Guenter, On Thu, Jan 08, 2015 at 08:48:40PM -0800, Guenter Roeck wrote: On 01/08/2015 10:05 AM, Nishanth Menon wrote: Allow gpio-fan to be used as thermal cooling device for platforms that use GPIO maps to control fans. As part of this change, we make the shutdown and remove logic the same as well. Signed-off-by: Nishanth Menon --- Applied to -next. What is the target kernel version for this change? It didn't make 4.0-rc1 If I recall correctly, I had to pull it because the thermal framework does not provide hooks if disabled. Weird, I am sure I sent an e-mail about this, but I don't find it right now. It can't make it in before the hooks are in place, or we'll need another version with ifdefs around the thermal registration code. I had posted the required hooks. https://patchwork.kernel.org/patch/5828261/ -> I think Eduardo picked this one up.. So once it hits mainline, we should ideally be clear. merged as 12ca7188468ee29c4e717f73db4bf43c90954fc7 upstream. Can we pick up this patch now? Done, currently testing. Should make its way into -next in a couple of days unless there are unexpected problems. Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] (gpio-fan): Add thermal control hooks
On 02/24/2015 02:06 PM, Nishanth Menon wrote: > On Tue, Feb 24, 2015 at 1:55 PM, Guenter Roeck wrote: >> On Tue, Feb 24, 2015 at 03:29:35PM -0400, Eduardo Valentin wrote: >>> Guenter, >>> >>> On Thu, Jan 08, 2015 at 08:48:40PM -0800, Guenter Roeck wrote: On 01/08/2015 10:05 AM, Nishanth Menon wrote: > Allow gpio-fan to be used as thermal cooling device for platforms that > use GPIO maps to control fans. > > As part of this change, we make the shutdown and remove logic the same > as well. > > Signed-off-by: Nishanth Menon > --- Applied to -next. >>> >>> What is the target kernel version for this change? It didn't make >>> 4.0-rc1 >>> >> If I recall correctly, I had to pull it because the thermal framework >> does not provide hooks if disabled. Weird, I am sure I sent an e-mail >> about this, but I don't find it right now. >> >> It can't make it in before the hooks are in place, or we'll need >> another version with ifdefs around the thermal registration code. > > I had posted the required hooks. > https://patchwork.kernel.org/patch/5828261/ -> I think Eduardo picked > this one up.. So once it hits mainline, we should ideally be clear. > merged as 12ca7188468ee29c4e717f73db4bf43c90954fc7 upstream. Can we pick up this patch now? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: imx: add required clocks property to binding
A clock specifier is required for i.MX I2C and is provided in all DTS implementations. Add this to the list of required properties in the binding. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/i2c/i2c-imx.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index 52d37fd..ce4311d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -7,6 +7,7 @@ Required properties: - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC - reg : Should contain I2C/HS-I2C registers location and length - interrupts : Should contain I2C/HS-I2C interrupt +- clocks : Should contain the I2C/HS-I2C clock specifier Optional properties: - clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [version 2] amba uarts - arm type uarts fifo size provided by device tree
On Wed, Feb 18, 2015 at 08:07:47PM +, Jorge Ramirez-Ortiz wrote: > [PATCH 1/2] Documentation: bindings: add optional fifo size property > [PATCH 2/2] drivers/tty: pl011: read fifo size from OF if present [updated] > > These patches aim at resolving an issue present on some of the amba pl011 > uarts. > > They were developed for the Hisilicon Hi6220 SoC where the fifo size on the > uarts is 64 despite the amba revision having been set to 1. Are we certain that the FIFO length is the only difference between the HI6220 PL011 and a regular PL011? It may be worth adding a compatible string in addition, just in case. Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 5/6] extcon: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Chanwoo Choi
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 63f01c4..6b5e795 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1149,6 +1149,7 @@ static int arizona_extcon_probe(struct platform_device
> *pdev)
> }
> break;
> case WM5110:
> + case WM8280:
> switch (arizona->rev) {
> case 0 ... 2:
> break;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/6] mfd: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> This adds support for the Wolfson Microelectronics WM8280 and WM8281
> codecs.
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Lee Jones
> [ Minor fixup to remove potentially uninitialised variable. ]
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/Kconfig |5 +++--
> drivers/mfd/arizona-core.c | 15 +--
> drivers/mfd/arizona-i2c.c|2 ++
> drivers/mfd/arizona-irq.c|1 +
> drivers/mfd/arizona-spi.c|2 ++
> include/linux/mfd/arizona/core.h |1 +
> 6 files changed, 22 insertions(+), 4 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 0ad88c7..b5fb03c 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1290,10 +1290,11 @@ config MFD_WM5102
> Support for Wolfson Microelectronics WM5102 low power audio SoC
>
> config MFD_WM5110
> - bool "Wolfson Microelectronics WM5110"
> + bool "Wolfson Microelectronics WM5110 and WM8280/WM8281"
> depends on MFD_ARIZONA
> help
> - Support for Wolfson Microelectronics WM5110 low power audio SoC
> + Support for Wolfson Microelectronics WM5110 and WM8280/WM8281
> + low power audio SoC
>
> config MFD_WM8997
> bool "Wolfson Microelectronics WM8997"
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 09ba8f1..9f81998 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -567,6 +567,7 @@ static int arizona_of_get_core_pdata(struct arizona
> *arizona)
> const struct of_device_id arizona_of_match[] = {
> { .compatible = "wlf,wm5102", .data = (void *)WM5102 },
> { .compatible = "wlf,wm5110", .data = (void *)WM5110 },
> + { .compatible = "wlf,wm8280", .data = (void *)WM8280 },
> { .compatible = "wlf,wm8997", .data = (void *)WM8997 },
> {},
> };
> @@ -671,6 +672,7 @@ int arizona_dev_init(struct arizona *arizona)
> switch (arizona->type) {
> case WM5102:
> case WM5110:
> + case WM8280:
> case WM8997:
> for (i = 0; i < ARRAY_SIZE(wm5102_core_supplies); i++)
> arizona->core_supplies[i].supply
> @@ -834,11 +836,19 @@ int arizona_dev_init(struct arizona *arizona)
> #endif
> #ifdef CONFIG_MFD_WM5110
> case 0x5110:
> - type_name = "WM5110";
> - if (arizona->type != WM5110) {
> + switch (arizona->type) {
> + case WM5110:
> + type_name = "WM5110";
> + break;
> + case WM8280:
> + type_name = "WM8280";
> + break;
> + default:
> + type_name = "WM5110";
> dev_err(arizona->dev, "WM5110 registered as %d\n",
> arizona->type);
> arizona->type = WM5110;
> + break;
> }
> apply_patch = wm5110_patch;
> break;
> @@ -1010,6 +1020,7 @@ int arizona_dev_init(struct arizona *arizona)
> ARRAY_SIZE(wm5102_devs), NULL, 0, NULL);
> break;
> case WM5110:
> + case WM8280:
> ret = mfd_add_devices(arizona->dev, -1, wm5110_devs,
> ARRAY_SIZE(wm5110_devs), NULL, 0, NULL);
> break;
> diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c
> index 9d4156f..ff782a5d 100644
> --- a/drivers/mfd/arizona-i2c.c
> +++ b/drivers/mfd/arizona-i2c.c
> @@ -44,6 +44,7 @@ static int arizona_i2c_probe(struct i2c_client *i2c,
> #endif
> #ifdef CONFIG_MFD_WM5110
> case WM5110:
> + case WM8280:
> regmap_config = &wm5110_i2c_regmap;
> break;
> #endif
> @@ -87,6 +88,7 @@ static int arizona_i2c_remove(struct i2c_client *i2c)
> static const struct i2c_device_id arizona_i2c_id[] = {
> { "wm5102", WM5102 },
> { "wm5110", WM5110 },
> + { "wm8280", WM8280 },
> { "wm8997", WM8997 },
> { }
> };
> diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
> index 3a3fe7c..d063b94 100644
> --- a/drivers/mfd/arizona-irq.c
> +++ b/drivers/mfd/arizona-irq.c
> @@ -211,6 +211,7 @@ int arizona_irq_init(struct arizona *arizona)
> #endif
> #ifdef CONFIG_MFD_WM5110
> case WM5110:
> + case WM8280:
> aod = &wm5110_aod;
>
> switch (arizona->rev) {
> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> index 8ef58bc..1e845f6 100644
> --- a/drivers/mfd/arizona-spi.c
> +++ b/drivers/mfd/arizona-spi.c
> @@ -44,6 +44,7 @@ static int arizona_spi_probe(struct spi_device *spi)
> #endif
> #ifdef CONFIG_MFD_WM5110
> case WM5110:
> + case WM8280:
> regmap_config = &wm5110_spi_regm
Re: [RESEND PATCH 3/6] regulator: arizona-micsupp: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Reviewed-by: Mark Brown
> Signed-off-by: Charles Keepax
> ---
> drivers/regulator/arizona-micsupp.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/regulator/arizona-micsupp.c
> b/drivers/regulator/arizona-micsupp.c
> index 2007900..bfe5dac 100644
> --- a/drivers/regulator/arizona-micsupp.c
> +++ b/drivers/regulator/arizona-micsupp.c
> @@ -246,6 +246,7 @@ static int arizona_micsupp_probe(struct platform_device
> *pdev)
>*/
> switch (arizona->type) {
> case WM5110:
> + case WM8280:
> desc = &arizona_micsupp_ext;
> micsupp->init_data = arizona_micsupp_ext_default;
> break;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 6/6] ASoC: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Mark Brown
> Signed-off-by: Charles Keepax
> ---
> sound/soc/codecs/arizona.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
> index 4c90602..95d31d6 100644
> --- a/sound/soc/codecs/arizona.c
> +++ b/sound/soc/codecs/arizona.c
> @@ -280,6 +280,7 @@ int arizona_init_gpio(struct snd_soc_codec *codec)
>
> switch (arizona->type) {
> case WM5110:
> + case WM8280:
> snd_soc_dapm_disable_pin(&codec->dapm, "DRC2 Signal Activity");
> break;
> default:
> @@ -1728,6 +1729,7 @@ static int arizona_calc_fratio(struct arizona_fll *fll,
>
> switch (fll->arizona->type) {
> case WM5110:
> + case WM8280:
> if (fll->arizona->rev < 3 || sync)
> return init_ratio;
> break;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 2/6] mfd: arizona: Update binding documentation for WM8280
On Tue, 03 Mar 2015, Charles Keepax wrote: > From: Richard Fitzgerald > > Signed-off-by: Richard Fitzgerald > Signed-off-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++ > 1 files changed, 11 insertions(+), 4 deletions(-) Applied, thanks. Will send out pull-request once this has had time to soak in -next. > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index bfef000..af8646f 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -8,6 +8,7 @@ Required properties: >- compatible : One of the following chip-specific strings: > "wlf,wm5102" > "wlf,wm5110" > +"wlf,wm8280" > "wlf,wm8997" >- reg : I2C slave address when connected using I2C, chip select number when > using SPI. > @@ -26,10 +27,16 @@ Required properties: >- #gpio-cells : Must be 2. The first cell is the pin number and the > second cell is used to specify optional parameters (currently unused). > > - - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, > wm5110), > -CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, > -wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as > covered > -in Documentation/devicetree/bindings/regulator/regulator.txt > + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, > +as covered in Documentation/devicetree/bindings/regulator/regulator.txt > + > + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, > +wm5110, wm8280) > + > + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, > +wm5110, wm8280) > + > + - SPKVDD-supply : Speaker driver power supply (wm8997) > > Optional properties: > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 4/6] gpio: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Linus Walleij
> Signed-off-by: Charles Keepax
> ---
> drivers/gpio/gpio-arizona.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
> index fe369f5..9665d0a 100644
> --- a/drivers/gpio/gpio-arizona.c
> +++ b/drivers/gpio/gpio-arizona.c
> @@ -116,6 +116,7 @@ static int arizona_gpio_probe(struct platform_device
> *pdev)
> switch (arizona->type) {
> case WM5102:
> case WM5110:
> + case WM8280:
> case WM8997:
> arizona_gpio->gpio_chip.ngpio = 5;
> break;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] regulator: qcom: Refactor of-parsing code
On Tue 03 Mar 06:13 PST 2015, Mark Brown wrote:
> On Mon, Mar 02, 2015 at 08:25:39PM -0800, Bjorn Andersson wrote:
>
> > + if ((vreg->parts->uV.mask || vreg->parts->mV.mask) &&
> > + (!initdata->constraints.min_uV || !initdata->constraints.max_uV)) {
> > + dev_err(&pdev->dev, "no voltage specified for regulator\n");
> > + return -EINVAL;
> > + }
>
> OK, so it looks like we're using it because we can't read the initial
> hardware state - can we introduce a specific interface for that perhaps?
> A call to query the current constraints might do it. Or possibly just
> change your earlier patch to make sure the constraints are marked const
> would do it, reading them isn't the problem that modifying them is. I
> might've missed some other usage somewhere though.
No, the reason for init_data is this snippet:
/* Regulators with ia property suppports drms */
if (vreg->parts->ia.mask)
init_data->constraints.valid_ops_mask |= REGULATOR_CHANGE_DRMS;
This patch just moves the code around to make it possible to implement
patch 4 as cleanly as possible.
The quoted code checks to see that for regulators with voltage-nobs
(could have checked for set_voltage ops) the of-parser did find voltage
limits. So it's a sanity check that discards regulators with missing
dt parameters.
I did drop this in patch 4, as it's not strictly needed. But the result
is that we will successfully register the regulator and the consumers
will be faced with errors upon trying to set voltage or enable it.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 3/6] regulator: arizona-micsupp: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Reviewed-by: Mark Brown
Signed-off-by: Charles Keepax
---
drivers/regulator/arizona-micsupp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index 2007900..bfe5dac 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -246,6 +246,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
*/
switch (arizona->type) {
case WM5110:
+ case WM8280:
desc = &arizona_micsupp_ext;
micsupp->init_data = arizona_micsupp_ext_default;
break;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 6/6] ASoC: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Acked-by: Mark Brown
Signed-off-by: Charles Keepax
---
sound/soc/codecs/arizona.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 4c90602..95d31d6 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -280,6 +280,7 @@ int arizona_init_gpio(struct snd_soc_codec *codec)
switch (arizona->type) {
case WM5110:
+ case WM8280:
snd_soc_dapm_disable_pin(&codec->dapm, "DRC2 Signal Activity");
break;
default:
@@ -1728,6 +1729,7 @@ static int arizona_calc_fratio(struct arizona_fll *fll,
switch (fll->arizona->type) {
case WM5110:
+ case WM8280:
if (fll->arizona->rev < 3 || sync)
return init_ratio;
break;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 5/6] extcon: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Acked-by: Chanwoo Choi
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 63f01c4..6b5e795 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1149,6 +1149,7 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
}
break;
case WM5110:
+ case WM8280:
switch (arizona->rev) {
case 0 ... 2:
break;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 4/6] gpio: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Acked-by: Linus Walleij
Signed-off-by: Charles Keepax
---
drivers/gpio/gpio-arizona.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index fe369f5..9665d0a 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -116,6 +116,7 @@ static int arizona_gpio_probe(struct platform_device *pdev)
switch (arizona->type) {
case WM5102:
case WM5110:
+ case WM8280:
case WM8997:
arizona_gpio->gpio_chip.ngpio = 5;
break;
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 2/6] mfd: arizona: Update binding documentation for WM8280
From: Richard Fitzgerald Signed-off-by: Richard Fitzgerald Signed-off-by: Charles Keepax --- Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index bfef000..af8646f 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -8,6 +8,7 @@ Required properties: - compatible : One of the following chip-specific strings: "wlf,wm5102" "wlf,wm5110" +"wlf,wm8280" "wlf,wm8997" - reg : I2C slave address when connected using I2C, chip select number when using SPI. @@ -26,10 +27,16 @@ Required properties: - #gpio-cells : Must be 2. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). - - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110), -CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, -wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered -in Documentation/devicetree/bindings/regulator/regulator.txt + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, +as covered in Documentation/devicetree/bindings/regulator/regulator.txt + + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, +wm5110, wm8280) + + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, +wm5110, wm8280) + + - SPKVDD-supply : Speaker driver power supply (wm8997) Optional properties: -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 1/6] mfd: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
This adds support for the Wolfson Microelectronics WM8280 and WM8281
codecs.
Signed-off-by: Richard Fitzgerald
Acked-by: Lee Jones
[ Minor fixup to remove potentially uninitialised variable. ]
Signed-off-by: Charles Keepax
---
drivers/mfd/Kconfig |5 +++--
drivers/mfd/arizona-core.c | 15 +--
drivers/mfd/arizona-i2c.c|2 ++
drivers/mfd/arizona-irq.c|1 +
drivers/mfd/arizona-spi.c|2 ++
include/linux/mfd/arizona/core.h |1 +
6 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0ad88c7..b5fb03c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1290,10 +1290,11 @@ config MFD_WM5102
Support for Wolfson Microelectronics WM5102 low power audio SoC
config MFD_WM5110
- bool "Wolfson Microelectronics WM5110"
+ bool "Wolfson Microelectronics WM5110 and WM8280/WM8281"
depends on MFD_ARIZONA
help
- Support for Wolfson Microelectronics WM5110 low power audio SoC
+ Support for Wolfson Microelectronics WM5110 and WM8280/WM8281
+ low power audio SoC
config MFD_WM8997
bool "Wolfson Microelectronics WM8997"
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 09ba8f1..9f81998 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -567,6 +567,7 @@ static int arizona_of_get_core_pdata(struct arizona
*arizona)
const struct of_device_id arizona_of_match[] = {
{ .compatible = "wlf,wm5102", .data = (void *)WM5102 },
{ .compatible = "wlf,wm5110", .data = (void *)WM5110 },
+ { .compatible = "wlf,wm8280", .data = (void *)WM8280 },
{ .compatible = "wlf,wm8997", .data = (void *)WM8997 },
{},
};
@@ -671,6 +672,7 @@ int arizona_dev_init(struct arizona *arizona)
switch (arizona->type) {
case WM5102:
case WM5110:
+ case WM8280:
case WM8997:
for (i = 0; i < ARRAY_SIZE(wm5102_core_supplies); i++)
arizona->core_supplies[i].supply
@@ -834,11 +836,19 @@ int arizona_dev_init(struct arizona *arizona)
#endif
#ifdef CONFIG_MFD_WM5110
case 0x5110:
- type_name = "WM5110";
- if (arizona->type != WM5110) {
+ switch (arizona->type) {
+ case WM5110:
+ type_name = "WM5110";
+ break;
+ case WM8280:
+ type_name = "WM8280";
+ break;
+ default:
+ type_name = "WM5110";
dev_err(arizona->dev, "WM5110 registered as %d\n",
arizona->type);
arizona->type = WM5110;
+ break;
}
apply_patch = wm5110_patch;
break;
@@ -1010,6 +1020,7 @@ int arizona_dev_init(struct arizona *arizona)
ARRAY_SIZE(wm5102_devs), NULL, 0, NULL);
break;
case WM5110:
+ case WM8280:
ret = mfd_add_devices(arizona->dev, -1, wm5110_devs,
ARRAY_SIZE(wm5110_devs), NULL, 0, NULL);
break;
diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c
index 9d4156f..ff782a5d 100644
--- a/drivers/mfd/arizona-i2c.c
+++ b/drivers/mfd/arizona-i2c.c
@@ -44,6 +44,7 @@ static int arizona_i2c_probe(struct i2c_client *i2c,
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
regmap_config = &wm5110_i2c_regmap;
break;
#endif
@@ -87,6 +88,7 @@ static int arizona_i2c_remove(struct i2c_client *i2c)
static const struct i2c_device_id arizona_i2c_id[] = {
{ "wm5102", WM5102 },
{ "wm5110", WM5110 },
+ { "wm8280", WM8280 },
{ "wm8997", WM8997 },
{ }
};
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 3a3fe7c..d063b94 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -211,6 +211,7 @@ int arizona_irq_init(struct arizona *arizona)
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
aod = &wm5110_aod;
switch (arizona->rev) {
diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
index 8ef58bc..1e845f6 100644
--- a/drivers/mfd/arizona-spi.c
+++ b/drivers/mfd/arizona-spi.c
@@ -44,6 +44,7 @@ static int arizona_spi_probe(struct spi_device *spi)
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
regmap_config = &wm5110_spi_regmap;
break;
#endif
@@ -84,6 +85,7 @@ static int arizona_spi_remove(struct spi_device *spi)
static const struct spi_device_id arizona_spi_ids[] = {
{ "wm5102", WM5102 },
{ "wm5110", WM5110 },
+ { "wm8280", WM8280 },
Re: [PATCH - v7] of: Move of_dma_configure() to device.c to help re-use
On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri wrote:
> Move of_dma_configure() to device.c so it can be re-used for PCI devices to
> obtain DMA configuration from DT. Also add a second argument so that for
> PCI, the DT node of root bus host bridge can be used to obtain the DMA
> configuration for the slave PCI device.
>
> Tested-by: Suravee Suthikulpanit (AMD Seattle)
> Signed-off-by: Murali Karicheri
> Signed-off-by: Bjorn Helgaas
> Reviewed-by: Catalin Marinas
> Acked-by: Will Deacon
> CC: Joerg Roedel
> CC: Grant Likely
> CC: Rob Herring
> CC: Russell King
> CC: Arnd Bergmann
Acked-by: Rob Herring
> ---
> - Based on the existing patch applied to arm-pci/pci/iommu for pci next
> (Bjorn)
> - Fixed the build issue reported on ARCH=x86_64
> drivers/of/device.c | 59
> +
> drivers/of/platform.c | 58 ++--
> include/linux/of_device.h |2 ++
> 3 files changed, 63 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 46d6c75c..31a7875 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -2,6 +2,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -66,6 +69,62 @@ int of_device_add(struct platform_device *ofdev)
> return device_add(&ofdev->dev);
> }
>
> +/**
> + * of_dma_configure - Setup DMA configuration
> + * @dev: Device to apply DMA configuration
> + * @np:Pointer to OF node having DMA configuration
> + *
> + * Try to get devices's DMA configuration from DT and update it
> + * accordingly.
> + *
> + * If platform code needs to use its own special DMA configuration, it
> + * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
> + * to fix up DMA configuration.
> + */
> +void of_dma_configure(struct device *dev, struct device_node *np)
> +{
> + u64 dma_addr, paddr, size;
> + int ret;
> + bool coherent;
> + unsigned long offset;
> + struct iommu_ops *iommu;
> +
> + /*
> +* Set default dma-mask to 32 bit. Drivers are expected to setup
> +* the correct supported dma_mask.
> +*/
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> +* Set it to coherent_dma_mask by default if the architecture
> +* code has not set it.
> +*/
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> + if (ret < 0) {
> + dma_addr = offset = 0;
> + size = dev->coherent_dma_mask;
> + } else {
> + offset = PFN_DOWN(paddr - dma_addr);
> + dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> + }
> +
> + dev->dma_pfn_offset = offset;
> +
> + coherent = of_dma_is_coherent(np);
> + dev_dbg(dev, "device is%sdma coherent\n",
> + coherent ? " " : " not ");
> +
> + iommu = of_iommu_configure(dev, np);
> + dev_dbg(dev, "device is%sbehind an iommu\n",
> + iommu ? " " : " not ");
> +
> + arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
> +}
> +EXPORT_SYMBOL_GPL(of_dma_configure);
> +
> int of_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 667c6f1..a01f57c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -19,7 +19,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -150,59 +149,6 @@ struct platform_device *of_device_alloc(struct
> device_node *np,
> }
> EXPORT_SYMBOL(of_device_alloc);
>
> -/**
> - * of_dma_configure - Setup DMA configuration
> - * @dev: Device to apply DMA configuration
> - *
> - * Try to get devices's DMA configuration from DT and update it
> - * accordingly.
> - *
> - * In case if platform code need to use own special DMA configuration,it
> - * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
> - * to fix up DMA configuration.
> - */
> -static void of_dma_configure(struct device *dev)
> -{
> - u64 dma_addr, paddr, size;
> - int ret;
> - bool coherent;
> - unsigned long offset;
> - struct iommu_ops *iommu;
> -
> - /*
> -* Set default dma-mask to 32 bit. Drivers are expected to setup
> -* the correct supported dma_mask.
> -*/
> - dev->coherent_dma_mask = DMA_BIT_MASK(32);
> -
> - /*
> -* Set it to coherent_dma_mask by default if the architecture
> -* code has not set it.
> -*/
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> -
> - ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> - if (ret < 0) {
> -
Re: [PATCH 2/4] regulator: core: Expose init_data to of_parse_cb
On Tue 03 Mar 04:50 PST 2015, Mark Brown wrote: > On Mon, Mar 02, 2015 at 08:25:38PM -0800, Bjorn Andersson wrote: > > > Expose the newly created init_data to the driver's parse callback so > > that it can futher enhance it with e.g. constraints of the regulator. > > Why would the driver need to do that? I guess I'll see later on in the > series but the changelog should make that clear. Drivers aren't > supposed to ever need to look at their init data, modifying the init > data from what the machine provied is usually a red flag. > I think what you're getting at is that the init_data should come from a board file or device tree. With the reworkings done in patch 4 this makes more sense than it did before (e.g. I no longer call of_get_regulator_init_data()). However, by calling register_regulator() with dev->of_node being non-NULL and desc->of_match being something that will match a DT entry all init_data is now coming from device tree, through: regulator_register() regulator_of_get_init_data() of_get_regulator_init_data() of_get_regulation_constraints() As this matches a regulator, there is no way for the driver (or anyone else to affect the init_data). The problem at hand is that there is nothing in this code path telling the core that we can do DRMS - something we can figure out in the driver by basically looking at the ops for the registering regulator. > > This is needed because calling regulator_register() with a of_node and > > of_match will overwrite the passed config->init_data. An alternative way > > would be to merge the parsed init_data with the driver provided one. > > Put any explanation as to why the feature is needed in the changelog. Point taken. Let me know if you think I'm on a sane path with the above reasoning and I can resend the patch with a better description of the problem at hand. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
