Re: [PATCH v2 1/2] ARM: OMAP2+: only search for GPMC DT child nodes on probe
On 04/18/2013 12:33 AM, Jon Hunter wrote:
>
> On 04/17/2013 05:10 PM, Javier Martinez Canillas wrote:
>> On 04/17/2013 11:27 PM, Jon Hunter wrote:
>>>
>>> On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device nodes of the GPMC controller. But this function does
not use the GPMC device node as the root of the search and instead
search across the complete Device Tree.
This means that any device node on the DT that is using any of the
GPMC child nodes names searched for will be returned even if they
are not connected to the GPMC, making the gpmc_probe_xxx_child()
function to fail.
Fix this by using the GPMC device node as the search root so the
search will be restricted to its children.
Reported-by: Lars Poeschel
Signed-off-by: Javier Martinez Canillas
---
Changes since v1 (suggested by Jon Hunter):
- Split the search for GPMC child nodes and only warn if a
child probe fails on two different patches
- Don't probe all childs unnecesary if a previous matched
arch/arm/mach-omap2/gpmc.c | 33 ++---
1 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..6166847 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1520,32 +1520,19 @@ static int gpmc_probe_dt(struct platform_device
*pdev)
return ret;
}
- for_each_node_by_name(child, "nand") {
- ret = gpmc_probe_nand_child(pdev, child);
- if (ret < 0) {
- of_node_put(child);
- return ret;
- }
- }
+ for_each_child_of_node(pdev->dev.of_node, child) {
- for_each_node_by_name(child, "onenand") {
- ret = gpmc_probe_onenand_child(pdev, child);
- if (ret < 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (!child->name)
+ continue;
- for_each_node_by_name(child, "nor") {
- ret = gpmc_probe_generic_child(pdev, child);
- if (ret < 0) {
- of_node_put(child);
- return ret;
- }
- }
+ if (of_node_cmp(child->name, "nand") == 0)
+ ret = gpmc_probe_nand_child(pdev, child);
+ else if (of_node_cmp(child->name, "onenand") == 0)
+ ret = gpmc_probe_onenand_child(pdev, child);
+ else if (of_node_cmp(child->name, "ethernet") == 0 ||
+ of_node_cmp(child->name, "nor") == 0)
+ ret = gpmc_probe_generic_child(pdev, child);
- for_each_node_by_name(child, "ethernet") {
- ret = gpmc_probe_generic_child(pdev, child);
if (ret < 0) {
>>>
>>> I think that we need to make sure that "ret" is initialised to 0 at the
>>> beginning of the function. We should not have a case where the child
>>
>> Hi Jon,
>>
>> I didn't set ret to 0 at the beginning of the function since it is assigned
>> the
>> return value of a previous call to of_property_read_u32(). So ret should be 0
>> when execution reaches the for loop.
>
> Yes you are right, I overlooked that.
>
>>> name does not match but who knows. Actually that raises another point,
>>> should we have an "else" clause at the end that WARNs on
>>> "unknown/unsupported child" device?
>>>
>>
>> Actually I thought about it when I was writing that patch and then I decided
>> to
>> not add a WARN for that case since nothing really fail in that case.
>>
>> I mean if we want to check that a DT is well formed then I think we will
>> need to
>> add much more checks and I don't know if is worth it.
>>
>> But I don't have a strong opinion on this so if you want I can add it an
>> send a v3.
>
> Ok, that's fine. I am happy with this version, so no need then to re-do.
>
Great, thanks a lot for your feedback!
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Regarding dtc+cpp support
Hi Stephen, I am trying to add a header file for samsung audio subsystem clk definitions, which can be used in kernel and dt files. I applied following patches posted by you in my working tree. [1/7] kbuild: create an "include chroot" for DT bindings [2/7] kbuild: fixdep: support concatenated dep files [3/7] kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc [4/7] kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp [5/7] ARM: dt: add header to define GPIO flags [6/7] ARM: dt: add header to define IRQ flags [7/7] ARM: dt: create a DT header for the GIC I created a header file in arch/arm/boot/dts/include/clk/samsung-audss-clk.h and I included this header in driver and dtsi files Please see the code snippet in dtsi below. #include /include/ "skeleton.dtsi" /include/ "exynos5250-pinctrl.dtsi In driver it is compiling successfully but in dtsi files I am getting the follwing compilation error. Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 make[1]: *** Waiting for unfinished jobs DTC arch/arm/boot/dts/exynos5250-snow.dtb Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/arm/boot/dts/exynos5250-smdk5250.dtb] Error 1 Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/arm/boot/dts/exynos5250-snow.dtb] Error 1 make: *** [dtbs] Error 2 make: *** Waiting for unfinished jobs where "#include " is the 21st line in the dtsi file. Please let me know if any extra patches are required to solve this compilation error? Best Regards Padma ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 06/10] video: ARM CLCD: Add DT & CDF support
On Wed, Apr 17, 2013 at 04:17:18PM +0100, Pawel Moll wrote:
> +#if defined(CONFIG_OF)
> +static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
> + struct display_entity_interface_params *params)
> +{
> + int r = params->p.tft_parallel.r_bits;
> + int g = params->p.tft_parallel.g_bits;
> + int b = params->p.tft_parallel.b_bits;
> +
> + /* Bypass pixel clock divider, data output on the falling edge */
> + panel->tim2 = TIM2_BCD | TIM2_IPC;
> +
> + /* TFT display, vert. comp. interrupt at the start of the back porch */
> + panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> +
> + if (params->p.tft_parallel.r_b_swapped)
> + panel->cntl |= CNTL_BGR;
NAK. Do not set this explicitly. Note the driver talks about this being
"the old way" - this should not be used with the panel capabilities - and
in fact it will be overwritten.
Instead, you need to encode this into the capabilities by masking the
below with CLCD_CAP_RGB or CLCD_CAP_BGR depending on the ordering.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/5] ARM: dts: Update G2D documentation for clock entries
Added clock entry definitions to G2D bindings document.
Signed-off-by: Sachin Kamat
Cc: devicetree-discuss@lists.ozlabs.org
---
.../devicetree/bindings/gpu/samsung-g2d.txt|5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
index 2b14a94..3f454ff 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -10,11 +10,16 @@ Required properties:
mapped region.
- interrupts : G2D interrupt number to the CPU.
+ - clocks : from common clock binding: handle to G2D clocks.
+ - clock-names : from common clock binding: must contain "sclk_fimg2d" and
+ "fimg2d", corresponding to entries in the clocks property.
Example:
g2d@1280 {
compatible = "samsung,s5pv210-g2d";
reg = <0x1280 0x1000>;
interrupts = <0 89 0>;
+ clocks = <&clock 177>, <&clock 277>;
+ clock-names = "sclk_fimg2d", "fimg2d";
status = "disabled";
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/2] ARM: dts: omap3-beagle-xm: Add USB Host support
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 61 +
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..04376a6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,59 @@
ti,mcbsp = <&mcbsp2>;
ti,codec = <&twl_audio>;
};
+
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb2_reset";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio5 19 0>; /* gpio_147 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb2_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&twl_gpio 18 0>;/* GPIO LEDA */
+ startup-delay-us = <7>;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = "usb-nop-xceiv";
+ reset-supply = <&hsusb2_reset>;
+ vcc-supply = <&hsusb2_power>;
+ };
+
+};
+
+&omap3_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusbb2_pins
+ >;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins = <
+ 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ >;
+ };
};
&i2c1 {
@@ -125,3 +178,11 @@
mode = <3>;
power = <50>;
};
+
+&usbhshost {
+ port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <0 &hsusb2_phy>;
+};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/2] ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx
Rev. Ax/Bx boards have reversed polarity for USBHOST_PWR_ENable
signal when compared to Rev. C boards.
We create a new dts file for Ax/Bx boards.
Also update model and compatible flags for Rev. C board.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm-ab.dts | 19 +++
arch/arm/boot/dts/omap3-beagle-xm.dts|4 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-beagle-xm-ab.dts
diff --git a/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
new file mode 100644
index 000..041b40e
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ "omap3-beagle-xm.dts"
+
+/ {
+model = "TI OMAP3 BeagleBoard xM Rev: Ax/Bx";
+compatible = "ti,omap3-beagle-xm-ab", "ti,omap3-beagle", "ti,omap3";
+};
+
+/* On Rev A/B USBHOST_PWR_EN is active high */
+&hsusb2_power {
+ enable-active-high;
+};
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 04376a6..8a46dc5 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -10,8 +10,8 @@
/include/ "omap36xx.dtsi"
/ {
- model = "TI OMAP3 BeagleBoard xM";
- compatible = "ti,omap3-beagle-xm, ti,omap3-beagle", "ti,omap3";
+ model = "TI OMAP3 BeagleBoard xM Rev: C";
+ compatible = "ti,omap3-beagle-xm-c", "ti,omap3-beagle", "ti,omap3";
cpus {
cpu@0 {
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring wrote: > On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: >> On 04/09/2013 12:16 AM, Stephen Warren wrote: >>> On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: > According to > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > the "#interrupt-cells" property of an "interrupt-controller" is used > to define the number of cells needed to specify a single interrupt. >>> ... > But the type is never returned so it can't be saved on the IRQ struct > resource flags member. > > This means that drivers that need the IRQ type/level flags defined in > the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? >>> >>> FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking >>> back, I'm not sure if that was the right thing or whether I should have >>> sent this same patch:-) >>> >> >> Hi Stephen, >> >> I'm glad you agree :-) >> >> I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for >> the IRQ with irqd_get_trigger_type() but I prefer $subject because: > > irqd_get_trigger_type probably is not meant for outside of irqchips. > Creating an irq_get_irq_type function which takes an irq number would be > the right function as that does not expose struct irq_data. > Hi Rob, I sent a patch-set a few days ago that adds an irq_get_irq_type() function [1] as you suggested and this function is used on the smsc911x driver probe function to get the edge/level flags [2]. It would be great if I can get your feedback on this. Thanks a lot and best regards, Javier [1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/97117 [2]: http://permalink.gmane.org/gmane.linux.network/265587 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 05/10] ASoC: fsl-ssi: Use generic DMA bindings if possible
There may be some platforms using fsl-ssi that do not have a DMA driver
with generic DMA bindings. So this patch adds support for the generic
DMA bindings, while still using the old "fsl,dma-events" property if
"dmas" is not found.
Signed-off-by: Markus Pargmann
---
Notes:
Changes in v4:
- Change TODO comment to a FIXME, to remove the old dma-events property as
soon
as all dma drivers support the generic DMA bindings.
sound/soc/fsl/fsl_ssi.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 5165d41..d2afda1 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -796,15 +796,19 @@ static int fsl_ssi_probe(struct platform_device *pdev)
&ssi_private->filter_data_tx;
ssi_private->dma_params_rx.filter_data =
&ssi_private->filter_data_rx;
- /*
-* TODO: This is a temporary solution and should be changed
-* to use generic DMA binding later when the helplers get in.
-*/
- ret = of_property_read_u32_array(pdev->dev.of_node,
+ if (!of_property_read_bool(pdev->dev.of_node, "dmas") &&
+ ssi_private->use_dma) {
+ /*
+* FIXME: This is a temporary solution until all
+* necessary dma drivers support the generic dma
+* bindings.
+*/
+ ret = of_property_read_u32_array(pdev->dev.of_node,
"fsl,ssi-dma-events", dma_events, 2);
- if (ret && !ssi_private->use_dma) {
- dev_err(&pdev->dev, "could not get dma events\n");
- goto error_clk;
+ if (ret && ssi_private->use_dma) {
+ dev_err(&pdev->dev, "could not get dma events
but fsl-ssi is configured to use DMA\n");
+ goto error_clk;
+ }
}
shared = of_device_is_compatible(of_get_parent(np),
@@ -875,8 +879,10 @@ static int fsl_ssi_probe(struct platform_device *pdev)
}
} else {
ssi_private->imx_pcm_pdev =
- platform_device_register_simple("imx-pcm-audio",
- -1, NULL, 0);
+ platform_device_register_data(&pdev->dev,
+ "imx-pcm-audio", -1,
+ pdev->dev.of_node,
+ sizeof(*pdev->dev.of_node));
if (IS_ERR(ssi_private->imx_pcm_pdev)) {
ret = PTR_ERR(ssi_private->imx_pcm_pdev);
goto error_dev;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 10/10] ASoC: fsl: Update fsl-ssi binding doc
Update the fsl-ssi bindings. DMA is no required property anymore and uses the generic DMA bindings. imx-fiq is a new alternative to DMA Signed-off-by: Markus Pargmann --- Notes: Changes in v4: - Add a comment about hardware bugs for imx-pcm-fiq Changes in v3: - In previous versions, I removed fsl,playback-dma and capture-dma. But they are still in use by fsl_dma.c, so I added them again. Documentation/devicetree/bindings/sound/fsl,ssi.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt index 5ff76c9..0375ee0 100644 --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt @@ -43,10 +43,20 @@ Required properties: together. This would still allow different sample sizes, but not different sample rates. +Note that either dmas, dma-names or fsl,imx-fiq are required. + Optional properties: - codec-handle: Phandle to a 'codec' node that defines an audio codec connected to this SSI. This node is typically a child of an I2C or other control node. +- dmas:Generic dma devicetree binding as described in + Documentation/devicetree/bindings/dma/dma.txt. +- dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq + is not defined. +- fsl,imx-fiq: Bool property. Use imx-pcm-fiq instead of imx-pcm-dma. + Only necessary for some boards with incompatible + codec. imx-pcm-fiq will manually filter some data from + the codec. It is a workaround for a hardware bug. Child 'codec' node required properties: - compatible: Compatible list, contains the name of the codec -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 07/10] ASoC: fsl-ssi: imx ac97 support
This patch copies some parts from imx-ssi to support AC97 on
imx27-pca100 and imx27-pcm043. This is a implementation of the
ac97-slave mode.
For ac97, the registers have to be setup earlier than for other ssi
modes because there is some communication with the external device
before actual streaming. So this patch introduces a fsl_ssi_setup
function to setup the registers at different times.
This patch was tested with imx27-pca100.
Signed-off-by: Markus Pargmann
---
Notes:
Changes in v3:
- Cleanup ac97 code by adding a fsl_ssi_setup function for initial register
setup. For ac97 the registers have to be setup earlier than in normal
mode.
sound/soc/fsl/fsl_ssi.c | 412 +++-
1 file changed, 340 insertions(+), 72 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index d2afda1..5cb7533 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -141,6 +141,7 @@ struct fsl_ssi_private {
bool new_binding;
bool ssi_on_imx;
+ bool imx_ac97;
bool use_dma;
struct clk *clk;
struct platform_device *imx_pcm_pdev;
@@ -150,6 +151,9 @@ struct fsl_ssi_private {
struct imx_dma_data filter_data_rx;
struct imx_pcm_fiq_params fiq_params;
+ void (*ac97_reset) (struct snd_ac97 *ac97);
+ void (*ac97_warm_reset)(struct snd_ac97 *ac97);
+
struct {
unsigned int rfrc;
unsigned int tfrc;
@@ -321,6 +325,124 @@ static irqreturn_t fsl_ssi_isr(int irq, void *dev_id)
return ret;
}
+static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
+{
+ struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+ u8 i2s_mode;
+ u8 wm;
+ int synchronous = ssi_private->cpu_dai_drv.symmetric_rates;
+
+ if (ssi_private->imx_ac97)
+ i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET;
+ else
+ i2s_mode = CCSR_SSI_SCR_I2S_MODE_SLAVE;
+
+ /*
+* Section 16.5 of the MPC8610 reference manual says that the SSI needs
+* to be disabled before updating the registers we set here.
+*/
+ write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_SSIEN, 0);
+
+ /*
+* Program the SSI into I2S Slave Non-Network Synchronous mode. Also
+* enable the transmit and receive FIFO.
+*
+* FIXME: Little-endian samples require a different shift dir
+*/
+ write_ssi_mask(&ssi->scr,
+ CCSR_SSI_SCR_I2S_MODE_MASK | CCSR_SSI_SCR_SYN,
+ CCSR_SSI_SCR_TFR_CLK_DIS |
+ i2s_mode |
+ (synchronous ? CCSR_SSI_SCR_SYN : 0));
+
+ write_ssi(CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 |
+CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS |
+CCSR_SSI_STCR_TSCKP, &ssi->stcr);
+
+ write_ssi(CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 |
+CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS |
+CCSR_SSI_SRCR_RSCKP, &ssi->srcr);
+ /*
+* The DC and PM bits are only used if the SSI is the clock master.
+*/
+
+ /*
+* Set the watermark for transmit FIFI 0 and receive FIFO 0. We don't
+* use FIFO 1. We program the transmit water to signal a DMA transfer
+* if there are only two (or fewer) elements left in the FIFO. Two
+* elements equals one frame (left channel, right channel). This value,
+* however, depends on the depth of the transmit buffer.
+*
+* We set the watermark on the same level as the DMA burstsize. For
+* fiq it is probably better to use the biggest possible watermark
+* size.
+*/
+ if (ssi_private->use_dma)
+ wm = ssi_private->fifo_depth - 2;
+ else
+ wm = ssi_private->fifo_depth;
+
+ write_ssi(CCSR_SSI_SFCSR_TFWM0(wm) | CCSR_SSI_SFCSR_RFWM0(wm) |
+ CCSR_SSI_SFCSR_TFWM1(wm) | CCSR_SSI_SFCSR_RFWM1(wm),
+ &ssi->sfcsr);
+
+ /*
+* For non-ac97 setups, we keep the SSI disabled because if we enable
+* it, then the DMA controller will start. It's not supposed to start
+* until the SCR.TE (or SCR.RE) bit is set, but it does anyway. The DMA
+* controller will transfer one "BWC" of data (i.e. the amount of data
+* that the MR.BWC bits are set to). The reason this is bad is because
+* at this point, the PCM driver has not finished initializing the DMA
+* controller.
+*/
+
+
+ /*
+* For ac97 interrupts are enabled with the startup of the substream
+* because it is also running without an active substream. Normally SSI
+* is only enabled when there is a substream.
+*/
+ if (!ssi_private->imx_ac97) {
+ /* Enable the interrupts and DMA requests */
+ if (ssi_private->use_dma)
+ write_ssi(SIER_FLAGS, &ssi
[PATCH v4 06/10] ARM: imx: Export ac97 reset functions
Signed-off-by: Markus Pargmann
---
arch/arm/mach-imx/mach-pca100.c | 7 +--
arch/arm/mach-imx/mach-pcm043.c | 7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index b8b15bb..68badf8 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -208,7 +209,7 @@ static const struct spi_imx_master pca100_spi0_data
__initconst = {
.num_chipselect = ARRAY_SIZE(pca100_spi_cs),
};
-static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
+void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
{
mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT);
gpio_set_value(GPIO_PORTC + 20, 1);
@@ -217,8 +218,9 @@ static void pca100_ac97_warm_reset(struct snd_ac97 *ac97)
mxc_gpio_mode(PC20_PF_SSI1_FS);
msleep(2);
}
+EXPORT_SYMBOL(pca100_ac97_warm_reset);
-static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
+void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
{
mxc_gpio_mode(GPIO_PORTC | 20 | GPIO_GPIO | GPIO_OUT); /* FS */
gpio_set_value(GPIO_PORTC + 20, 0);
@@ -232,6 +234,7 @@ static void pca100_ac97_cold_reset(struct snd_ac97 *ac97)
mxc_gpio_mode(PC22_PF_SSI1_TXD);
msleep(2);
}
+EXPORT_SYMBOL(pca100_ac97_cold_reset);
static const struct imx_ssi_platform_data pca100_ssi_pdata __initconst = {
.ac97_reset = pca100_ac97_cold_reset,
diff --git a/arch/arm/mach-imx/mach-pcm043.c b/arch/arm/mach-imx/mach-pcm043.c
index 8ed533f..4f318ca 100644
--- a/arch/arm/mach-imx/mach-pcm043.c
+++ b/arch/arm/mach-imx/mach-pcm043.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -217,7 +218,7 @@ static iomux_v3_cfg_t pcm043_pads[] = {
#define SD1_GPIO_WPIMX_GPIO_NR(2, 23)
#define SD1_GPIO_CDIMX_GPIO_NR(2, 24)
-static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
{
iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -239,8 +240,9 @@ static void pcm043_ac97_warm_reset(struct snd_ac97 *ac97)
gpio_free(AC97_GPIO_TXFS);
mxc_iomux_v3_setup_pad(txfs);
}
+EXPORT_SYMBOL(pcm043_ac97_warm_reset);
-static void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
+void pcm043_ac97_cold_reset(struct snd_ac97 *ac97)
{
iomux_v3_cfg_t txfs_gpio = MX35_PAD_STXFS4__GPIO2_31;
iomux_v3_cfg_t txfs = MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS;
@@ -286,6 +288,7 @@ err1:
printk("%s failed with %d\n", __func__, ret);
mdelay(1);
}
+EXPORT_SYMBOL(pcm043_ac97_cold_reset);
static const struct imx_ssi_platform_data pcm043_ssi_pdata __initconst = {
.ac97_reset = pcm043_ac97_cold_reset,
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 08/10] ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
Signed-off-by: Markus Pargmann --- sound/soc/fsl/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 3843a18..28af843 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -153,7 +153,7 @@ config SND_SOC_PHYCORE_AC97 select SND_SOC_WM9712 select SND_SOC_IMX_PCM_FIQ select SND_SOC_IMX_AUDMUX - select SND_SOC_IMX_SSI + select SND_SOC_FSL_SSI help Say Y if you want to add support for SoC audio on Phytec phyCORE and phyCARD boards in AC97 mode -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 03/10] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
Cleaner parameter passing for imx-pcm-fiq. Create a seperated fiq-params
struct to pass all arguments.
Signed-off-by: Markus Pargmann
---
Notes:
Changes in v3:
- Using snd_dmaengine_dai_dma_data for dma_params after rebasing onto
dmaengine cleanups.
sound/soc/fsl/imx-pcm-fiq.c | 16 +---
sound/soc/fsl/imx-pcm.h | 9 +
sound/soc/fsl/imx-ssi.c | 7 ++-
sound/soc/fsl/imx-ssi.h | 1 +
4 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c
index 670b96b..c3fdb2f 100644
--- a/sound/soc/fsl/imx-pcm-fiq.c
+++ b/sound/soc/fsl/imx-pcm-fiq.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,7 @@
#include
#include "imx-ssi.h"
+#include "imx-pcm.h"
struct imx_pcm_runtime_data {
unsigned int period;
@@ -283,7 +285,7 @@ static struct snd_soc_platform_driver imx_soc_platform_fiq
= {
int imx_pcm_fiq_init(struct platform_device *pdev)
{
- struct imx_ssi *ssi = platform_get_drvdata(pdev);
+ struct imx_pcm_fiq_params *params = platform_get_drvdata(pdev);
int ret;
ret = claim_fiq(&fh);
@@ -292,15 +294,15 @@ int imx_pcm_fiq_init(struct platform_device *pdev)
return ret;
}
- mxc_set_irq_fiq(ssi->irq, 1);
- ssi_irq = ssi->irq;
+ mxc_set_irq_fiq(params->irq, 1);
+ ssi_irq = params->irq;
- imx_pcm_fiq = ssi->irq;
+ imx_pcm_fiq = params->irq;
- imx_ssi_fiq_base = (unsigned long)ssi->base;
+ imx_ssi_fiq_base = (unsigned long)params->base;
- ssi->dma_params_tx.maxburst = 4;
- ssi->dma_params_rx.maxburst = 6;
+ params->dma_params_tx->maxburst = 4;
+ params->dma_params_rx->maxburst = 6;
ret = snd_soc_register_platform(&pdev->dev, &imx_soc_platform_fiq);
if (ret)
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index b7fa0d7..f592f23 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -32,6 +32,15 @@ imx_pcm_dma_params_init_data(struct imx_dma_data *dma_data,
dma_data->peripheral_type = IMX_DMATYPE_SSI;
}
+struct imx_pcm_fiq_params {
+ int irq;
+ void __iomem *base;
+
+ /* Pointer to original ssi driver to setup tx rx sizes */
+ struct snd_dmaengine_dai_dma_data *dma_params_rx;
+ struct snd_dmaengine_dai_dma_data *dma_params_tx;
+};
+
int snd_imx_pcm_mmap(struct snd_pcm_substream *substream,
struct vm_area_struct *vma);
int imx_pcm_new(struct snd_soc_pcm_runtime *rtd);
diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index 902fab0..f80f4c7 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -601,7 +601,12 @@ static int imx_ssi_probe(struct platform_device *pdev)
goto failed_pdev_fiq_alloc;
}
- platform_set_drvdata(ssi->soc_platform_pdev_fiq, ssi);
+ ssi->fiq_params.irq = ssi->irq;
+ ssi->fiq_params.base = ssi->base;
+ ssi->fiq_params.dma_params_rx = &ssi->dma_params_rx;
+ ssi->fiq_params.dma_params_tx = &ssi->dma_params_tx;
+
+ platform_set_drvdata(ssi->soc_platform_pdev_fiq, &ssi->fiq_params);
ret = platform_device_add(ssi->soc_platform_pdev_fiq);
if (ret) {
dev_err(&pdev->dev, "failed to add platform device\n");
diff --git a/sound/soc/fsl/imx-ssi.h b/sound/soc/fsl/imx-ssi.h
index bb6b3db..20ce7ca 100644
--- a/sound/soc/fsl/imx-ssi.h
+++ b/sound/soc/fsl/imx-ssi.h
@@ -209,6 +209,7 @@ struct imx_ssi {
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct imx_dma_data filter_data_tx;
struct imx_dma_data filter_data_rx;
+ struct imx_pcm_fiq_params fiq_params;
int enabled;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 09/10] ASoC: fsl: Move fsl-ssi binding doc to sound/
fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific device, so it should be moved to sound/ as it connects to differen audio codecs. Signed-off-by: Markus Pargmann --- .../devicetree/bindings/powerpc/fsl/ssi.txt| 73 -- .../devicetree/bindings/sound/fsl,ssi.txt | 73 ++ 2 files changed, 73 insertions(+), 73 deletions(-) delete mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ssi.txt create mode 100644 Documentation/devicetree/bindings/sound/fsl,ssi.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt b/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt deleted file mode 100644 index 5ff76c9..000 --- a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt +++ /dev/null @@ -1,73 +0,0 @@ -Freescale Synchronous Serial Interface - -The SSI is a serial device that communicates with audio codecs. It can -be programmed in AC97, I2S, left-justified, or right-justified modes. - -Required properties: -- compatible: Compatible list, contains "fsl,ssi". -- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on. -- reg: Offset and length of the register set for the device. -- interrupts:where a is the interrupt number and b is a -field that represents an encoding of the sense and -level information for the interrupt. This should be -encoded based on the information in section 2) -depending on the type of interrupt controller you -have. -- interrupt-parent: The phandle for the interrupt controller that -services interrupts for this device. -- fsl,mode: The operating mode for the SSI interface. -"i2s-slave" - I2S mode, SSI is clock slave -"i2s-master" - I2S mode, SSI is clock master -"lj-slave" - left-justified mode, SSI is clock slave -"lj-master" - l.j. mode, SSI is clock master -"rj-slave" - right-justified mode, SSI is clock slave -"rj-master" - r.j., SSI is clock master -"ac97-slave" - AC97 mode, SSI is clock slave -"ac97-master" - AC97 mode, SSI is clock master -- fsl,playback-dma: Phandle to a node for the DMA channel to use for -playback of audio. This is typically dictated by SOC -design. See the notes below. -- fsl,capture-dma: Phandle to a node for the DMA channel to use for -capture (recording) of audio. This is typically dictated -by SOC design. See the notes below. -- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs. -This number is the maximum allowed value for SFCSR[TFWM0]. -- fsl,ssi-asynchronous: -If specified, the SSI is to be programmed in asynchronous -mode. In this mode, pins SRCK, STCK, SRFS, and STFS must -all be connected to valid signals. In synchronous mode, -SRCK and SRFS are ignored. Asynchronous mode allows -playback and capture to use different sample sizes and -sample rates. Some drivers may require that SRCK and STCK -be connected together, and SRFS and STFS be connected -together. This would still allow different sample sizes, -but not different sample rates. - -Optional properties: -- codec-handle: Phandle to a 'codec' node that defines an audio -codec connected to this SSI. This node is typically -a child of an I2C or other control node. - -Child 'codec' node required properties: -- compatible: Compatible list, contains the name of the codec - -Child 'codec' node optional properties: -- clock-frequency: The frequency of the input clock, which typically comes -from an on-board dedicated oscillator. - -Notes on fsl,playback-dma and fsl,capture-dma: - -On SOCs that have an SSI, specific DMA channels are hard-wired for playback -and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for -playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for -playback and DMA channel 3 for capture. The developer can choose which -DMA controller to use, but the channels themselves are hard-wired. The -purpose of these two properties is to represent this hardware design. - -The device tree nodes for the DMA channels that are referenced by -"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with -"fsl,ssi-dma-channel". The SOC-specific compatible string (e.g. -"fsl,mpc8610-dma-channel") can remain. If these nodes are left as -"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA -drivers (fsldma) will attempt to use th
[PATCH v4 02/10] ASoC: imx-pcm-dma: DT support
This patch adds the possibility to pass a of_node as platform_data which
is used by generic-pcm-dma to request a DMA slave channel.
Signed-off-by: Markus Pargmann
---
sound/soc/fsl/imx-pcm-dma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index c246fb5..8945d22 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config
imx_dmaengine_pcm_config = {
int imx_pcm_dma_init(struct platform_device *pdev)
{
+ if (pdev->dev.platform_data)
+ pdev->dev.of_node = pdev->dev.platform_data;
+
return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
- SND_DMAENGINE_PCM_FLAG_NO_DT |
SND_DMAENGINE_PCM_FLAG_COMPAT);
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 04/10] ASoC: fsl-ssi: Add support for imx-pcm-fiq
Add support for non-dma pcm for imx platforms with imx-pcm-fiq support.
Instead of imx-pcm-audio, in this case imx-pcm-fiq-audio device is added
and the SIER flags are set differently.
We need imx-pcm-fiq for some boards that use an incompatible codec.
imx-pcm-fiq handles those codecs differently and allows to operate with
them. DMA is not possible because some data sent by the codecs, e.g.
wm9712, is not in the datastream. Also some data is mixed up in the
fifos, so that we need to sort them out manually.
Signed-off-by: Markus Pargmann
---
Notes:
Changes in v4:
- Add a comment about the reason why we add a imx-pcm-fiq device.
- Change commit message to include information about the usage of
imx-pcm-fiq
Changes in v3:
- Rename bool "dma" to "use_dma"
sound/soc/fsl/fsl_ssi.c | 94 +
1 file changed, 80 insertions(+), 14 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 0f0bed6..5165d41 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -8,6 +8,26 @@
* 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.
+ *
+ *
+ * Some notes why imx-pcm-fiq is used instead of DMA on some boards:
+ *
+ * The i.MX SSI core has some nasty limitations in AC97 mode. While most
+ * sane processor vendors have a FIFO per AC97 slot, the i.MX has only
+ * one FIFO which combines all valid receive slots. We cannot even select
+ * which slots we want to receive. The WM9712 with which this driver
+ * was developed with always sends GPIO status data in slot 12 which
+ * we receive in our (PCM-) data stream. The only chance we have is to
+ * manually skip this data in the FIQ handler. With sampling rates different
+ * from 48000Hz not every frame has valid receive data, so the ratio
+ * between pcm data and GPIO status data changes. Our FIQ handler is not
+ * able to handle this, hence this driver only works with 48000Hz sampling
+ * rate.
+ * Reading and writing AC97 registers is another challenge. The core
+ * provides us status bits when the read register is updated with *another*
+ * value. When we read the same register two times (and the register still
+ * contains the same value) these status bits are not set. We work
+ * around this by not polling these bits but only wait a fixed delay.
*/
#include
@@ -121,12 +141,14 @@ struct fsl_ssi_private {
bool new_binding;
bool ssi_on_imx;
+ bool use_dma;
struct clk *clk;
struct platform_device *imx_pcm_pdev;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
struct imx_dma_data filter_data_tx;
struct imx_dma_data filter_data_rx;
+ struct imx_pcm_fiq_params fiq_params;
struct {
unsigned int rfrc;
@@ -356,7 +378,12 @@ static int fsl_ssi_startup(struct snd_pcm_substream
*substream,
*/
/* Enable the interrupts and DMA requests */
- write_ssi(SIER_FLAGS, &ssi->sier);
+ if (ssi_private->use_dma)
+ write_ssi(SIER_FLAGS, &ssi->sier);
+ else
+ write_ssi(CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TFE0_EN |
+ CCSR_SSI_SIER_RIE |
+ CCSR_SSI_SIER_RFF0_EN, &ssi->sier);
/*
* Set the watermark for transmit FIFI 0 and receive FIFO 0. We
@@ -550,7 +577,7 @@ static int fsl_ssi_dai_probe(struct snd_soc_dai *dai)
{
struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(dai);
- if (ssi_private->ssi_on_imx) {
+ if (ssi_private->ssi_on_imx && ssi_private->use_dma) {
dai->playback_dma_data = &ssi_private->dma_params_tx;
dai->capture_dma_data = &ssi_private->dma_params_rx;
}
@@ -695,6 +722,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
sizeof(fsl_ssi_dai_template));
ssi_private->cpu_dai_drv.name = ssi_private->name;
+ ssi_private->use_dma = !of_property_read_bool(np, "fsl,imx-fiq");
+
/* Get the addresses and IRQ */
ret = of_address_to_resource(np, 0, &res);
if (ret) {
@@ -716,12 +745,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
goto error_iomap;
}
- /* The 'name' should not have any slashes in it. */
- ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, ssi_private->name,
- ssi_private);
- if (ret < 0) {
- dev_err(&pdev->dev, "could not claim irq %u\n",
ssi_private->irq);
- goto error_irqmap;
+ if (ssi_private->use_dma) {
+ /* The 'name' should not have any slashes in it. */
+ ret = request_irq(
[PATCH v4 01/10] ASoC: phycore-ac97: Add DT support
Add devicetree support for this audio soc fabric driver.
DT initialized drivers do not have real device ids, so
imx-pcm-fiq-audio.0 is used without '.0'.
This patch also simplifies the way audmux ports are configured. Before
there was knowledge about the used board. As the audmux driver knows the
used board, we know use the returned errorcodes to correctly set the
audmux port. So this driver does not have to know which board it is
running on.
Signed-off-by: Markus Pargmann
---
Notes:
Changes in v4:
- New property phytec,audmux to check which audmux setup should be
executed. Checking for fsl,imx21-audmux and fsl,imx31-audmux.
Changes in v3:
- Add some more information in the commit message.
Changes in v2:
- Simplify the driver, by combining audmux port configurations. The
audmux driver actually knows on which platform he is running and
will return the appropriate error code if we use functions for
another platform. So we don't need to have the knowledge about it
in phycore-ac97 and can try both functions. This removes the need
of different compatibilities and renames it to phycore-ac97.
- Use a phandle for the cpu_dai link.
- Add devicetree binding documentation.
- Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
Changes in v2:
- Simplify the driver, by combining audmux port configurations. The
audmux driver actually knows on which platform he is running and
will return the appropriate error code if we use functions for
another platform. So we don't need to have the knowledge about it
in phycore-ac97 and can try both functions. This removes the need
of different compatibilities and renames it to imx27-ac97.
- Use a phandle for the cpu_dai link.
- Add devicetree binding documentation.
- Rename binding to phytec,phycore-ac97 and fsl,ssi to phytec,ssi
.../bindings/sound/phytec,phycore-ac97.txt | 14 ++
sound/soc/fsl/phycore-ac97.c | 166 ++---
2 files changed, 158 insertions(+), 22 deletions(-)
create mode 100644
Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
diff --git a/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
new file mode 100644
index 000..41201ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
@@ -0,0 +1,14 @@
+Phytec phycore AC97
+
+Required properties:
+- compatible: "phytec,phycore-ac97"
+- phytec,ssi: A phandle to the ssi device that is connected to ac97.
+- phytec,audmux: A phandle to the audmux device.
+
+Example:
+
+sound {
+ compatible = "phytec,phycore-ac97";
+ phytec,ssi = <&ssi1>;
+ phytec,audmux = <&audmux>;
+};
diff --git a/sound/soc/fsl/phycore-ac97.c b/sound/soc/fsl/phycore-ac97.c
index f8da6dd..d9f3ac7 100644
--- a/sound/soc/fsl/phycore-ac97.c
+++ b/sound/soc/fsl/phycore-ac97.c
@@ -21,7 +21,10 @@
#include "imx-audmux.h"
+#define DRV_NAME "phycore-audio-fabric"
+
static struct snd_soc_card imx_phycore;
+static struct device_node *phycore_dai_cpu_node;
static struct snd_soc_ops imx_phycore_hifi_ops = {
};
@@ -32,8 +35,12 @@ static struct snd_soc_dai_link imx_phycore_dai_ac97[] = {
.stream_name= "HiFi",
.codec_dai_name = "wm9712-hifi",
.codec_name = "wm9712-codec",
+#ifdef CONFIG_MACH_IMX27_DT
+ .platform_name = "imx-fiq-pcm-audio",
+#else
.cpu_dai_name = "imx-ssi.0",
.platform_name = "imx-fiq-pcm-audio.0",
+#endif
.ops= &imx_phycore_hifi_ops,
},
};
@@ -45,35 +52,48 @@ static struct snd_soc_card imx_phycore = {
.num_links = ARRAY_SIZE(imx_phycore_dai_ac97),
};
-static struct platform_device *imx_phycore_snd_ac97_device;
+static void phycore_ac97_imx21_audmux(void)
+{
+ imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0,
+ IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+ IMX_AUDMUX_V1_PCR_TFCSEL(3) |
+ IMX_AUDMUX_V1_PCR_TCLKDIR | /* clock is output */
+ IMX_AUDMUX_V1_PCR_RXDSEL(3));
+ imx_audmux_v1_configure_port(3,
+ IMX_AUDMUX_V1_PCR_SYN | /* 4wire mode */
+ IMX_AUDMUX_V1_PCR_TFCSEL(0) |
+ IMX_AUDMUX_V1_PCR_TFSDIR |
+ IMX_AUDMUX_V1_PCR_RXDSEL(0));
+}
+
+static void phycore_ac97_imx31_audmux(void)
+{
+ imx_audmux_v2_configure_port(3,
+ IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+ IMX_AUDMUX_V2_PTCR_TFSEL(0) |
+ IMX_AUDMUX_V2_PTCR_TFSDIR,
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0));
+ imx_audmux_v2_configure_port(0,
+ IMX_AUDMUX_V2_PTCR_SYN | /* 4wire mode */
+ IMX_AUDMUX_V2_PTCR_TCSEL(3) |
+ IMX_AUDMUX_V2_PTCR_TCLKDIR,
[PATCH v4 00/10] ASoC: fsl-ssi: ac97-slave support
Hi,
This series adds DT support for phycore-ac97. It is now based on the pcm dma
cleanups from Lars. Beside ac97 support, the series adds fsl-ssi imx-pcm-fiq
and generic DMA binding handling.
Regards,
Markus
Changes in v4:
- phycore-ac97 uses the iomux functions based on audmux phandle now.
- fsl-ssi imx-pcm-fiq got some new comments about problems with imx-ssi and
incompatible codecs
Changes in v3:
- Rebased onto pcm dma cleanup patches
- A lot of cleanups for the fsl-ssi ac97 integration
- Some small changes which are listed in the notes of the patches.
Markus Pargmann (10):
ASoC: phycore-ac97: Add DT support
ASoC: imx-pcm-dma: DT support
ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
ASoC: fsl-ssi: Add support for imx-pcm-fiq
ASoC: fsl-ssi: Use generic DMA bindings if possible
ARM: imx: Export ac97 reset functions
ASoC: fsl-ssi: imx ac97 support
ASoC: fsl: Kconfig: Use fsl-ssi for phycore-ac97
ASoC: fsl: Move fsl-ssi binding doc to sound/
ASoC: fsl: Update fsl-ssi binding doc
Documentation/devicetree/bindings/{powerpc/fsl/ssi.txt => sound/fsl,ssi.txt} |
10 ++
Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt |
14 ++
arch/arm/mach-imx/mach-pca100.c |
7 +-
arch/arm/mach-imx/mach-pcm043.c |
7 +-
sound/soc/fsl/Kconfig|
2 +-
sound/soc/fsl/fsl_ssi.c |
512 --
sound/soc/fsl/imx-pcm-dma.c |
4 +-
sound/soc/fsl/imx-pcm-fiq.c |
16 +-
sound/soc/fsl/imx-pcm.h |
9 ++
sound/soc/fsl/imx-ssi.c |
7 +-
sound/soc/fsl/imx-ssi.h |
1 +
sound/soc/fsl/phycore-ac97.c |
166 ---
12 files changed, 633 insertions(+), 122 deletions(-)
rename Documentation/devicetree/bindings/{powerpc/fsl/ssi.txt =>
sound/fsl,ssi.txt} (88%)
create mode 100644
Documentation/devicetree/bindings/sound/phytec,phycore-ac97.txt
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 2/2] ARM: DT: kernel: DT cpu node bindings update
On Wed, 17 Apr 2013 09:14:46 -0600, Stephen Warren wrote: > On 04/17/2013 03:14 AM, Mark Rutland wrote: > > Hi Stephen, > > > >>> + - enable-method > >>> + Usage: required on ARM 64-bit systems, optional on ARM 32-bit > >>> +systems > >>> + Value type: > >>> + Definition: On ARM 64-bit systems must be "spin-table" [1]. > >> > >> Can that be an integer instead? with dtc+cpp support, that shouldn't > >> hurt the eyes too much any more. > > > > The "enable-method" property is described as a stringlist by ePAPR, and is > > currently in use on arm64 as such. It *must* remain a string(list) for > > arm64. > > > > Having it as an integer for arm is only going to cause us additional work, > > makes it impossible to share a common dt between 64bit and 32bit, and goes > > against the standard. I think it should be a stringlist for arm. > > OK, that's a great reason for this case. > > I hope we don't introduce any more standards that use strings, but that > may just be my personal preference... We've got lots of bindings using strings like this. I don't really see any problem with it. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper wrote: > On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote: > > On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper wrote: > > > On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote: > > >> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray > > >> wrote: > > >> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: > > >> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges" > > >> > > property of a PCI host device, is found in both Microblaze and > > >> > > PowerPC > > >> > > architectures. These implementations are nearly identical. This patch > > >> > > moves this common code to a common place. > > >> > > > > >> > > Signed-off-by: Andrew Murray > > >> > > Signed-off-by: Liviu Dudau > > >> > > Reviewed-by: Rob Herring > > >> > > Tested-by: Thomas Petazzoni > > >> > > Tested-by: Linus Walleij > > >> > > Acked-by: Michal Simek > > >> > > --- > > >> > > arch/microblaze/include/asm/pci-bridge.h |5 +- > > >> > > arch/microblaze/pci/pci-common.c | 192 > > >> > > > > >> > > arch/powerpc/include/asm/pci-bridge.h|5 +- > > >> > > arch/powerpc/kernel/pci-common.c | 192 > > >> > > > > >> > > > >> > Is there anyone on linuxppc-dev/linux-mips that can help test this > > >> > patchset? > > >> > > > >> > I've tested that it builds on powerpc with a variety of configs (some > > >> > which > > >> > include fsl_pci.c implementation). Though I don't have hardware to > > >> > verify that > > >> > it works. > > >> > > > >> > I haven't tested this builds or runs on MIPS. > > >> > > > >> > You shouldn't see any difference in behaviour or new warnings and PCI > > >> > devices > > >> > should continue to operate as before. > > >> > > >> I've got through a line-by-line comparison between powerpc, microblaze, > > >> and then new code. The differences are purely cosmetic, so I have > > >> absolutely no concerns about this patch. I've applied it to my tree. > > > > > > oops. Due to the number of dependencies the mvebu-pcie series has (this > > > being one of them, we (arm-soc/mvebu) asked if we could take this > > > through our tree. Rob Herring agreed to this several days ago. Is this > > > a problem for you? > > > > > > It would truly (dogs and cats living together) upset the apple cart for > > > us at this stage to pipe these through a different tree... > > > > Not a problem at all. I'll drop it. > > Great! Thanks. You can add my Acked-by: Grant Likely to the first patch. I've not reviewed out the second or third patches yet. None of this appears to be in linux-next yet. I've boot tested on PowerPC, but that isn't the same as an ack by the PowerPC maintainers. It is probably too late for the whole now since we're after -rc7. However, if you ask me to, I have absolutely no problem putting the first patch into my tree for v3.10 merging. I went over the patch line-by-line and am convinced that it is functionally identical. Let me know if you need me to do this. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/6] DT: add vendor prefixes for Ralink
On Tue, 16 Apr 2013 11:12:37 +0200, John Crispin wrote: > Signed-off-by: John Crispin For the whole series: Acked-by: Grant Likely Please merge via a MIPS tree. g. > --- > 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 19e1ef7..6527412 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -41,6 +41,7 @@ onnnON Semiconductor Corp. > picochip Picochip Ltd > powervr PowerVR (deprecated, use img) > qcom Qualcomm, Inc. > +ralink Mediatek/Ralink Technology Corp. > ramtron Ramtron International > realtek Realtek Semiconductor Corp. > renesas Renesas Electronics Corporation > -- > 1.7.10.4 > > ___ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/6] DT: add vendor prefixes for Ralink
On 18/04/13 14:50, Grant Likely wrote: On Tue, 16 Apr 2013 11:12:37 +0200, John Crispin wrote: Signed-off-by: John Crispin For the whole series: Acked-by: Grant Likely Please merge via a MIPS tree. g. Thank you ! ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote: > On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray wrote: > > > This patch converts the pci_load_of_ranges function to use the new common > > of_pci_range_parser. > > > > Signed-off-by: Andrew Murray > > Signed-off-by: Liviu Dudau > > Reviewed-by: Rob Herring > > Tested-by: Linus Walleij Jason - you may not have seen this, but here (Linus Walleij) is another Tested-by to add to this patch in your tree (if you can). Andrew Murray ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 1/2] imxfb: Set alpha value of the framebuffer
From: Christian Hemp
Based on Sascha Hauer's patch i.MX27 clock: Do not disable lcd clocks during
startup.
This patch gives a interface to chance the alphavalue of the framebuffer.
Signed-off-by: Christian Hemp
rebased to 3.7
Signed-off-by: Markus Pargmann
---
drivers/video/imxfb.c | 35 +++
include/linux/platform_data/video-imxfb.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..ef2b587 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
@@ -112,6 +113,10 @@
#define LCDISR_EOF (1<<1)
#define LCDISR_BOF (1<<0)
+#define LCDC_LGWCR 0x64
+#define LGWCR_GWAV(alpha) (((alpha) & 0xff) << 24)
+#define LGWCR_GWE (1 << 22)
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
@@ -610,6 +615,35 @@ static int imxfb_blank(int blank, struct fb_info *info)
return 0;
}
+static int imxfb_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ struct imxfb_info *fbi = info->par;
+ int alpha, ret = 0;
+ unsigned int tmp;
+
+ switch (cmd) {
+ case IMXFB_ALPHA:
+ if (get_user(alpha, (int __user *)arg)) {
+ ret = -EFAULT;
+ } else {
+ tmp = readl(fbi->regs + LCDC_LGWCR);
+ tmp &= ~LGWCR_GWAV(0xff);
+ tmp |= LGWCR_GWAV(alpha);
+ if (!alpha)
+ tmp &= ~LGWCR_GWE;
+ else
+ tmp |= LGWCR_GWE;
+ writel(tmp , fbi->regs + LCDC_LGWCR);
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
static struct fb_ops imxfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = imxfb_check_var,
@@ -619,6 +653,7 @@ static struct fb_ops imxfb_ops = {
.fb_copyarea= cfb_copyarea,
.fb_imageblit = cfb_imageblit,
.fb_blank = imxfb_blank,
+ .fb_ioctl = imxfb_ioctl,
};
/*
diff --git a/include/linux/platform_data/video-imxfb.h
b/include/linux/platform_data/video-imxfb.h
index 9de8f06..ce3875f 100644
--- a/include/linux/platform_data/video-imxfb.h
+++ b/include/linux/platform_data/video-imxfb.h
@@ -51,6 +51,9 @@
#define DMACR_HM(x)(((x) & 0xf) << 16)
#define DMACR_TM(x)((x) & 0xf)
+#define IMXFB_IOW(num, dtype) _IOW('I', num, dtype)
+#define IMXFB_ALPHAIMXFB_IOW(31, int)
+
struct imx_fb_videomode {
struct fb_videomode mode;
u32 pcr;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 2/2] video: imxfb: Add DT support
Add devicetree support for imx framebuffer driver. It uses the generic
display bindings and helper functions.
Signed-off-by: Markus Pargmann
Cc: Fabio Estevam
Cc: Mark Rutland
---
Notes:
Changes in v4:
- Remove eukrea specific dmacr property.
- Add optional dmacr property. If not present, the dmacr reset value is not
changed.
Changes in v3:
- Fix returncodes of of_read_mode function and print error messages
- Introduce a lower bound check for bits per pixel
- Calculate correct bytes per pixel value before using it for the
calculation of
memory size
- Change DT property names
Changes in v2:
- Removed pwmr register property
- Cleanup of devicetree binding documentation
- Use default values for pwmr and lscr1
.../devicetree/bindings/video/fsl,imx-fb.txt | 51 ++
drivers/video/imxfb.c | 194 +
2 files changed, 210 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 000..aff16a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,51 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : "fsl,-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+ Documentation/devicetree/bindings/video/display-timing.txt
+ Additional, the display node has to define properties:
+ - fsl,bpp: Bits per pixel
+ - fsl,pcr: LCDC PCR value
+
+Optional properties:
+- fsl,dmacr: DMA Control Register value. This is optional. By default, the
+ register is not modified as recommended by the datasheet.
+- fsl,lscr1: LCDC Sharp Configuration Register value.
+
+Example:
+
+ imxfb: fb@10021000 {
+ compatible = "fsl,imx27-fb", "fsl,imx21-fb";
+ interrupts = <61>;
+ reg = <0x10021000 0x1000>;
+ display = <&display0>;
+ };
+
+ ...
+
+ display0: display0 {
+ model = "Primeview-PD050VL1";
+ native-mode = <&timing_disp0>;
+ fsl,bpp = <16>; /* non-standard but required */
+ fsl,pcr = <0xf0c88080>; /* non-standard but required */
+ display-timings {
+ timing_disp0: 640x480 {
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <112>;
+ hfront-porch = <36>;
+ hsync-len = <32>;
+ vback-porch = <33>;
+ vfront-porch = <33>;
+ vsync-len = <2>;
+ clock-frequency = <2500>;
+ };
+ };
+ };
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index ef2b587..e0230f8 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -32,6 +32,12 @@
#include
#include
#include
+#include
+#include
+
+#include
+#include
+#include
#include
@@ -117,10 +123,11 @@
#define LGWCR_GWAV(alpha) (((alpha) & 0xff) << 24)
#define LGWCR_GWE (1 << 22)
+#define IMXFB_LSCR1_DEFAULT 0x00120300
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
-
/*
* These are the bitfields for each
* display depth that we support.
@@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
};
MODULE_DEVICE_TABLE(platform, imxfb_devtype);
+static struct of_device_id imxfb_of_dev_id[] = {
+ {
+ .compatible = "fsl,imx1-fb",
+ .data = &imxfb_devtype[IMX1_FB],
+ }, {
+ .compatible = "fsl,imx21-fb",
+ .data = &imxfb_devtype[IMX21_FB],
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
+
static inline int is_imx1_fb(struct imxfb_info *fbi)
{
return fbi->devtype == IMX1_FB;
@@ -324,6 +344,9 @@ static const struct imx_fb_videomode
*imxfb_find_mode(struct imxfb_info *fbi)
struct imx_fb_videomode *m;
int i;
+ if (!fb_mode)
+ return &fbi->mode[0];
+
for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
if (!strcmp(m->mode.name, fb_mode))
return m;
@@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device
*bl)
struct imxfb_info *fbi = bl_get_data(bl);
int brightness = bl->props.brightness;
+
[PATCH v4 0/2] video: imxfb DT support
Hi, This series adds DT support for imxfb. Changes are listed in the notes section of each patch. Regards, Markus Christian Hemp (1): imxfb: Set alpha value of the framebuffer Markus Pargmann (1): video: imxfb: Add DT support Documentation/devicetree/bindings/video/fsl,imx-fb.txt | 51 ++ drivers/video/imxfb.c | 229 +++- include/linux/platform_data/video-imxfb.h | 3 ++ 3 files changed, 248 insertions(+), 35 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Thu, Apr 18, 2013 at 01:48:32PM +0100, Grant Likely wrote: > On Wed, 17 Apr 2013 12:22:23 -0400, Jason Cooper wrote: > > On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote: > > > On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper > > > wrote: > > > > On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote: > > > >> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray > > > >> wrote: > > > >> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: > > > >> > > The pci_process_bridge_OF_ranges function, used to parse the > > > >> > > "ranges" > > > >> > > property of a PCI host device, is found in both Microblaze and > > > >> > > PowerPC > > > >> > > architectures. These implementations are nearly identical. This > > > >> > > patch > > > >> > > moves this common code to a common place. > > > >> > > > > > >> > > Signed-off-by: Andrew Murray > > > >> > > Signed-off-by: Liviu Dudau > > > >> > > Reviewed-by: Rob Herring > > > >> > > Tested-by: Thomas Petazzoni > > > >> > > Tested-by: Linus Walleij > > > >> > > Acked-by: Michal Simek > > > >> > > --- > > > >> > > arch/microblaze/include/asm/pci-bridge.h |5 +- > > > >> > > arch/microblaze/pci/pci-common.c | 192 > > > >> > > > > > >> > > arch/powerpc/include/asm/pci-bridge.h|5 +- > > > >> > > arch/powerpc/kernel/pci-common.c | 192 > > > >> > > > > > >> > > > > >> > Is there anyone on linuxppc-dev/linux-mips that can help test this > > > >> > patchset? > > > >> > > > > >> > I've tested that it builds on powerpc with a variety of configs > > > >> > (some which > > > >> > include fsl_pci.c implementation). Though I don't have hardware to > > > >> > verify that > > > >> > it works. > > > >> > > > > >> > I haven't tested this builds or runs on MIPS. > > > >> > > > > >> > You shouldn't see any difference in behaviour or new warnings and > > > >> > PCI devices > > > >> > should continue to operate as before. > > > >> > > > >> I've got through a line-by-line comparison between powerpc, microblaze, > > > >> and then new code. The differences are purely cosmetic, so I have > > > >> absolutely no concerns about this patch. I've applied it to my tree. > > > > > > > > oops. Due to the number of dependencies the mvebu-pcie series has (this > > > > being one of them, we (arm-soc/mvebu) asked if we could take this > > > > through our tree. Rob Herring agreed to this several days ago. Is this > > > > a problem for you? > > > > > > > > It would truly (dogs and cats living together) upset the apple cart for > > > > us at this stage to pipe these through a different tree... > > > > > > Not a problem at all. I'll drop it. > > > > Great! Thanks. > > You can add my Acked-by: Grant Likely to the > first patch. I've not reviewed out the second or third patches yet. > > None of this appears to be in linux-next yet. I've boot tested on > PowerPC, but that isn't the same as an ack by the PowerPC maintainers. > It is probably too late for the whole now since we're after -rc7. > However, if you ask me to, I have absolutely no problem putting the > first patch into my tree for v3.10 merging. I went over the patch > line-by-line and am convinced that it is functionally identical. > > Let me know if you need me to do this. Thanks for the offer, Olof just pulled the branch last night (my PRs were a little late trying to sort all this out), so it should be in shortly. FYI: 65ee348 of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC is in arm-soc/mvebu/drivers as well as arm-soc/next/drivers (and arm-soc/for-next if you want to test merging everything...) thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Thu, Apr 18, 2013 at 01:59:10PM +0100, Andrew Murray wrote: > On Wed, Apr 17, 2013 at 04:42:48PM +0100, Linus Walleij wrote: > > On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray > > wrote: > > > > > This patch converts the pci_load_of_ranges function to use the new common > > > of_pci_range_parser. > > > > > > Signed-off-by: Andrew Murray > > > Signed-off-by: Liviu Dudau > > > Reviewed-by: Rob Herring > > > > Tested-by: Linus Walleij > > Jason - you may not have seen this, but here (Linus Walleij) is another > Tested-by > to add to this patch in your tree (if you can). Thanks, I saw it. Unfortunately, the PR was already sent, and the branch is now pulled into arm-soc. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND v5 2/2] DMA: imx-dma: imxdma->dev used uninitialized
imxdma->dev is used for dev_warn before it was set. Signed-off-by: Markus Pargmann --- drivers/dma/imx-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c index 8849d03..0d42d0a 100644 --- a/drivers/dma/imx-dma.c +++ b/drivers/dma/imx-dma.c @@ -1067,6 +1067,7 @@ static int __init imxdma_probe(struct platform_device *pdev) if (!imxdma) return -ENOMEM; + imxdma->dev = &pdev->dev; imxdma->devtype = pdev->id_entry->driver_data; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -1171,7 +1172,6 @@ static int __init imxdma_probe(struct platform_device *pdev) &imxdma->dma_device.channels); } - imxdma->dev = &pdev->dev; imxdma->dma_device.dev = &pdev->dev; imxdma->dma_device.device_alloc_chan_resources = imxdma_alloc_chan_resources; -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RESEND v5 1/2] dma: imx-dma: Add oftree support
Adding devicetree support for imx-dma driver. Use driver name for
function 'imx_dma_is_general_purpose' because the devicename for
devicetree initialized devices is different.
Signed-off-by: Markus Pargmann
Reviewed-by: Arnd Bergmann
---
Notes:
Changes in V5:
- Style fix
- Documentation reference
Changes in V4:
- Directly use "imxdma_channel" as proposed by Arnd. This removes the
allocation of imx_dma_data.
- Simplify function imx_dma_is_general_purpose using driver names.
Changes in V3:
- Create a imxdma translate function to pass the device object into the
filter function.
Changes in V2:
- Change the driver to use generic DMA DT bindings.
- Add a imx-dma filter function that sets the dma request line in
private data.
.../devicetree/bindings/dma/fsl-imx-dma.txt| 48 ++
drivers/dma/imx-dma.c | 74 ++
include/linux/platform_data/dma-imx.h | 6 +-
3 files changed, 124 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
new file mode 100644
index 000..2717ecb
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
@@ -0,0 +1,48 @@
+* Freescale Direct Memory Access (DMA) Controller for i.MX
+
+This document will only describe differences to the generic DMA Controller and
+DMA request bindings as described in dma/dma.txt .
+
+* DMA controller
+
+Required properties:
+- compatible : Should be "fsl,-dma". chip can be imx1, imx21 or imx27
+- reg : Should contain DMA registers location and length
+- interrupts : First item should be DMA interrupt, second one is optional and
+should contain DMA Error interrupt
+- #dma-cells : Has to be 1. imx-dma does not support anything else.
+
+Optional properties:
+- #dma-channels : Number of DMA channels supported. Should be 16.
+- #dma-requests : Number of DMA requests supported.
+
+Example:
+
+ dma: dma@10001000 {
+ compatible = "fsl,imx27-dma";
+ reg = <0x10001000 0x1000>;
+ interrupts = <32 33>;
+ #dma-cells = <1>;
+ #dma-channels = <16>;
+ };
+
+
+* DMA client
+
+Clients have to specify the DMA requests with phandles in a list.
+
+Required properties:
+- dmas: List of one or more DMA request specifiers. One DMA request specifier
+consists of a phandle to the DMA controller followed by the integer
+specifiying the request line.
+- dma-names: List of string identifiers for the DMA requests. For the correct
+names, have a look at the specific client driver.
+
+Example:
+
+ sdhci1: sdhci@10013000 {
+ ...
+ dmas = <&dma 7>;
+ dma-names = "rx-tx";
+ ...
+ };
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 70b8975..8849d03 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -186,6 +188,11 @@ struct imxdma_engine {
enum imx_dma_type devtype;
};
+struct imxdma_filter_data {
+ struct imxdma_engine*imxdma;
+ int request;
+};
+
static struct platform_device_id imx_dma_devtype[] = {
{
.name = "imx1-dma",
@@ -202,6 +209,22 @@ static struct platform_device_id imx_dma_devtype[] = {
};
MODULE_DEVICE_TABLE(platform, imx_dma_devtype);
+static const struct of_device_id imx_dma_of_dev_id[] = {
+ {
+ .compatible = "fsl,imx1-dma",
+ .data = &imx_dma_devtype[IMX1_DMA],
+ }, {
+ .compatible = "fsl,imx21-dma",
+ .data = &imx_dma_devtype[IMX21_DMA],
+ }, {
+ .compatible = "fsl,imx27-dma",
+ .data = &imx_dma_devtype[IMX27_DMA],
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, imx_dma_of_dev_id);
+
static inline int is_imx1_dma(struct imxdma_engine *imxdma)
{
return imxdma->devtype == IMX1_DMA;
@@ -997,13 +1020,49 @@ static void imxdma_issue_pending(struct dma_chan *chan)
spin_unlock_irqrestore(&imxdma->lock, flags);
}
+static bool imxdma_filter_fn(struct dma_chan *chan, void *param)
+{
+ struct imxdma_filter_data *fdata = param;
+ struct imxdma_channel *imxdma_chan = to_imxdma_chan(chan);
+
+ if (chan->device->dev != fdata->imxdma->dev)
+ return false;
+
+ imxdma_chan->dma_request = fdata->request;
+ chan->private = NULL;
+
+ return true;
+}
+
+static struct dma_chan *imxdma_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ int count = dma_spec->args_count;
+ struct imxdma_engine *imxdma =
[PATCH RESEND v5 0/2] dma: imx-dma: OFTree support
Hi, this series adds support for the generic DMA DT bindings. Regards, Markus Markus Pargmann (2): dma: imx-dma: Add oftree support DMA: imx-dma: imxdma->dev used uninitialized Documentation/devicetree/bindings/dma/fsl-imx-dma.txt | 48 drivers/dma/imx-dma.c | 76 +++- include/linux/platform_data/dma-imx.h | 6 ++ 3 files changed, 125 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray wrote:
> This patch factors out common implementation patterns to reduce overall kernel
> code and provide a means for host bridge drivers to directly obtain struct
> resources from the DT's ranges property without relying on architecture
> specific
> DT handling. This will make it easier to write archiecture independent host
> bridge
> drivers and mitigate against further duplication of DT parsing code.
>
> This patch can be used in the following way:
>
> struct of_pci_range_parser parser;
> struct of_pci_range range;
>
> if (of_pci_range_parser(&parser, np))
> ; //no ranges property
>
> for_each_of_pci_range(&parser, &range) {
>
> /*
> directly access properties of the address range, e.g.:
> range.pci_space, range.pci_addr, range.cpu_addr,
> range.size, range.flags
>
> alternatively obtain a struct resource, e.g.:
> struct resource res;
> of_pci_range_to_resource(&range, np, &res);
> */
> }
>
> Additionally the implementation takes care of adjacent ranges and merges them
> into a single range (as was the case with powerpc and microblaze).
>
> Signed-off-by: Andrew Murray
> Signed-off-by: Liviu Dudau
> Signed-off-by: Thomas Petazzoni
> Reviewed-by: Rob Herring
> Tested-by: Thomas Petazzoni
> Tested-by: Linus Walleij
Acked-by: Grant Likely
But comments below...
> ---
> drivers/of/address.c | 67 ++
> drivers/of/of_pci.c| 113
>
> include/linux/of_address.h | 46 ++
> 3 files changed, 154 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..6eec70c 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev,
> int bar,
> return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
> }
> EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +int of_pci_range_parser(struct of_pci_range_parser *parser,
> + struct device_node *node)
> +{
> + const int na = 3, ns = 2;
> + int rlen;
> +
> + parser->node = node;
> + parser->pna = of_n_addr_cells(node);
> + parser->np = parser->pna + na + ns;
> +
> + parser->range = of_get_property(node, "ranges", &rlen);
> + if (parser->range == NULL)
> + return -ENOENT;
> +
> + parser->end = parser->range + rlen / sizeof(__be32);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_range_parser);
"of_pci_range_parser_init" would be a clearer name
> +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser
> *parser,
> + struct of_pci_range *range)
Similarly, "of_pci_range_parser_one" would be more consistent.
> +{
> + const int na = 3, ns = 2;
> +
> + if (!range)
> + return NULL;
> +
> + if (!parser->range || parser->range + parser->np > parser->end)
> + return NULL;
> +
> + range->pci_space = parser->range[0];
> + range->flags = of_bus_pci_get_flags(parser->range);
> + range->pci_addr = of_read_number(parser->range + 1, ns);
> + range->cpu_addr = of_translate_address(parser->node,
> + parser->range + na);
> + range->size = of_read_number(parser->range + parser->pna + na, ns);
> +
> + parser->range += parser->np;
> +
> + /* Now consume following elements while they are contiguous */
> + while (parser->range + parser->np <= parser->end) {
> + u32 flags, pci_space;
> + u64 pci_addr, cpu_addr, size;
> +
> + pci_space = be32_to_cpup(parser->range);
> + flags = of_bus_pci_get_flags(parser->range);
> + pci_addr = of_read_number(parser->range + 1, ns);
> + cpu_addr = of_translate_address(parser->node,
> + parser->range + na);
> + size = of_read_number(parser->range + parser->pna + na, ns);
> +
> + if (flags != range->flags)
> + break;
> + if (pci_addr != range->pci_addr + range->size ||
> + cpu_addr != range->cpu_addr + range->size)
> + break;
> +
> + range->size += size;
> + parser->range += parser->np;
> + }
> +
> + return range;
> +}
> +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
> +
> #endif /* CONFIG_PCI */
>
> /*
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 1626172..e5ab604 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -2,6 +2,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) ||
> defined(CONFIG_
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Tue, 16 Apr 2013 11:18:28 +0100, Andrew Murray wrote: > This patch converts the pci_load_of_ranges function to use the new common > of_pci_range_parser. > > Signed-off-by: Andrew Murray > Signed-off-by: Liviu Dudau > Reviewed-by: Rob Herring Looks okay to me, and thank you very much for doing the legwork to merge the common code. Reviewed-by: Grant Likely ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
> On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray
> wrote:
> > This patch factors out common implementation patterns to reduce overall
> > kernel
> > code and provide a means for host bridge drivers to directly obtain struct
> > resources from the DT's ranges property without relying on architecture
> > specific
> > DT handling. This will make it easier to write archiecture independent host
> > bridge
> > drivers and mitigate against further duplication of DT parsing code.
> >
> > This patch can be used in the following way:
> >
> > struct of_pci_range_parser parser;
> > struct of_pci_range range;
> >
> > if (of_pci_range_parser(&parser, np))
> > ; //no ranges property
> >
> > for_each_of_pci_range(&parser, &range) {
> >
> > /*
> > directly access properties of the address range, e.g.:
> > range.pci_space, range.pci_addr, range.cpu_addr,
> > range.size, range.flags
> >
> > alternatively obtain a struct resource, e.g.:
> > struct resource res;
> > of_pci_range_to_resource(&range, np, &res);
> > */
> > }
> >
> > Additionally the implementation takes care of adjacent ranges and merges
> > them
> > into a single range (as was the case with powerpc and microblaze).
> >
> > Signed-off-by: Andrew Murray
> > Signed-off-by: Liviu Dudau
> > Signed-off-by: Thomas Petazzoni
> > Reviewed-by: Rob Herring
> > Tested-by: Thomas Petazzoni
> > Tested-by: Linus Walleij
>
> Acked-by: Grant Likely
>
> But comments below...
>
> > ---
> > drivers/of/address.c | 67 ++
> > drivers/of/of_pci.c| 113
> >
> > include/linux/of_address.h | 46 ++
> > 3 files changed, 154 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 04da786..6eec70c 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node
> > *dev, int bar,
> > return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
> > }
> > EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> > +
> > +int of_pci_range_parser(struct of_pci_range_parser *parser,
> > + struct device_node *node)
> > +{
> > + const int na = 3, ns = 2;
> > + int rlen;
> > +
> > + parser->node = node;
> > + parser->pna = of_n_addr_cells(node);
> > + parser->np = parser->pna + na + ns;
> > +
> > + parser->range = of_get_property(node, "ranges", &rlen);
> > + if (parser->range == NULL)
> > + return -ENOENT;
> > +
> > + parser->end = parser->range + rlen / sizeof(__be32);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(of_pci_range_parser);
>
> "of_pci_range_parser_init" would be a clearer name
>
> > +struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser
> > *parser,
> > + struct of_pci_range *range)
>
> Similarly, "of_pci_range_parser_one" would be more consistent.
>
> > +{
> > + const int na = 3, ns = 2;
> > +
> > + if (!range)
> > + return NULL;
> > +
> > + if (!parser->range || parser->range + parser->np > parser->end)
> > + return NULL;
> > +
> > + range->pci_space = parser->range[0];
> > + range->flags = of_bus_pci_get_flags(parser->range);
> > + range->pci_addr = of_read_number(parser->range + 1, ns);
> > + range->cpu_addr = of_translate_address(parser->node,
> > + parser->range + na);
> > + range->size = of_read_number(parser->range + parser->pna + na, ns);
> > +
> > + parser->range += parser->np;
> > +
> > + /* Now consume following elements while they are contiguous */
> > + while (parser->range + parser->np <= parser->end) {
> > + u32 flags, pci_space;
> > + u64 pci_addr, cpu_addr, size;
> > +
> > + pci_space = be32_to_cpup(parser->range);
> > + flags = of_bus_pci_get_flags(parser->range);
> > + pci_addr = of_read_number(parser->range + 1, ns);
> > + cpu_addr = of_translate_address(parser->node,
> > + parser->range + na);
> > + size = of_read_number(parser->range + parser->pna + na, ns);
> > +
> > + if (flags != range->flags)
> > + break;
> > + if (pci_addr != range->pci_addr + range->size ||
> > + cpu_addr != range->cpu_addr + range->size)
> > + break;
> > +
> > + range->size += size;
> > + parser->range += parser->np;
> > + }
> > +
> > + return range;
> > +}
> > +EXPORT_SYMBOL_GPL(of_pci_process_ranges);
> > +
> > #endif /* CONFIG_PCI */
> >
> > /*
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> > index 1626172
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Thu, Apr 18, 2013 at 02:45:35PM +0100, Grant Likely wrote: > On Tue, 16 Apr 2013 11:18:28 +0100, Andrew Murray > wrote: > > This patch converts the pci_load_of_ranges function to use the new common > > of_pci_range_parser. > > > > Signed-off-by: Andrew Murray > > Signed-off-by: Liviu Dudau > > Reviewed-by: Rob Herring > > Looks okay to me, and thank you very much for doing the legwork to merge > the common code. No problem, though I think there is more than can be done in this area - there is a lot of similar PCI code floating about. > > Reviewed-by: Grant Likely Thanks for the review. Andrew Murray ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND v5 0/2] dma: imx-dma: OFTree support
On Thu, Apr 18, 2013 at 03:21:36PM +0200, Markus Pargmann wrote: > Markus Pargmann (2): > dma: imx-dma: Add oftree support > DMA: imx-dma: imxdma->dev used uninitialized Both, Reviewed-by: Shawn Guo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Regarding dtc+cpp support
On 04/18/2013 04:12 AM, Padma Venkat wrote: > Hi Stephen, > > I am trying to add a header file for samsung audio subsystem clk > definitions, which can be used in kernel and dt files. > I applied following patches posted by you in my working tree. > > > [1/7] kbuild: create an "include chroot" for DT bindings > [2/7] kbuild: fixdep: support concatenated dep files > [3/7] kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc > [4/7] kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp > [5/7] ARM: dt: add header to define GPIO flags > [6/7] ARM: dt: add header to define IRQ flags > [7/7] ARM: dt: create a DT header for the GIC > > I created a header file in > arch/arm/boot/dts/include/clk/samsung-audss-clk.h and I included this > header in driver and dtsi files > > Please see the code snippet in dtsi below. > > #include > /include/ "skeleton.dtsi" > /include/ "exynos5250-pinctrl.dtsi Try making all of the above "#include" ... #include #include "skeleton.dtsi" #include "exynos5250-pinctrl.dtsi > In driver it is compiling successfully but in dtsi files I am getting > the follwing compilation error. > > Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error > FATAL ERROR: Unable to parse input tree > make[1]: *** [arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 > make[1]: *** Waiting for unfinished jobs > DTC arch/arm/boot/dts/exynos5250-snow.dtb > Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error > FATAL ERROR: Unable to parse input tree > make[1]: *** [arch/arm/boot/dts/exynos5250-smdk5250.dtb] Error 1 > Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error > FATAL ERROR: Unable to parse input tree > make[1]: *** [arch/arm/boot/dts/exynos5250-snow.dtb] Error 1 > make: *** [dtbs] Error 2 > make: *** Waiting for unfinished jobs > > where "#include " is the 21st > line in the dtsi file. > > Please let me know if any extra patches are required to solve this > compilation error? I was seeing some compile errors when I had a mixture of /include/ and #include. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [alsa-devel] [PATCH v4 02/10] ASoC: imx-pcm-dma: DT support
On 04/18/2013 02:33 PM, Markus Pargmann wrote:
> This patch adds the possibility to pass a of_node as platform_data which
> is used by generic-pcm-dma to request a DMA slave channel.
>
> Signed-off-by: Markus Pargmann
> ---
> sound/soc/fsl/imx-pcm-dma.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
> index c246fb5..8945d22 100644
> --- a/sound/soc/fsl/imx-pcm-dma.c
> +++ b/sound/soc/fsl/imx-pcm-dma.c
> @@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config
> imx_dmaengine_pcm_config = {
>
> int imx_pcm_dma_init(struct platform_device *pdev)
> {
> + if (pdev->dev.platform_data)
> + pdev->dev.of_node = pdev->dev.platform_data;
In my opinion it's better to use pdev->dev.parent->of_node here. In the ssi
driver you use platform_device_register_data, which will create a copy of
the of_node you pass in as platform data. I'm not quite sure how well this
will work. If you want to continue to use platform_data you should at least
change the code in the ssi driver to not make a copy of the of_node.
- Lars
> +
> return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
> SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
> - SND_DMAENGINE_PCM_FLAG_NO_DT |
> SND_DMAENGINE_PCM_FLAG_COMPAT);
> }
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND v5 1/2] dma: imx-dma: Add oftree support
Hi,
On 04/18/2013 03:21 PM, Markus Pargmann wrote:
[...]
> +static struct dma_chan *imxdma_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + int count = dma_spec->args_count;
> + struct imxdma_engine *imxdma = ofdma->of_dma_data;
> + struct imxdma_filter_data fdata = {
> + .imxdma = imxdma,
> + .request = *(unsigned *)&dma_spec->args[0],
This cast looks rather bogus and shouldn't be necessary.
> + };
> +
> + if (count != 1)
> + return NULL;
I think you need to check count before you access dma_spec->args[0]
> +
> + return dma_request_channel(imxdma->dma_device.cap_mask,
> + imxdma_filter_fn, &fdata);
> +}
> +
[...]
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Thu, Apr 18, 2013 at 3:24 PM, Andrew Murray wrote:
> On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
>> On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray
>> wrote:
>> > /* Act based on address space type */
>> > res = NULL;
>> > - switch ((pci_space >> 24) & 0x3) {
>> > - case 1: /* PCI IO space */
>> > + res_type = range.flags & IORESOURCE_TYPE_BITS;
>> > + if (res_type == IORESOURCE_IO) {
>>
>> Why the change from switch() to an if/else if sequence?
>
> Russell King suggested this change - see
> https://patchwork.kernel.org/patch/2323941/
Umm, that isn't what that link shows. That link shows the patch
already changing to an if/else if construct, and rmk is commenting on
that.
g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [alsa-devel] [PATCH v4 02/10] ASoC: imx-pcm-dma: DT support
On Thu, Apr 18, 2013 at 04:43:43PM +0200, Lars-Peter Clausen wrote:
> On 04/18/2013 02:33 PM, Markus Pargmann wrote:
> > This patch adds the possibility to pass a of_node as platform_data which
> > is used by generic-pcm-dma to request a DMA slave channel.
> >
> > Signed-off-by: Markus Pargmann
> > ---
> > sound/soc/fsl/imx-pcm-dma.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
> > index c246fb5..8945d22 100644
> > --- a/sound/soc/fsl/imx-pcm-dma.c
> > +++ b/sound/soc/fsl/imx-pcm-dma.c
> > @@ -62,9 +62,11 @@ static const struct snd_dmaengine_pcm_config
> > imx_dmaengine_pcm_config = {
> >
> > int imx_pcm_dma_init(struct platform_device *pdev)
> > {
> > + if (pdev->dev.platform_data)
> > + pdev->dev.of_node = pdev->dev.platform_data;
>
> In my opinion it's better to use pdev->dev.parent->of_node here. In the ssi
> driver you use platform_device_register_data, which will create a copy of
> the of_node you pass in as platform data. I'm not quite sure how well this
> will work. If you want to continue to use platform_data you should at least
> change the code in the ssi driver to not make a copy of the of_node.
Thanks, I did not think about using the parent, that is much easier. I
changed it for the next version.
Regards,
Markus
>
> - Lars
>
> > +
> > return snd_dmaengine_pcm_register(&pdev->dev, &imx_dmaengine_pcm_config,
> > SND_DMAENGINE_PCM_FLAG_NO_RESIDUE |
> > - SND_DMAENGINE_PCM_FLAG_NO_DT |
> > SND_DMAENGINE_PCM_FLAG_COMPAT);
> > }
> >
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/3] of/pci: Provide support for parsing PCI DT ranges property
On Thu, Apr 18, 2013 at 04:29:54PM +0100, Grant Likely wrote:
> On Thu, Apr 18, 2013 at 3:24 PM, Andrew Murray wrote:
> > On Thu, Apr 18, 2013 at 02:44:01PM +0100, Grant Likely wrote:
> >> On Tue, 16 Apr 2013 11:18:27 +0100, Andrew Murray
> >> wrote:
> >> > /* Act based on address space type */
> >> > res = NULL;
> >> > - switch ((pci_space >> 24) & 0x3) {
> >> > - case 1: /* PCI IO space */
> >> > + res_type = range.flags & IORESOURCE_TYPE_BITS;
> >> > + if (res_type == IORESOURCE_IO) {
> >>
> >> Why the change from switch() to an if/else if sequence?
> >
> > Russell King suggested this change - see
> > https://patchwork.kernel.org/patch/2323941/
>
> Umm, that isn't what that link shows. That link shows the patch
> already changing to an if/else if construct, and rmk is commenting on
> that.
Arh yes sorry about that. I can't find or remember any good reason why I
changed it from a switch to an if/else :\
Andrew Murray
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND v5 1/2] dma: imx-dma: Add oftree support
On Thu, Apr 18, 2013 at 05:14:37PM +0200, Lars-Peter Clausen wrote:
> Hi,
>
> On 04/18/2013 03:21 PM, Markus Pargmann wrote:
> [...]
> > +static struct dma_chan *imxdma_xlate(struct of_phandle_args *dma_spec,
> > + struct of_dma *ofdma)
> > +{
> > + int count = dma_spec->args_count;
> > + struct imxdma_engine *imxdma = ofdma->of_dma_data;
> > + struct imxdma_filter_data fdata = {
> > + .imxdma = imxdma,
> > + .request = *(unsigned *)&dma_spec->args[0],
>
> This cast looks rather bogus and shouldn't be necessary.
Ah right, I was assuming "args" is void*.
>
> > + };
> > +
> > + if (count != 1)
> > + return NULL;
>
> I think you need to check count before you access dma_spec->args[0]
dma_spec->args is actually a static array of size MAX_PHANDLE_ARGS.
However it is probably cleaner after the check, so I changed both.
Thanks,
Markus
>
> > +
> > + return dma_request_channel(imxdma->dma_device.cap_mask,
> > + imxdma_filter_fn, &fdata);
> > +}
> > +
> [...]
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/2] video: imxfb: Add DT support
On 15:03 Thu 18 Apr , Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
>
> Signed-off-by: Markus Pargmann
> Cc: Fabio Estevam
> Cc: Mark Rutland
> ---
>
> Notes:
> Changes in v4:
> - Remove eukrea specific dmacr property.
> - Add optional dmacr property. If not present, the dmacr reset value is
> not
> changed.
>
> Changes in v3:
> - Fix returncodes of of_read_mode function and print error messages
> - Introduce a lower bound check for bits per pixel
> - Calculate correct bytes per pixel value before using it for the
> calculation of
> memory size
> - Change DT property names
>
> Changes in v2:
> - Removed pwmr register property
> - Cleanup of devicetree binding documentation
> - Use default values for pwmr and lscr1
>
> .../devicetree/bindings/video/fsl,imx-fb.txt | 51 ++
> drivers/video/imxfb.c | 194
> +
> 2 files changed, 210 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> new file mode 100644
> index 000..aff16a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -0,0 +1,51 @@
> +Freescale imx21 Framebuffer
> +
> +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> +
> +Required properties:
> +- compatible : "fsl,-fb", chip should be imx1 or imx21
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : One interrupt of the fb dev
> +
> +Required nodes:
> +- display: Phandle to a display node as described in
> + Documentation/devicetree/bindings/video/display-timing.txt
> + Additional, the display node has to define properties:
> + - fsl,bpp: Bits per pixel
> + - fsl,pcr: LCDC PCR value
> +
> +Optional properties:
> +- fsl,dmacr: DMA Control Register value. This is optional. By default, the
> + register is not modified as recommended by the datasheet.
> +- fsl,lscr1: LCDC Sharp Configuration Register value.
> +
> +Example:
> +
> + imxfb: fb@10021000 {
> + compatible = "fsl,imx27-fb", "fsl,imx21-fb";
you put both when in the doc you request one
> + interrupts = <61>;
> + reg = <0x10021000 0x1000>;
> + display = <&display0>;
> + };
> +
> + ...
> +
> + display0: display0 {
> + model = "Primeview-PD050VL1";
> + native-mode = <&timing_disp0>;
> + fsl,bpp = <16>; /* non-standard but required */
there is a generic binding bit-per-pixel use a cross other IP
> + fsl,pcr = <0xf0c88080>; /* non-standard but required */
> + display-timings {
> + timing_disp0: 640x480 {
> + hactive = <640>;
> + vactive = <480>;
> + hback-porch = <112>;
> + hfront-porch = <36>;
> + hsync-len = <32>;
> + vback-porch = <33>;
> + vfront-porch = <33>;
> + vsync-len = <2>;
> + clock-frequency = <2500>;
> + };
> + };
> + };
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index ef2b587..e0230f8 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -32,6 +32,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
>
> #include
>
> @@ -117,10 +123,11 @@
> #define LGWCR_GWAV(alpha)(((alpha) & 0xff) << 24)
> #define LGWCR_GWE(1 << 22)
>
> +#define IMXFB_LSCR1_DEFAULT 0x00120300
> +
> /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
> static const char *fb_mode;
>
> -
> /*
> * These are the bitfields for each
> * display depth that we support.
> @@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
> };
> MODULE_DEVICE_TABLE(platform, imxfb_devtype);
>
> +static struct of_device_id imxfb_of_dev_id[] = {
> + {
> + .compatible = "fsl,imx1-fb",
> + .data = &imxfb_devtype[IMX1_FB],
> + }, {
> + .compatible = "fsl,imx21-fb",
> + .data = &imxfb_devtype[IMX21_FB],
> + }, {
> + /* sentinel */
> + }
> +};
> +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> +
> static inline int is_imx1_fb(struct imxfb_info *fbi)
> {
> return fbi->devtype == IMX1_FB;
> @@ -324,6 +344,9 @@ static const struct imx_fb_videomode
> *imxfb_find_mode(struct imxfb_info *fbi)
> struct imx_fb_videomode *m;
> int i;
>
> + if (!fb_mode)
> + return &f
Re: Regarding dtc+cpp support
Hi, On Thu, Apr 18, 2013 at 8:19 PM, Jon Hunter wrote: > > On 04/18/2013 04:12 AM, Padma Venkat wrote: >> Hi Stephen, >> >> I am trying to add a header file for samsung audio subsystem clk >> definitions, which can be used in kernel and dt files. >> I applied following patches posted by you in my working tree. >> >> >> [1/7] kbuild: create an "include chroot" for DT bindings >> [2/7] kbuild: fixdep: support concatenated dep files >> [3/7] kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc >> [4/7] kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp >> [5/7] ARM: dt: add header to define GPIO flags >> [6/7] ARM: dt: add header to define IRQ flags >> [7/7] ARM: dt: create a DT header for the GIC >> >> I created a header file in >> arch/arm/boot/dts/include/clk/samsung-audss-clk.h and I included this >> header in driver and dtsi files >> >> Please see the code snippet in dtsi below. >> >> #include >> /include/ "skeleton.dtsi" >> /include/ "exynos5250-pinctrl.dtsi > > Try making all of the above "#include" ... I haven't changed all dts files but I tried below with no success. > > #include > #include "skeleton.dtsi" > #include "exynos5250-pinctrl.dtsi > >> In driver it is compiling successfully but in dtsi files I am getting >> the follwing compilation error. >> >> Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error >> FATAL ERROR: Unable to parse input tree >> make[1]: *** [arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 >> make[1]: *** Waiting for unfinished jobs >> DTC arch/arm/boot/dts/exynos5250-snow.dtb >> Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error >> FATAL ERROR: Unable to parse input tree >> make[1]: *** [arch/arm/boot/dts/exynos5250-smdk5250.dtb] Error 1 >> Error: arch/arm/boot/dts/exynos5250.dtsi:21.1-9 syntax error >> FATAL ERROR: Unable to parse input tree >> make[1]: *** [arch/arm/boot/dts/exynos5250-snow.dtb] Error 1 >> make: *** [dtbs] Error 2 >> make: *** Waiting for unfinished jobs >> >> where "#include " is the 21st >> line in the dtsi file. >> >> Please let me know if any extra patches are required to solve this >> compilation error? > > I was seeing some compile errors when I had a mixture of /include/ and > #include. > > Cheers > Jon Thanks Padma ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 26/28] proc: Supply a function to remove a proc entry by PDE [RFC]
On Tue, Apr 16, 2013 at 12:27 PM, David Howells wrote:
> Supply a function (proc_remove()) to remove a proc entry (and any subtree
> rooted there) by proc_dir_entry pointer rather than by name and (optionally)
> root dir entry pointer. This allows us to eliminate all remaining pde->name
> accesses outside of procfs.
>
> Signed-off-by: David Howells
> cc: linux-a...@vger.kernel.org
> cc: openipmi-develo...@lists.sourceforge.net
> cc: devicetree-discuss@lists.ozlabs.org
> cc: linux-...@vger.kernel.org
> cc: net...@vger.kernel.org
> cc: netfilter-de...@vger.kernel.org
> cc: alsa-de...@alsa-project.org
> ---
>
> drivers/acpi/sbs.c | 21 -
> drivers/char/ipmi/ipmi_msghandler.c |2 +-
> drivers/misc/sgi-gru/gruprocfs.c|2 +-
> drivers/of/base.c | 11 +--
> drivers/pci/proc.c | 12 +++-
For the drivers/pci part:
Acked-by: Bjorn Helgaas
I assume you'll merge this via something other than my tree.
> fs/proc/generic.c |7 +++
> fs/proc/vmcore.c|2 +-
> include/linux/proc_fs.h |2 ++
> kernel/irq/proc.c |6 +-
> net/8021q/vlanproc.c|9 ++---
> net/core/pktgen.c |6 ++
> net/ipv4/netfilter/ipt_CLUSTERIP.c |4 ++--
> net/ipv6/proc.c |3 +--
> net/netfilter/xt_hashlimit.c|4 ++--
> sound/core/info.c | 19 +--
> 15 files changed, 35 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
> index a296e08..b6241ee 100644
> --- a/drivers/acpi/sbs.c
> +++ b/drivers/acpi/sbs.c
> @@ -521,19 +521,6 @@ acpi_sbs_add_fs(struct proc_dir_entry **dir,
> return 0;
> }
>
> -static void
> -acpi_sbs_remove_fs(struct proc_dir_entry **dir,
> - struct proc_dir_entry *parent_dir)
> -{
> - if (*dir) {
> - remove_proc_entry(ACPI_SBS_FILE_INFO, *dir);
> - remove_proc_entry(ACPI_SBS_FILE_STATE, *dir);
> - remove_proc_entry(ACPI_SBS_FILE_ALARM, *dir);
> - remove_proc_entry((*dir)->name, parent_dir);
> - *dir = NULL;
> - }
> -}
> -
> /* Smart Battery Interface */
> static struct proc_dir_entry *acpi_battery_dir = NULL;
>
> @@ -836,8 +823,8 @@ static void acpi_battery_remove(struct acpi_sbs *sbs, int
> id)
> power_supply_unregister(&battery->bat);
> }
> #ifdef CONFIG_ACPI_PROCFS_POWER
> - if (battery->proc_entry)
> - acpi_sbs_remove_fs(&battery->proc_entry, acpi_battery_dir);
> + proc_remove(battery->proc_entry);
> + battery->proc_entry = NULL;
> #endif
> }
>
> @@ -873,8 +860,8 @@ static void acpi_charger_remove(struct acpi_sbs *sbs)
> if (sbs->charger.dev)
> power_supply_unregister(&sbs->charger);
> #ifdef CONFIG_ACPI_PROCFS_POWER
> - if (sbs->charger_entry)
> - acpi_sbs_remove_fs(&sbs->charger_entry, acpi_ac_dir);
> + proc_remove(sbs->charger_entry);
> + sbs->charger_entry = NULL;
> #endif
> }
>
> diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> b/drivers/char/ipmi/ipmi_msghandler.c
> index 1420bbb..4d439d2 100644
> --- a/drivers/char/ipmi/ipmi_msghandler.c
> +++ b/drivers/char/ipmi/ipmi_msghandler.c
> @@ -4541,7 +4541,7 @@ static void __exit cleanup_ipmi(void)
> del_timer_sync(&ipmi_timer);
>
> #ifdef CONFIG_PROC_FS
> - remove_proc_entry(proc_ipmi_root->name, NULL);
> + proc_remove(proc_ipmi_root);
> #endif /* CONFIG_PROC_FS */
>
> driver_unregister(&ipmidriver.driver);
> diff --git a/drivers/misc/sgi-gru/gruprocfs.c
> b/drivers/misc/sgi-gru/gruprocfs.c
> index 950dbe9..797d796 100644
> --- a/drivers/misc/sgi-gru/gruprocfs.c
> +++ b/drivers/misc/sgi-gru/gruprocfs.c
> @@ -355,7 +355,7 @@ static void delete_proc_files(void)
> for (p = proc_files; p->name; p++)
> if (p->entry)
> remove_proc_entry(p->name, proc_gru);
> - remove_proc_entry("gru", proc_gru->parent);
> + proc_remove(proc_gru);
> }
> }
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 321d3ef..9c70436 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1452,16 +1452,7 @@ int of_attach_node(struct device_node *np)
> #ifdef CONFIG_PROC_DEVICETREE
> static void of_remove_proc_dt_entry(struct device_node *dn)
> {
> - struct device_node *parent = dn->parent;
> - struct property *prop = dn->properties;
> -
> - while (prop) {
> - remove_proc_entry(prop->name, dn->pde);
> - prop = prop->next;
> - }
> -
> - if (dn->pde)
> - remove_proc_entry(dn->pde->name, parent->pde);
> + proc_remove(dn->pde);
> }
> #else
> static void of_remove_proc_dt_entry(struct devi
Re: Regarding dtc+cpp support
On 04/18/2013 11:21 AM, Padma Venkat wrote: > Hi, > > On Thu, Apr 18, 2013 at 8:19 PM, Jon Hunter wrote: >> >> On 04/18/2013 04:12 AM, Padma Venkat wrote: >>> Hi Stephen, >>> >>> I am trying to add a header file for samsung audio subsystem clk >>> definitions, which can be used in kernel and dt files. >>> I applied following patches posted by you in my working tree. >>> >>> >>> [1/7] kbuild: create an "include chroot" for DT bindings >>> [2/7] kbuild: fixdep: support concatenated dep files >>> [3/7] kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc >>> [4/7] kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp >>> [5/7] ARM: dt: add header to define GPIO flags >>> [6/7] ARM: dt: add header to define IRQ flags >>> [7/7] ARM: dt: create a DT header for the GIC >>> >>> I created a header file in >>> arch/arm/boot/dts/include/clk/samsung-audss-clk.h and I included this >>> header in driver and dtsi files >>> >>> Please see the code snippet in dtsi below. >>> >>> #include >>> /include/ "skeleton.dtsi" >>> /include/ "exynos5250-pinctrl.dtsi >> >> Try making all of the above "#include" ... > > I haven't changed all dts files but I tried below with no success. I should mentioned that you should also make any /include/ in the *.dtsi above #include too. Cheers Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH] drivers: bus: add ARM CCI support
On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> new file mode 100644
> index 000..81953de
> --- /dev/null
> +++ b/drivers/bus/arm-cci.c
[...]
> +static void notrace cci_port_control(unsigned int port, bool enable)
> +{
> + void __iomem *base = ports[port].base;
> +
> + if (!base)
> + return;
> +
> + writel_relaxed(enable, base + CCI_PORT_CTRL);
> + while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> + ;
cpu_relax()?
> +}
[...]
> +int notrace __cci_control_port_by_device(struct device_node *np, bool enable)
> +{
> + int port = cci_ace_lite_port(np);
> + if (WARN_ONCE(port < 0,
> + "ACE lite port look-up failure, node %p\n", np))
> + return -ENODEV;
> + cci_port_control(port, enable);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(__cci_control_port_by_device);
> +
> +static const struct of_device_id arm_cci_matches[];
Why not just put the definition here then?
> +
> +static int __init cci_driver_probe(struct platform_device *pdev)
You probably want to drop the __init considering device hotplug is not
optional anymore.
> +{
> + const struct of_device_id *match;
> + struct cci_nb_ports const *cci_config;
> + int ret, j, i, nb_ace = 0, nb_ace_lite = 0;
> + struct device_node *np, *cp;
> + const char *match_str;
> +
> + match = of_match_device(arm_cci_matches, &pdev->dev);
> +
> + if (!match)
> + return -ENODEV;
It would be nice if we could get the data field from the of_device_id
without doing the search again. Can we update the of_platform code to
assign some field that you can get from the platform device?
> +
> + cci_config = (struct cci_nb_ports const *)match->data;
> + nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
> + ports = kzalloc(sizeof(*ports) * nb_cci_ports, GFP_KERNEL);
kcalloc()?
> + if (!ports)
> + return -ENOMEM;
> +
> + np = pdev->dev.of_node;
> + cci_ctrl_base = of_iomap(np, 0);
This is a platform driver so we should use non-of functions to map,
platform_get_resource()/ioremap(), etc.
> +}
> +
> +static int __exit cci_driver_remove(struct platform_device *pdev)
> +{
You probably want to drop the __exit here too.
> diff --git a/include/linux/arm-cci.h b/include/linux/arm-cci.h
> new file mode 100644
> index 000..e9514a2
> --- /dev/null
> +++ b/include/linux/arm-cci.h
> @@ -0,0 +1,44 @@
> +
> +#ifndef __LINUX_ARM_CCI_H
> +#define __LINUX_ARM_CCI_H
> +
> +#include
> +#include
> +#include
You can declare
struct device_node;
here to avoid including linux/of.h. Less includes means less circular
dependencies.
> +
> +#ifdef CONFIG_ARM_CCI
> +extern int cci_disable_port_by_cpu(u64 mpidr);
> +extern int __cci_control_port_by_device(struct device_node *np, bool enable);
> +#else
> +static inline int cci_disable_port_by_cpu(u64 mpidr) { return -ENODEV; }
> +static inline int __cci_control_port_by_device(struct device_node *np,
> + bool enable)
> +{
> + return -ENODEV;
> +}
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC v2] video: ARM CLCD: Add DT & CDF support
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them, together with the
Common Display Framework.
The DT provides information about the hardware configuration
and limitations (eg. the largest supported resolution)
but the video modes come exclusively from the Common
Display Framework drivers, referenced to by the standard CDF
binding.
Signed-off-by: Pawel Moll
---
.../devicetree/bindings/video/arm,pl11x.txt| 35 +++
drivers/video/Kconfig |1 +
drivers/video/amba-clcd.c | 247
include/linux/amba/clcd.h |2 +
4 files changed, 285 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt
b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 000..ee9534a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,35 @@
+* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
+
+Required properties:
+
+- compatible : must be one of:
+ "arm,pl110", "arm,primecell"
+ "arm,pl111", "arm,primecell"
+- reg : base address and size of the control registers block
+- interrupts : the combined interrupt
+- clocks : phandles to the CLCD (pixel) clock and the APB clocks
+- clock-names : "clcdclk", "apb_pclk"
+- display : phandle to the display entity connected to the controller
+
+Optional properties:
+
+- label : string describing the controller location and/or usage
+- video-ram : phandle to DT node of the specialized video RAM to be used
+- max-hactive : maximum frame buffer width in pixels
+- max-vactive : maximum frame buffer height in pixels
+- max-bpp : maximum number of bits per pixel
+- big-endian-pixels : defining this property makes the pixel bytes being
+ accessed in Big Endian organization
+
+Example:
+
+ clcd@1f {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f 0x1000>;
+ interrupts = <14>;
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+ clock-names = "clcdclk", "apb_pclk";
+ label = "IOFPGA CLCD";
+ video-ram = <&v2m_vram>;
+ display = <&v2m_muxfpga>;
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 281e548..bad8166 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -340,6 +340,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..853f74c 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -62,6 +67,10 @@ static void clcdfb_disable(struct clcd_fb *fb)
{
u32 val;
+ if (fb->panel->display)
+ display_entity_set_state(fb->panel->display,
+ DISPLAY_ENTITY_STATE_OFF);
+
if (fb->board->disable)
fb->board->disable(fb);
@@ -115,6 +124,11 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
*/
if (fb->board->enable)
fb->board->enable(fb);
+
+ if (fb->panel->display)
+ display_entity_set_state(fb->panel->display,
+ DISPLAY_ENTITY_STATE_ON);
+
}
static int
@@ -304,6 +318,13 @@ static int clcdfb_set_par(struct fb_info *info)
clcdfb_enable(fb, regs.cntl);
+ if (fb->panel->display) {
+ struct videomode mode;
+
+ videomode_from_fb_var_screeninfo(&fb->fb.var, &mode);
+ display_entity_update(fb->panel->display, &mode);
+ }
+
#ifdef DEBUG
printk(KERN_INFO
"CLCD: Registers set to\n"
@@ -542,6 +563,229 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#if defined(CONFIG_OF)
+static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
+ struct display_entity_interface_params *params)
+{
+ int r = params->p.tft_parallel.r_bits;
+ int g = params->p.tft_parallel.g_bits;
+ int b = params->p.tft_parallel.b_bits;
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ panel->cn
Re: [RFC PATCH] drivers: bus: add ARM CCI support
On Thu, 18 Apr 2013, Stephen Boyd wrote:
> On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > new file mode 100644
> > index 000..81953de
> > --- /dev/null
> > +++ b/drivers/bus/arm-cci.c
> [...]
> > +static void notrace cci_port_control(unsigned int port, bool enable)
> > +{
> > + void __iomem *base = ports[port].base;
> > +
> > + if (!base)
> > + return;
> > +
> > + writel_relaxed(enable, base + CCI_PORT_CTRL);
> > + while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
> > + ;
>
> cpu_relax()?
In some cases there is no more cache coherence when this is called and
the hardware might not be in a good state to cope with whatever action
people might be tempted to insert into cpu_relax(). After the CCI is
disabled it is important to keep a low profile and not touch anything
global. With some early hardware revision, even a DMB here was harmful.
Nicolas
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH] drivers: bus: add ARM CCI support
On 04/18/13 10:54, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stephen Boyd wrote:
>
>> On 04/11/13 07:47, Lorenzo Pieralisi wrote:
>>> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
>>> new file mode 100644
>>> index 000..81953de
>>> --- /dev/null
>>> +++ b/drivers/bus/arm-cci.c
>> [...]
>>> +static void notrace cci_port_control(unsigned int port, bool enable)
>>> +{
>>> + void __iomem *base = ports[port].base;
>>> +
>>> + if (!base)
>>> + return;
>>> +
>>> + writel_relaxed(enable, base + CCI_PORT_CTRL);
>>> + while (readl_relaxed(cci_ctrl_base + CCI_CTRL_STATUS) & 0x1)
>>> + ;
>> cpu_relax()?
> In some cases there is no more cache coherence when this is called and
> the hardware might not be in a good state to cope with whatever action
> people might be tempted to insert into cpu_relax(). After the CCI is
> disabled it is important to keep a low profile and not touch anything
> global. With some early hardware revision, even a DMB here was harmful.
Fair enough. Perhaps the code could use a comment to that effect.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
Hi Olav, On Tue, Apr 16, 2013 at 07:18:42PM +0100, Olav Haugan wrote: > On 4/15/2013 6:13 AM, Will Deacon wrote: > > If so, doesn't that strongly tie your video driver to the SMMU? > > Isn't this more or less what you are doing in DT where you associate > specific devices with an IOMMU (mmu-masters)? No. The device-tree describes the *hardware*, as per usual. The StreamIDs are fixed properties of the SoC and we can't change them from Linux, so we describe all of the StreamIDs upstream of each SMMU so that we can program the thing. There's no way to generic way to discover them. > > This seems to be where we differ. My anticipated use-case is that a domain > > is allocated, which defines an empty address space. Masters are then > > attached to the domain by passing their struct device, so this may > > correspond to a DMA controller or a video core, in your case. The context > > bank is allocated dynamically when the first device is added to the > > domain, and then it is subsequently shared between all the masters in that > > domain. > > I feel that there are some limitation with this. Maybe you can address > the following: > > 1) What if you want two context banks in one domain (shared page table)? Why would a page table shared between devices require multiple context banks? Multiple SMRs and S2CRs, sure, but they would ultimately point at the same context bank (and hence same address space). > 2) What if a master (device) needs to use 2 or more context banks? If a master needs to be in two address spaces at once, then it will need to attach it's StreamIDs to different domains. You can't place a single StreamID in two address spaces (this is an architectural constraint). > > Perhaps, but I don't think it's worth complicating the binding based on a > > potential nice-to-have fault message. > > > > However, global register space (including Stream Match Registers [SMR]) > needs to be programmed by the secure environment for security or by > hyper-visor if you are in such an environment. Of course, but that's not Linux (and KVM would likely have some additional code if it wanted to do device passthrough, for example). Will ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 2/2] gpio: samsung: Remove OF support for Exynos4/5
On 04/17/2013 06:35 PM, Linus Walleij wrote: On Wed, Apr 17, 2013 at 1:06 PM, Sylwester Nawrocki wrote: -#endif +* All Samsung platforms that support device tree will use the pinctrl +* driver, hence we skip initialization of this driver if the OF tree +* is available. +*/ + if (of_have_populated_dt()) + return -ENODEV; samsung_gpiolib_set_cfg(samsung_gpio_cfgs, ARRAY_SIZE(samsung_gpio_cfgs)); Oh is that how you do it? It looks fragile. Can't you check if you have the pinctrl node atleast? But this driver won't help if there is no pinctrl node found anyway, since any OF support is removed from it. This way there is no need for any additional DT parsing, just to skip probing of this legacy GPIO driver. There might be something that could have gone wrong and I am missing though. Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: omap4-panda: Add USB Host support
* Roger Quadros [130415 01:53]:
> Provide the RESET and Power regulators for the USB PHY,
> the USB Host port mode and the PHY device.
>
> The USB PHY needs AUXCLK3 to operate. Provide this information
> as well.
>
> Also provide pin multiplexer information for the USB host
> pins.
>
> This patch depends on OMAP clock binding introduced in
> https://lkml.org/lkml/2013/4/12/407
Cool looks like EHCI works with this on my panda with linux
next booting with DT. One comment below.
Regards,
Tony
> CC: Benoît Cousson
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap4-panda-common.dtsi | 58
> +
> arch/arm/boot/dts/omap4.dtsi |5 ++
> 2 files changed, 63 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 03bd60d..628f744 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -54,6 +54,38 @@
> "AFML", "Line In",
> "AFMR", "Line In";
> };
> +
> + /* HS USB Port 1 RESET */
> + hsusb1_reset: hsusb1_reset_reg {
> + compatible = "regulator-fixed";
> + regulator-name = "hsusb1_reset";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpio2 30 0>; /* gpio_62 */
> + startup-delay-us = <7>;
> + enable-active-high;
> + };
> +
> + /* HS USB Port 1 Power */
> + hsusb1_power: hsusb1_power_reg {
> + compatible = "regulator-fixed";
> + regulator-name = "hsusb1_vbus";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpio1 1 0>;/* gpio_1 */
> + startup-delay-us = <7>;
> + enable-active-high;
> + };
> +
> + /* HS USB Host PHY on PORT 1 */
> + hsusb1_phy: hsusb1_phy {
> + compatible = "usb-nop-xceiv";
> + reset-supply = <&hsusb1_reset>;
> + vcc-supply = <&hsusb1_power>;
> + clocks = <&auxclk3>;
> + clock-names = "main_clk";
> + clock-frequency = <1920>;
> + };
> };
>
> &omap4_pmx_core {
> @@ -64,6 +96,7 @@
> &mcbsp1_pins
> &dss_hdmi_pins
> &tpd12s015_pins
> + &hsusbb1_pins
> >;
>
> twl6040_pins: pinmux_twl6040_pins {
> @@ -108,6 +141,23 @@
> >;
> };
>
> + hsusbb1_pins: pinmux_hsusbb1_pins {
> + pinctrl-single,pins = <
> + 0x82 0x10C /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
> + 0x84 0x4/*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
> + 0x86 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
> + 0x88 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
> + 0x8a 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
> + 0x8c 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
> + 0x8e 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
> + 0x90 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
> + 0x92 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
> + 0x94 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
> + 0x96 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
> + 0x98 0x104 /*
> USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
> + >;
> + };
> +
> i2c1_pins: pinmux_i2c1_pins {
> pinctrl-single,pins = <
> 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
> MODE0 */
Looks like your comments are wrong above, it's not PULLDOWN? Also
the naming should be mode0name.modename to be consistent. Here's
what I dumped out, please check and replace spaces with tabs:
0x82 0x10c /* usbb1_ulpitll_clk.usbb1_ulpiphy_clk
gpio84 INPUT_PULLDOWN | MODE4 */
0x84 0x4/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp
gpio85 OUTPUT | MODE4 */
0x86 0x104 /* usbb1_ulpitll_dir.usbb1_ulpiphy_dir
gpio86 INPUT | MODE4 */
0x88 0x104 /* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt
gpio87 INPUT | MODE4 */
0x8a 0x104 /*
usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 gpio88 INPUT | MODE4 */
0x8c
Re: [PATCH 1/2] mfd: wm8994: Add device ID data to WM8994 OF device IDs
Hi Mark, On Thu, Apr 11, 2013 at 06:11:50PM +0100, Mark Brown wrote: > We can actually read this back from the device but we use this when > registered using standard I2C board data registration so make sure > it's there for OF too. > > Signed-off-by: Mark Brown > Tested-by: Sylwester Nawrocki > --- > drivers/mfd/wm8994-core.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Both patches applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 02/10] utilfdt_read: pass back up the length of data read
On Mon, Apr 15, 2013 at 10:13:09PM -0400, Mike Frysinger wrote: > For a follow up commit, we want to be able to scan the buffer that was > returned to us. In order to do that safely, we need to know how big > the buffer actually is, so create a new set of funcs to pass that back. > > Signed-off-by: Mike Frysinger Acked-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/10] util_version: new helper for displaying version info
On Mon, Apr 15, 2013 at 10:13:11PM -0400, Mike Frysinger wrote: > This is so all utilities can have this flag and not just dtc. > > Acked-by: David Gibson > Signed-off-by: Mike Frysinger Jon, Please apply these first 4 patches, regardless of the rest of the series. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] fdtput: expand fdt if value does not fit.
On Mon, Apr 15, 2013 at 07:36:50AM +0100, Srinivas KANDAGATLA wrote: > From: Srinivas Kandagatla > > If you try to insert a new node or extend a property with large value, > using fdtput you will notice that it always fails. > > example: > fdtput -v -p -ts ./tst.dtb "/node-1" "property-1" "value-1 > Error at 'node-1': FDT_ERR_NOSPACE > > or > > fdtput -v -c ./tst.dtb "/node-1" > Error at 'node-1': FDT_ERR_NOSPACE > > or > > fdtput -v -ts ./tst.dtb "/node" "property" "very big value" > Decoding value: > string: 'very big value' > Value size 15 > Error at 'property': FDT_ERR_NOSPACE > > All these error are returned from libfdt, as the size of the fdt passed > has no space to accomdate these new properties. > > This patch adds realloc functions in fdtput to allocate new space in fdt > when it detects a shortage in space for new value or node. With this > patch, fdtput can insert a new node or property or extend a property > with new value greater than original size. > > Without this patch fdtput tool complains with FDT_ERR_NOSPACE when we > try to add a node/property or extend the value of a property. > > Signed-off-by: Srinivas Kandagatla Your realloc functions could overestimate the required size in some cases, so you should put an fdt_pack() before you write the final blob out to clean up any extra padding. Other than that, looks good. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next] mmc: dw_mmc: fix error return code in dw_mci_probe()
From: Wei Yongjun
Fix to return -ENOMEM in alloc workqueue error case instead
of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/mmc/host/dw_mmc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index bc3a1bc..0652690 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2321,8 +2321,10 @@ int dw_mci_probe(struct dw_mci *host)
tasklet_init(&host->tasklet, dw_mci_tasklet_func, (unsigned long)host);
host->card_workqueue = alloc_workqueue("dw-mci-card",
WQ_MEM_RECLAIM | WQ_NON_REENTRANT, 1);
- if (!host->card_workqueue)
+ if (!host->card_workqueue) {
+ ret = -ENOMEM;
goto err_dmaunmap;
+ }
INIT_WORK(&host->card_work, dw_mci_work_routine_card);
ret = devm_request_irq(host->dev, host->irq, dw_mci_interrupt,
host->irq_flags, "dw-mci", host);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next] mmc: mxs-mmc: fix error return code in mxs_mmc_probe()
From: Wei Yongjun
Fix to return -ENODEV in the request dma error case instead
of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/mmc/host/mxs-mmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 4278a17..a09ba6e 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -639,6 +639,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
if (!ssp->dmach) {
dev_err(mmc_dev(host->mmc),
"%s: failed to request dma\n", __func__);
+ ret = -ENODEV;
goto out_clk_put;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
On Fri, Apr 19, 2013 at 12:28:21AM +0200, Arnaud Ebalard wrote:
>
> Signed-off-by: Arnaud Ebalard
> Tested-by: Arnaud Ebalard
> ---
> drivers/hwmon/Kconfig | 10 +
> drivers/hwmon/Makefile |1 +
> drivers/hwmon/g762.c | 1159
>
> 3 files changed, 1170 insertions(+)
> create mode 100644 drivers/hwmon/g762.c
>
checkpatch says:
total: 1 errors, 15 warnings, 0 checks, 1182 lines checked
Please fix those. Also, please make sure there are spaces around operators.
Additional comments inline. This is not a complete review; I gave up after
a while. Please fix the problems and resubmit.
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..0c6ddee 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -423,6 +423,16 @@ config SENSORS_G760A
> This driver can also be built as a module. If so, the module
> will be called g760a.
>
> +config SENSORS_G762
> + tristate "GMT G762"
> + depends on I2C
> + help
> + If you say yes here you get support for Global Mixed-mode
> + Technology Inc G762 fan speed PWM controller chips.
> +
> + This driver can also be built as a module. If so, the module
> + will be called g762a.
> +
> config SENSORS_GL518SM
> tristate "Genesys Logic GL518SM"
> depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8d6d97e..4b49504 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S) += f75375s.o
> obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
> obj-$(CONFIG_SENSORS_FSCHMD) += fschmd.o
> obj-$(CONFIG_SENSORS_G760A) += g760a.o
> +obj-$(CONFIG_SENSORS_G762) += g762.o
> obj-$(CONFIG_SENSORS_GL518SM)+= gl518sm.o
> obj-$(CONFIG_SENSORS_GL520SM)+= gl520sm.o
> obj-$(CONFIG_SENSORS_GPIO_FAN) += gpio-fan.o
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 000..8c4cb39
> --- /dev/null
> +++ b/drivers/hwmon/g762.c
> @@ -0,0 +1,1159 @@
> +/*
> + * g762 - Driver for the Global Mixed-mode Technology Inc. fan speed PWM
> + *controller chips from G762 family, i.e. G762 and G763
> + *
> + * Copyright (C) 2013, Arnaud EBALARD
> + *
> + * This work is based on a basic version for 2.6.31 kernel developed
> + * by Olivier Mouchet for LaCie NAS. Updates have been performed to run
> + * on recent kernels. Supported has been completed and additional
> + * features added: ability to configure various characteristics from
> + * .dts file, better initialization, alarms and error reporting support,
> + * gear mode, polarity, fan pulse per revolution, fan startup voltage
> + * control. The following detailed datasheet has been used as a basis
> + * for this work:
> + *
> + * http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf
> + *
> + * Headers from previous developments have been kept below:
> + *
> + * Copyright (c) 2009 LaCie
> + *
> + * Author: Olivier Mouchet
> + *
> + * based on g760a code written by Herbert Valerio Riedel
> + * Copyright (C) 2007 Herbert Valerio Riedel
> + *
> + * g762: minimal datasheet available at:
> + * http://www.gmt.com.tw/product/datasheet/EDS-762_3.pdf
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRVNAME "g762"
> +
> +static const struct i2c_device_id g762_id[] = {
> + { DRVNAME, 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, g762_id);
> +
> +enum g762_regs {
> + G762_REG_SET_CNT = 0x00,
> + G762_REG_ACT_CNT = 0x01,
> + G762_REG_FAN_STA = 0x02,
> + G762_REG_SET_OUT = 0x03,
> + G762_REG_FAN_CMD1 = 0x04,
> + G762_REG_FAN_CMD2 = 0x05,
> +};
> +
> +/* Config register bits */
> +#define G762_REG_FAN_CMD1_DET_FAN_FAIL 0x80 /* enable fan_fail signal
> */
> +#define G762_REG_FAN_CMD1_DET_FAN_OOC0x40 /* enable
> fan_out_of_control */
> +#define G762_REG_FAN_CMD1_OUT_MODE 0x20 /* out mode, pwm or dac */
> +#define G762_REG_FAN_CMD1_FAN_MODE 0x10 /* fan mode: close or open loop */
Re: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
Hi Arnaud > +static DEVICE_ATTR(pwm1, S_IWUSR | S_IRUGO, get_pwm, set_pwm); > +static DEVICE_ATTR(pwm1_polarity, S_IWUSR | S_IRUGO, > +get_pwm_polarity, set_pwm_polarity); > +static DEVICE_ATTR(pwm1_mode, S_IWUSR | S_IRUGO, > +get_pwm_mode, set_pwm_mode); > +static DEVICE_ATTR(pwm1_enable, S_IWUSR | S_IRUGO, > +get_speed_control_mode, set_speed_control_mode); > +static DEVICE_ATTR(pwm1_freq, S_IWUSR | S_IRUGO, > +get_pwm_freq, set_pwm_freq); > + > +static DEVICE_ATTR(fan1_input, S_IRUGO, get_fan_rpm, NULL); > +static DEVICE_ATTR(fan1_alarm, S_IRUGO, get_fan_ooc, NULL); > +static DEVICE_ATTR(fan1_alarm_detection, S_IWUSR | S_IRUGO, > +get_fan_ooc_detection, set_fan_ooc_detection); > +static DEVICE_ATTR(fan1_fault, S_IRUGO, get_fan_failure, NULL); > +static DEVICE_ATTR(fan1_fault_detection, S_IWUSR | S_IRUGO, > +get_fan_failure_detection, set_fan_failure_detection); > +static DEVICE_ATTR(fan1_target, S_IWUSR | S_IRUGO, > +get_fan_target, set_fan_target); > +static DEVICE_ATTR(fan1_pulses, S_IWUSR | S_IRUGO, > +get_fan_pulses, set_fan_pulses); > +static DEVICE_ATTR(fan1_div, S_IWUSR | S_IRUGO, > +get_fan_clk_div, set_fan_clk_div); > +static DEVICE_ATTR(fan1_gear_mode, S_IWUSR | S_IRUGO, > +get_fan_gear_mode, set_fan_gear_mode); > +static DEVICE_ATTR(fan1_startup_voltage, S_IWUSR | S_IRUGO, > +get_fan_startup_voltage, set_fan_startup_voltage); It is normal to use SENSOR_ATTR, not DEVICE_ATTR. Take a look at the existing fan drivers. I also think a lot of these are not needed. They are fixed properties of the board and cannot change dynamically. They are set once using DT and user space does not need to care. Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Regarding dtc+cpp support
On Thu, Apr 18, 2013 at 10:27 PM, Jon Hunter wrote: > > On 04/18/2013 11:21 AM, Padma Venkat wrote: >> Hi, >> >> On Thu, Apr 18, 2013 at 8:19 PM, Jon Hunter wrote: >>> >>> On 04/18/2013 04:12 AM, Padma Venkat wrote: Hi Stephen, I am trying to add a header file for samsung audio subsystem clk definitions, which can be used in kernel and dt files. I applied following patches posted by you in my working tree. [1/7] kbuild: create an "include chroot" for DT bindings [2/7] kbuild: fixdep: support concatenated dep files [3/7] kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc [4/7] kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp [5/7] ARM: dt: add header to define GPIO flags [6/7] ARM: dt: add header to define IRQ flags [7/7] ARM: dt: create a DT header for the GIC I created a header file in arch/arm/boot/dts/include/clk/samsung-audss-clk.h and I included this header in driver and dtsi files Please see the code snippet in dtsi below. #include /include/ "skeleton.dtsi" /include/ "exynos5250-pinctrl.dtsi >>> >>> Try making all of the above "#include" ... >> >> I haven't changed all dts files but I tried below with no success. > > I should mentioned that you should also make any /include/ in the *.dtsi > above #include too. It is working after all dtsi files modified. Thanks Padma > > Cheers > Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] Add support for GMT G72/G763 PWM fan controller
Hi Arnaud,
Just a few things I noticed...
Typo in subject line: G762, not G72.
On Fri, 19 Apr 2013 00:28:21 +0200, Arnaud Ebalard wrote:
>
> Signed-off-by: Arnaud Ebalard
> Tested-by: Arnaud Ebalard
> ---
> drivers/hwmon/Kconfig | 10 +
> drivers/hwmon/Makefile |1 +
> drivers/hwmon/g762.c | 1159
>
> 3 files changed, 1170 insertions(+)
> create mode 100644 drivers/hwmon/g762.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 89ac1cb..0c6ddee 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -423,6 +423,16 @@ config SENSORS_G760A
> This driver can also be built as a module. If so, the module
> will be called g760a.
>
> +config SENSORS_G762
> + tristate "GMT G762"
> + depends on I2C
> + help
> + If you say yes here you get support for Global Mixed-mode
> + Technology Inc G762 fan speed PWM controller chips.
If your driver also supports the G763 it should be mentioned here.
> +
> + This driver can also be built as a module. If so, the module
> + will be called g762a.
This is not how your driver is actually named.
> +
> config SENSORS_GL518SM
> tristate "Genesys Logic GL518SM"
> depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8d6d97e..4b49504 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_F75375S) += f75375s.o
> obj-$(CONFIG_SENSORS_FAM15H_POWER) += fam15h_power.o
> obj-$(CONFIG_SENSORS_FSCHMD) += fschmd.o
> obj-$(CONFIG_SENSORS_G760A) += g760a.o
> +obj-$(CONFIG_SENSORS_G762) += g762.o
> obj-$(CONFIG_SENSORS_GL518SM)+= gl518sm.o
> obj-$(CONFIG_SENSORS_GL520SM)+= gl520sm.o
> obj-$(CONFIG_SENSORS_GPIO_FAN) += gpio-fan.o
> diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
> new file mode 100644
> index 000..8c4cb39
> --- /dev/null
> +++ b/drivers/hwmon/g762.c
> (...)
> +#define DRVNAME "g762"
> +
> +static const struct i2c_device_id g762_id[] = {
> + { DRVNAME, 0 },
No, this is a list of device names, nor driver names, so the use of
DRVNAME is inappropriate. Also, again, if your driver supports the g763
it should be listed here too.
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, g762_id);
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
