* [PATCH 3/9] ARM: DTS: omap4: Set all audio related IP's status to disabled as default
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Board dts files will need to enable the IP nodes which they are using and
does not have to care about the not used ones (to disable them).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e05853afcd..78c19e30eca0 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -426,6 +426,7 @@
dmas = <&sdma 65>,
<&sdma 66>;
dma-names = "up_link", "dn_link";
+ status = "disabled";
};
dmic: dmic at 4012e000 {
@@ -437,6 +438,7 @@
ti,hwmods = "dmic";
dmas = <&sdma 67>;
dma-names = "up_link";
+ status = "disabled";
};
mcbsp1: mcbsp at 40122000 {
@@ -451,6 +453,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 40124000 {
@@ -465,6 +468,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 40126000 {
@@ -479,6 +483,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp4: mcbsp at 48096000 {
@@ -492,6 +497,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
keypad: keypad at 4a31c000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 2/9] ARM: DTS: omap4-sdp: Move audio related pinmux to respective nodes
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Attach the pinctrl nodes to their respective device node:
mcbsp1, mcbsp2, dmic, mcpdm and twl6040.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 33 ++++++++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index dbc81fb6ef03..513b01774966 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,11 +158,6 @@
&omap4_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <
- &twl6040_pins
- &mcpdm_pins
- &dmic_pins
- &mcbsp1_pins
- &mcbsp2_pins
&dss_hdmi_pins
&tpd12s015_pins
>;
@@ -326,6 +321,10 @@
twl6040: twl at 4b {
compatible = "ti,twl6040";
reg = <0x4b>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&twl6040_pins>;
+
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_2N cascaded to gic */
interrupt-parent = <&gic>;
@@ -537,10 +536,34 @@
pinctrl-0 = <&uart4_pins>;
};
+&mcbsp1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp1_pins>;
+ status = "okay";
+};
+
+&mcbsp2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp2_pins>;
+ status = "okay";
+};
+
&mcbsp3 {
status = "disabled";
};
+&dmic {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dmic_pins>;
+ status = "okay";
+};
+
+&mcpdm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcpdm_pins>;
+ status = "okay";
+};
+
&twl_usb_comparator {
usb-supply = <&vusb>;
};
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/9] ARM: DTS: omap4-panda-common: Move audio related pinmux to respective nodes
From: Peter Ujfalusi @ 2014-01-24 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Attach the pinctrl nodes to their respective device node:
mcbsp1, mcpdm and twl6040.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05cab41..9067d4c0148d 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -109,9 +109,6 @@
&omap4_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <
- &twl6040_pins
- &mcpdm_pins
- &mcbsp1_pins
&dss_dpi_pins
&tfp410_pins
&dss_hdmi_pins
@@ -300,6 +297,10 @@
twl6040: twl@4b {
compatible = "ti,twl6040";
reg = <0x4b>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&twl6040_pins>;
+
/* IRQ# = 119 */
interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_2N cascaded to gic */
interrupt-parent = <&gic>;
@@ -380,6 +381,12 @@
device-handle = <&elpida_ECB240ABACN>;
};
+&mcbsp1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp1_pins>;
+ status = "okay";
+};
+
&mcbsp2 {
status = "disabled";
};
@@ -392,6 +399,12 @@
status = "disabled";
};
+&mcpdm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcpdm_pins>;
+ status = "okay";
+};
+
&twl_usb_comparator {
usb-supply = <&vusb>;
};
--
1.8.5.3
^ permalink raw reply related
* [PATCH 0/9] ARM: DTS: OMAP: Audio related cleanups for dtsi and dts files
From: Peter Ujfalusi @ 2014-01-24 8:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Benoit,
OMAP: Put the audio nodes to disabled styate by default and board dts files should
enable the nodes which is used on the board.
am335x: correct the audio mclk clock. This patch has been marked to go to 3.13
stable as well.
Regards,
Peter
---
Peter Ujfalusi (9):
ARM: DTS: omap4-panda-common: Move audio related pinmux to respective
nodes
ARM: DTS: omap4-sdp: Move audio related pinmux to respective nodes
ARM: DTS: omap4: Set all audio related IP's status to disabled as
default
ARM: DTS: omap4-panda-common: No need to disable the unused audio
nodes
ARM: DTS: omap4-sdp: No need to disable mcbsp3 node
ARM: DTS: omap5: Set all audio related IP's status to disabled as
default
ARM: DTS: omap3: Set disabled status for McBSP instances as default
state
ARM: DTS: omap2: Set disabled status for McBSP instances as default
state
ARM: DTS: am335x-evmsk: Correct audio clock frequency
arch/arm/boot/dts/am335x-evmsk.dts | 2 +-
arch/arm/boot/dts/omap2420.dtsi | 2 ++
arch/arm/boot/dts/omap2430.dtsi | 5 +++++
arch/arm/boot/dts/omap3-beagle-xm.dts | 4 ++++
arch/arm/boot/dts/omap3-beagle.dts | 4 ++++
arch/arm/boot/dts/omap3-devkit8000.dts | 16 ++-------------
arch/arm/boot/dts/omap3-igep.dtsi | 1 +
arch/arm/boot/dts/omap3-overo.dtsi | 4 ++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
arch/arm/boot/dts/omap4-panda-common.dtsi | 23 ++++++++++-----------
arch/arm/boot/dts/omap4-sdp.dts | 33 ++++++++++++++++++++++++-------
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
arch/arm/boot/dts/omap5.dtsi | 5 +++++
13 files changed, 77 insertions(+), 33 deletions(-)
--
1.8.5.3
^ permalink raw reply
* [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
From: Heiko Stübner @ 2014-01-24 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E19931.80803@gmail.com>
On Thursday 23 January 2014 23:35:29 Tomasz Figa wrote:
> On 23.01.2014 20:02, Heiko St?bner wrote:
> > Am Donnerstag, 23. Januar 2014, 19:51:34 schrieb Tomasz Figa:
> >> On 23.01.2014 19:36, Heiko St?bner wrote:
> > In general, I want to try establishing some sort of general restart way,
> > as in the future one dt-board should hopefully be enough to cover all
> > s3c24xx soc variants.
>
> If you make SAMSUNG_WDT_RESET always selected on S3C24XX then I guess
> it's fine.
>
> >> Note that you can make the restart field NULL in mach_desc in board
> >> files.
> >
> > As I said above, this is mainly meant for the dt-case. The legacy-board
> > files are more or less only secondary, and the affected boards can of
> > course then have a NULL restart handle :-) .
> >
> > So for this the dt-board could simply use the wdt-reset, which then gets
> > replaced by the ccf-based reset if appropriate.
>
> OK. By the way, are there any benefits of using this software reset over
> watchdog reset? Maybe all S3C24xx could simply use watchdog reset and no
> special handling of those with swrst would be needed.
According to the manuals I looked at, all S3C24XX SoCs seem to support the
watchdog reset - I'm not sure why the swrst variant was choosen for the newer
ones when they were added initially. So yes in theory all of them seem to be
able to use the watchdog reset.
But in any case the s3c2412 will need its own handling, due to the apparent
clock problem during resets (mentioned in the code and the manuals of
s3c2412/s3c2413).
Heiko
^ permalink raw reply
* DT include files
From: Heiko Stübner @ 2014-01-24 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140113021912.GB23525@S2101-09.ap.freescale.net>
Hi Shawn,
did this topic get any final resolution - especially in terms of the pingrp.h
header?
As I'm currently preparing two board files (imx50 and imx6sl) this discussion
made me unsure if using the pin-group definitions is still the preferred style.
Thanks
Heiko
On Monday 13 January 2014 10:19:14 Shawn Guo wrote:
> On Sun, Jan 12, 2014 at 09:21:19PM +0100, Arnd Bergmann wrote:
> > I was under the impression that the generic pinctrl binding was designed
> > in a way to let you assign labels to each possible (reasonable)
> > configuration so you didn't have get to this level of detail at the
> > driver.
>
> The generic part of pinctrl binding only covers the procedure how a
> client device get its pinctrl state configuration from a pin controller
> node. That's what we defined in bindings/pinctrl/pinctrl-bindings.txt
> and implemented in pinctrl core. But the details of how a pinctrl state
> configuration should be interpreted for a particular pin controller is
> defined by individual pin controller binding like fsl,imx-pinctrl.txt,
> and implemented in the pin controller driver like
> drivers/pinctrl/pinctrl-imx.c.
>
> > I'm also surprised that you have to know multiple constants
> > (mux register, input register, config register offsets) to select a
> > particular pin. I would have expected that you could have one constant
> > from which the driver is able to compute the other ones.
>
> That's what we do before. We define a constant in the binding and have
> the driver to maintain these data and look up the data using the
> constant. See commit below for imx6q example.
>
> d8fe357 pinctrl: pinctrl-imx: add imx6q pinctrl driver
>
> The biggest problem with that approach is we have huge data to maintain
> in the driver because of the complexity and flexibility of IMX pin
> controller design. And these data can not be init data. Check that big
> array of struct imx_pin_reg in commit above for what I'm talking about.
> So when we build a v7 kernel image for IMX, we will have such big array
> for each of these SoCs, imx50, imx51, imx53, imx6sl, imx6dl, imx6q, and
> more to come.
>
> That's why we went through the pain of breaking DT compatibility to move
> all these data into device tree one year ago with the commit below.
>
> e164153 pinctrl: imx: move hard-coding data into device tree
>
> Now kernel gets released from the floating and we do not even need to
> touch kernel to add these data when new SoC support is added.
>
> Shawn
^ permalink raw reply
* [PATCH resend] pwm: Remove obsolete HAVE_PWM Kconfig symbol
From: Sascha Hauer @ 2014-01-24 7:54 UTC (permalink / raw)
To: linux-arm-kernel
Before we had the PWM framework we used to have a barebone PWM api. The
HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify
the PWM API is present in the kernel. Since the last legacy driver is gone
the HAVE_PWM symbol can go aswell.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm at vger.kernel.orig
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
---
Thierry as PWM maintainer has agreed to take this patch. Would be nice
to get some Acks from affected architectures. Russell, Ralf?
arch/arm/Kconfig | 4 ----
arch/arm/mach-pxa/Kconfig | 15 ---------------
arch/mips/Kconfig | 1 -
drivers/input/misc/Kconfig | 4 ++--
include/linux/pwm.h | 2 +-
5 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7e..1b6f499 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -109,9 +109,6 @@ config ARM_DMA_IOMMU_ALIGNMENT
endif
-config HAVE_PWM
- bool
-
config MIGHT_HAVE_PCI
bool
@@ -606,7 +603,6 @@ config ARCH_LPC32XX
select CPU_ARM926T
select GENERIC_CLOCKEVENTS
select HAVE_IDE
- select HAVE_PWM
select USB_ARCH_HAS_OHCI
select USE_OF
help
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 96100db..b96244c 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -7,7 +7,6 @@ comment "Intel/Marvell Dev Platforms (sorted by hardware release time)"
config MACH_PXA3XX_DT
bool "Support PXA3xx platforms from device tree"
select CPU_PXA300
- select HAVE_PWM
select POWER_SUPPLY
select PXA3xx
select USE_OF
@@ -23,12 +22,10 @@ config ARCH_LUBBOCK
config MACH_MAINSTONE
bool "Intel HCDDBBVA0 Development Platform (aka Mainstone)"
- select HAVE_PWM
select PXA27x
config MACH_ZYLONITE
bool
- select HAVE_PWM
select PXA3xx
config MACH_ZYLONITE300
@@ -69,7 +66,6 @@ config ARCH_PXA_IDP
config ARCH_VIPER
bool "Arcom/Eurotech VIPER SBC"
select ARCOM_PCMCIA
- select HAVE_PWM
select I2C_GPIO
select ISA
select PXA25x
@@ -120,7 +116,6 @@ config MACH_CM_X300
bool "CompuLab CM-X300 modules"
select CPU_PXA300
select CPU_PXA310
- select HAVE_PWM
select PXA3xx
config MACH_CAPC7117
@@ -211,7 +206,6 @@ config TRIZEPS_PCMCIA
config MACH_LOGICPD_PXA270
bool "LogicPD PXA270 Card Engine Development Platform"
- select HAVE_PWM
select PXA27x
config MACH_PCM027
@@ -222,7 +216,6 @@ config MACH_PCM027
config MACH_PCM990_BASEBOARD
bool "PHYTEC PCM-990 development board"
depends on MACH_PCM027
- select HAVE_PWM
choice
prompt "display on pcm990"
@@ -246,7 +239,6 @@ config MACH_COLIBRI
config MACH_COLIBRI_PXA270_INCOME
bool "Income s.r.o. PXA270 SBC"
depends on MACH_COLIBRI
- select HAVE_PWM
select PXA27x
config MACH_COLIBRI300
@@ -275,7 +267,6 @@ comment "End-user Products (sorted by vendor name)"
config MACH_H4700
bool "HP iPAQ hx4700"
- select HAVE_PWM
select IWMMXT
select PXA27x
@@ -289,14 +280,12 @@ config MACH_HIMALAYA
config MACH_MAGICIAN
bool "Enable HTC Magician Support"
- select HAVE_PWM
select IWMMXT
select PXA27x
config MACH_MIOA701
bool "Mitac Mio A701 Support"
select GPIO_SYSFS
- select HAVE_PWM
select IWMMXT
select PXA27x
help
@@ -306,7 +295,6 @@ config MACH_MIOA701
config PXA_EZX
bool "Motorola EZX Platform"
- select HAVE_PWM
select IWMMXT
select PXA27x
@@ -346,7 +334,6 @@ config MACH_MP900C
config ARCH_PXA_PALM
bool "PXA based Palm PDAs"
- select HAVE_PWM
config MACH_PALM27X
bool
@@ -444,7 +431,6 @@ config MACH_TREO680
config MACH_RAUMFELD_RC
bool "Raumfeld Controller"
select CPU_PXA300
- select HAVE_PWM
select POWER_SUPPLY
select PXA3xx
@@ -608,7 +594,6 @@ config MACH_E800
config MACH_ZIPIT2
bool "Zipit Z2 Handheld"
- select HAVE_PWM
select PXA27x
endmenu
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 650de39..ce62af8 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -233,7 +233,6 @@ config MACH_JZ4740
select IRQ_CPU
select ARCH_REQUIRE_GPIOLIB
select SYS_HAS_EARLY_PRINTK
- select HAVE_PWM
select HAVE_CLK
select GENERIC_IRQ_CHIP
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5f4967d..bc6ec8e 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -156,7 +156,7 @@ config INPUT_MAX8925_ONKEY
config INPUT_MAX8997_HAPTIC
tristate "MAXIM MAX8997 haptic controller support"
- depends on PWM && HAVE_PWM && MFD_MAX8997
+ depends on PWM && MFD_MAX8997
select INPUT_FF_MEMLESS
help
This option enables device driver support for the haptic controller
@@ -461,7 +461,7 @@ config INPUT_PCF8574
config INPUT_PWM_BEEPER
tristate "PWM beeper support"
- depends on PWM && HAVE_PWM
+ depends on PWM
help
Say Y here to get support for PWM based beeper devices.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f0feafd..4717f54 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -7,7 +7,7 @@
struct pwm_device;
struct seq_file;
-#if IS_ENABLED(CONFIG_PWM) || IS_ENABLED(CONFIG_HAVE_PWM)
+#if IS_ENABLED(CONFIG_PWM)
/*
* pwm_request - request a PWM device
*/
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/2] PWM: let of_xlate handlers check args count
From: Sascha Hauer @ 2014-01-24 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124064254.0369084d@ipc1.ka-ro>
On Fri, Jan 24, 2014 at 06:42:54AM +0100, Lothar Wa?mann wrote:
> Hi,
>
> > Okay, this works, but there's a problem with pwm-leds.
> >
> > When the duty cycle is set to zero (when you set the brightness to zero)
> > pwm-leds decides to disable the PWM after configuring it. This causes
> > the PWM output to be driven low, causing the LED to go to maximum
> > brightness.
> >
> > So, using the inversion at PWM level doesn't work.
> >
> The problem is that the driver calls pwm_disable() when the duty cycle is 0.
> This sets the PWM output low independent from the output polarity setting.
>
> > To make this work correctly, we really need pwm-leds to do the inversion
> > rather than setting the inversion bit in hardware.
> >
> The same holds for the pwm-backlight driver.
>
> The easiest fix would be not to call pwm_disable() even for a zero duty
> cycle.
IMO that's the right thing to do anyway due to the different PWM
hardware controllers we have. I'm thinking about the following patch
for some time.
Sascha
--------------------8<--------------------------
>From 9ebbc3d72c71bd97d7fc4458f60ae3ecd5876984 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Fri, 24 Jan 2014 08:34:16 +0100
Subject: [PATCH] PWM: Document disabled PWM output as undefined
When disabled PWM hardware reacts differently. Some controllers
just stop with their current value, others produce a constant high
or low output, sometimes depending on the output inversion bit. Update
the documentation to reflect that and request from the PWM consumer
drivers to set a constant high/low value with duty cycles of 0/100%
instead of disabling the PWM.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Documentation/pwm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 93cb979..b7e8a31 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -44,6 +44,8 @@ After being requested, a PWM has to be configured using:
int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
+The output of a disabled PWM is undefined. Set the duty cycle to 100%
+for a constant high output and to 0 for constant low output.
Using PWMs with the sysfs interface
-----------------------------------
--
1.8.5.2
--
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-5555 |
^ permalink raw reply related
* [PATCH v3 1/2] i2c: qup: Add device tree bindings information
From: Andy Gross @ 2014-01-24 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121024007.GE13785@codeaurora.org>
On Mon, Jan 20, 2014 at 06:40:07PM -0800, Stephen Boyd wrote:
> On 01/20, Rob Herring wrote:
> > On Fri, Jan 17, 2014 at 5:03 PM, Bjorn Andersson
> > <bjorn.andersson@sonymobile.com> wrote:
> >
> > > .../devicetree/bindings/i2c/qcom,i2c-qup.txt | 41 ++++++++++++++++++++++
> > > 1 file changed, 41 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> > > new file mode 100644
> > > index 0000000..a99711b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> > > @@ -0,0 +1,41 @@
> > > +Qualcomm Universal Peripheral (QUP) I2C controller
> > > +
> > > +Required properties:
> > > + - compatible: Should be "qcom,i2c-qup".
> >
> > Seems a bit generic. All versions of the IP are exactly the same?
> > "qcom,<chip>-i2c-qup" would be better.
> >
>
> There are different versions of the IP in different SoCs. The
> versions for platforms supported upstream are:
>
> 1.1.1 (MSM8660, MSM8960)
> 2.2.1 (MSM8974v2)
>
> so how about one of "qcom,i2c-qup-v1.1.1" or
> "qcom,i2c-qup-v2.2.1" should be specified as more specific
> compatible strings in addition to "qcom,i2c-qup"?
>
This definitely needs two compatible tags. The v1.1.1 supports the FIFO, block,
and data mover modes. The v2.2.1 supports FIFO, block, and BAM DMA.
The BAM patches are currently in review and ideally BAM support can be added to
the I2C. We'll need a way to differentiate so BAM can be used.
Otherwise, the register interfaces are interchangeable except for BAM specific
fields in the registers.
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
From: Mohit KUMAR DCG @ 2014-01-24 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64pSvoRBzrpzXT5yywqWSw8ryQiuVop2tMSRpU2=YMLiw@mail.gmail.com>
Hello Chen,
> -----Original Message-----
> From: wens213 at gmail.com [mailto:wens213 at gmail.com] On Behalf Of
> Chen-Yu Tsai
> Sent: Friday, January 24, 2014 11:33 AM
> To: Viresh Kumar
> Cc: Mohit KUMAR DCG; Pratyush ANAND; spear-devel; linux-arm-
> kernel at lists.infradead.org; devicetree
> Subject: Re: [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-
> addr> for phy probe
>
> Hi,
>
> On Fri, Jan 24, 2014 at 1:02 PM, Viresh Kumar <viresh.kumar@linaro.org>
> wrote:
> > On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com>
> wrote:
> >> DT field name for the phy address changed since kernel 3.10. Set the
> >> snps,phy-addr to 0xffffffff so that the driver probes for the phy.
>
> This will no longer be required. The default behavior for DT based setups has
> been changed to auto-detecting the phy.
>
> See http://patchwork.ozlabs.org/patch/312063/
>
- Thanks, we will test with your patch and remove this one from v3.
Regards
Mohit
>
> Cheers
> ChenYu
>
> >>
> >> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
> >> Cc: Pratyush Anand <pratyush.anand@st.com>
> >> Cc: Viresh Kumar <viresh.linux@gmail.com>
> >> Cc: spear-devel at list.st.com
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> Cc: devicetree at vger.kernel.org
> >> ---
> >> arch/arm/boot/dts/spear13xx.dtsi | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/spear13xx.dtsi
> >> b/arch/arm/boot/dts/spear13xx.dtsi
> >> index 4382547..3518803 100644
> >> --- a/arch/arm/boot/dts/spear13xx.dtsi
> >> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> >> @@ -155,6 +155,7 @@
> >>
> >> gmac0: eth at e2000000 {
> >> compatible = "st,spear600-gmac";
> >> + snps,phy-addr = <0xffffffff>;
> >> reg = <0xe2000000 0x8000>;
> >> interrupts = <0 33 0x4
> >> 0 34 0x4>;
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
From: Chen-Yu Tsai @ 2014-01-24 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=mQLyMV_0Swf3o2c9bW_DNCLT-fQFc3Qs6yt1+9prabmw@mail.gmail.com>
Hi,
On Fri, Jan 24, 2014 at 1:02 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
>> DT field name for the phy address changed since kernel 3.10. Set the
>> snps,phy-addr to 0xffffffff so that the driver probes for the phy.
This will no longer be required. The default behavior for
DT based setups has been changed to auto-detecting the phy.
See http://patchwork.ozlabs.org/patch/312063/
Cheers
ChenYu
>>
>> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
>> Cc: Pratyush Anand <pratyush.anand@st.com>
>> Cc: Viresh Kumar <viresh.linux@gmail.com>
>> Cc: spear-devel at list.st.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree at vger.kernel.org
>> ---
>> arch/arm/boot/dts/spear13xx.dtsi | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
>> index 4382547..3518803 100644
>> --- a/arch/arm/boot/dts/spear13xx.dtsi
>> +++ b/arch/arm/boot/dts/spear13xx.dtsi
>> @@ -155,6 +155,7 @@
>>
>> gmac0: eth at e2000000 {
>> compatible = "st,spear600-gmac";
>> + snps,phy-addr = <0xffffffff>;
>> reg = <0xe2000000 0x8000>;
>> interrupts = <0 33 0x4
>> 0 34 0x4>;
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] PWM: let of_xlate handlers check args count
From: Lothar Waßmann @ 2014-01-24 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123173642.GZ15937@n2100.arm.linux.org.uk>
Hi,
Russell King - ARM Linux wrote:
> On Thu, Jan 23, 2014 at 04:53:50PM +0000, Russell King - ARM Linux wrote:
> > On Thu, Jan 23, 2014 at 12:04:44PM +0100, Sascha Hauer wrote:
> > > On Thu, Jan 23, 2014 at 11:56:32AM +0100, Lothar Wa?mann wrote:
> > > > Hi,
> > > >
> > > > Sascha Hauer wrote:
> > > > > of_pwm_n_cells for the of_xlate handler is stored in struct pwm_chip,
> > > > > but it is only ever used by the of_xlate handler itsel. Remove
> > > > > of_pwm_n_cells from struct pwm_chip and let the handler do the argument
> > > > > count checking to simplify the code.
> > > > >
> > > > This still does not make the PWM_POLARITY flag in the pwms node
> > > > optional as was the goal because of_parse_phandle_with_args() requires
> > > > at least #pwm-cells arguments in the node.
> > > >
> > > > So, with a DT configuration like:
> > > > pwm0: pwm at 0 {
> > > > #pwm-cells = <3>;
> > > > };
> > > > backlight {
> > > > pwms = <&pwm0 0 100000>;
> > > > };
> > >
> > > We misunderstood each other. My goal was to allow the driver to also
> > > work with old devicetrees which specify #pwm-cells = <2>, not to allow
> > > inconsistent devicetrees like the snippet above.
> >
> > In which case, the patch I've posted seems to do that job too... I'm
> > just about to test out the three-cell version.
>
> Okay, this works, but there's a problem with pwm-leds.
>
> When the duty cycle is set to zero (when you set the brightness to zero)
> pwm-leds decides to disable the PWM after configuring it. This causes
> the PWM output to be driven low, causing the LED to go to maximum
> brightness.
>
> So, using the inversion at PWM level doesn't work.
>
The problem is that the driver calls pwm_disable() when the duty cycle is 0.
This sets the PWM output low independent from the output polarity setting.
> To make this work correctly, we really need pwm-leds to do the inversion
> rather than setting the inversion bit in hardware.
>
The same holds for the pwm-backlight driver.
The easiest fix would be not to call pwm_disable() even for a zero duty
cycle.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH V2 6/8] SPEAr13xx: Fix static mapping table
From: Pratyush Anand @ 2014-01-24 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=nAUxyx+5y4yA=NSEQPTAPLfdxaFjc=k8r1NyRUgZLu8A@mail.gmail.com>
On Fri, Jan 24, 2014 at 01:07:38PM +0800, Viresh Kumar wrote:
> On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> > From: Pratyush Anand <pratyush.anand@st.com>
> >
> > SPEAr13xx was using virtual address space 0xFE000000 to map physical address
> > space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
> > change 0xFE000000 to 0xF9000000.
> >
> > Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> > Tested-by: Mohit Kumar <mohit.kumar@st.com>
> > Cc: Viresh Kumar <viresh.linux@gmail.com>
> > Cc: spear-devel at list.st.com
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm/mach-spear/include/mach/spear.h | 4 ++--
> > arch/arm/mach-spear/spear13xx.c | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-spear/include/mach/spear.h b/arch/arm/mach-spear/include/mach/spear.h
> > index 5cdc53d..f2d6a01 100644
> > --- a/arch/arm/mach-spear/include/mach/spear.h
> > +++ b/arch/arm/mach-spear/include/mach/spear.h
> > @@ -52,10 +52,10 @@
> > #ifdef CONFIG_ARCH_SPEAR13XX
> >
> > #define PERIP_GRP2_BASE UL(0xB3000000)
> > -#define VA_PERIP_GRP2_BASE IOMEM(0xFE000000)
> > +#define VA_PERIP_GRP2_BASE IOMEM(0xF9000000)
> > #define MCIF_SDHCI_BASE UL(0xB3000000)
> > #define SYSRAM0_BASE UL(0xB3800000)
> > -#define VA_SYSRAM0_BASE IOMEM(0xFE800000)
> > +#define VA_SYSRAM0_BASE IOMEM(0xF9800000)
> > #define SYS_LOCATION (VA_SYSRAM0_BASE + 0x600)
> >
> > #define PERIP_GRP1_BASE UL(0xE0000000)
> > diff --git a/arch/arm/mach-spear/spear13xx.c b/arch/arm/mach-spear/spear13xx.c
> > index 7aa6e8c..20ce885 100644
> > --- a/arch/arm/mach-spear/spear13xx.c
> > +++ b/arch/arm/mach-spear/spear13xx.c
> > @@ -52,10 +52,10 @@ void __init spear13xx_l2x0_init(void)
> > /*
> > * Following will create 16MB static virtual/physical mappings
> > * PHYSICAL VIRTUAL
> > - * 0xB3000000 0xFE000000
> > * 0xE0000000 0xFD000000
> > * 0xEC000000 0xFC000000
> > * 0xED000000 0xFB000000
> > + * 0xB3000000 0xF9000000
>
>
> Why have you moved this to bottom of list? It was probably kept
> in increasing order and so please keep the same.
Oh,yes..ll be corrected in v3 of series.
>
> Other than that:
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Thanks.
Regards
Pratyush
^ permalink raw reply
* [PATCH V2 6/8] SPEAr13xx: Fix static mapping table
From: Viresh Kumar @ 2014-01-24 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22d2e7d6fbd5a291cdecf6a4d1e294d9c9ede617.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> From: Pratyush Anand <pratyush.anand@st.com>
>
> SPEAr13xx was using virtual address space 0xFE000000 to map physical address
> space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
> change 0xFE000000 to 0xF9000000.
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Tested-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-spear/include/mach/spear.h | 4 ++--
> arch/arm/mach-spear/spear13xx.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-spear/include/mach/spear.h b/arch/arm/mach-spear/include/mach/spear.h
> index 5cdc53d..f2d6a01 100644
> --- a/arch/arm/mach-spear/include/mach/spear.h
> +++ b/arch/arm/mach-spear/include/mach/spear.h
> @@ -52,10 +52,10 @@
> #ifdef CONFIG_ARCH_SPEAR13XX
>
> #define PERIP_GRP2_BASE UL(0xB3000000)
> -#define VA_PERIP_GRP2_BASE IOMEM(0xFE000000)
> +#define VA_PERIP_GRP2_BASE IOMEM(0xF9000000)
> #define MCIF_SDHCI_BASE UL(0xB3000000)
> #define SYSRAM0_BASE UL(0xB3800000)
> -#define VA_SYSRAM0_BASE IOMEM(0xFE800000)
> +#define VA_SYSRAM0_BASE IOMEM(0xF9800000)
> #define SYS_LOCATION (VA_SYSRAM0_BASE + 0x600)
>
> #define PERIP_GRP1_BASE UL(0xE0000000)
> diff --git a/arch/arm/mach-spear/spear13xx.c b/arch/arm/mach-spear/spear13xx.c
> index 7aa6e8c..20ce885 100644
> --- a/arch/arm/mach-spear/spear13xx.c
> +++ b/arch/arm/mach-spear/spear13xx.c
> @@ -52,10 +52,10 @@ void __init spear13xx_l2x0_init(void)
> /*
> * Following will create 16MB static virtual/physical mappings
> * PHYSICAL VIRTUAL
> - * 0xB3000000 0xFE000000
> * 0xE0000000 0xFD000000
> * 0xEC000000 0xFC000000
> * 0xED000000 0xFB000000
> + * 0xB3000000 0xF9000000
Why have you moved this to bottom of list? It was probably kept
in increasing order and so please keep the same.
Other than that:
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 5/8] clk: SPEAr13xx: Fix pcie clock name
From: Viresh Kumar @ 2014-01-24 5:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1d96a68894439fa9a571e6234745ab60d4c0f1f5.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> From: Pratyush Anand <pratyush.anand@st.com>
>
> Follow dt clock naming convention for PCIe clocks.
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Tested-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/clk/spear/spear1310_clock.c | 6 +++---
> drivers/clk/spear/spear1340_clock.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 2/8] SPEAr13xx: defconfig: Update
From: Viresh Kumar @ 2014-01-24 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e60c36509dd5d9a39ae7671f8ac80ad1f4506e29.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> Enable EABI, OEABI, VFP and NFS configs in default configuration file for
> SPEAr13xx.
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Mohit Kumar <mohit.kumar@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
From: Viresh Kumar @ 2014-01-24 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12754927160d11063aad96c011c4807cb0aa1775.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> DT field name for the phy address changed since kernel 3.10. Set the
> snps,phy-addr to 0xffffffff so that the driver probes for the phy.
>
> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> ---
> arch/arm/boot/dts/spear13xx.dtsi | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> index 4382547..3518803 100644
> --- a/arch/arm/boot/dts/spear13xx.dtsi
> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> @@ -155,6 +155,7 @@
>
> gmac0: eth at e2000000 {
> compatible = "st,spear600-gmac";
> + snps,phy-addr = <0xffffffff>;
> reg = <0xe2000000 0x8000>;
> interrupts = <0 33 0x4
> 0 34 0x4>;
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 4/8] SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to system cfg driver
From: Pratyush Anand @ 2014-01-24 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401231322.54914.arnd@arndb.de>
Hi Arnd,
Thanks for your valuable comments.
On Thu, Jan 23, 2014 at 08:22:54PM +0800, Arnd Bergmann wrote:
> On Thursday 23 January 2014, Mohit Kumar wrote:
> > diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> > index 3518803..2b4e58e 100644
> > --- a/arch/arm/boot/dts/spear13xx.dtsi
> > +++ b/arch/arm/boot/dts/spear13xx.dtsi
> > @@ -78,6 +78,10 @@
> > status = "disabled";
> > };
> >
> > + cfg {
> > + compatible = "st,spear13xx-cfg";
> > + };
> > +
> > ahb {
> > #address-cells = <1>;
> > #size-cells = <1>;
>
> I only saw some of the patches, and did not get a patch with the binding
> description for this device. Please forward that patch to me, or add it
> to the series if you didn't have one.
It was not there.
Will add a patch for the same in v3.
>
> I assume you'd want a phandle pointing to the syscon device in here
> as well?
Since there is only one syscon device in the whole DT, so do I really
need to add phandle? Currently I am using
syscon_regmap_lookup_by_compatible to find syscon device.
>
> Regarding the naming, please do not use 'xx' wildcards in DT compatible
> strings. Instead, use the exact model name of the first supported
> version of the hardware (e.g. spear1300 or spear600) that remains
> compatible. If there are minor variations between the versions,
> use a list with the most specific version as well as the older ones
> it's compatible with.
Ok..ll take care.
>
> > @@ -221,6 +225,11 @@
> > 0xd8000000 0xd8000000 0x01000000
> > 0xe0000000 0xe0000000 0x10000000>;
> >
> > + misc: misc at e0700000 {
> > + compatible = "st,spear13xx-misc", "syscon";
> > + reg = <0xe0700000 0x1000>;
> > + };
> > +
>
> Same here. Also, I would make this 'misc: syscon at e0700000', since 'misc'
> does not seem like an appropriate device name.
Ok.
>
>
> > +/* SPEAr1340 Registers */
> > +/* Power Management Registers */
> > +#define SPEAR1340_PCM_CFG 0x100
> > + #define SPEAR1340_PCM_CFG_SATA_POWER_EN 0x800
> > +#define SPEAR1340_PCM_WKUP_CFG 0x104
> > +#define SPEAR1340_SWITCH_CTR 0x108
> > +
> > +#define SPEAR1340_PERIP1_SW_RST 0x318
> > + #define SPEAR1340_PERIP1_SW_RST_SATA 0x1000
> > +#define SPEAR1340_PERIP2_SW_RST 0x31C
> > +#define SPEAR1340_PERIP3_SW_RST 0x320
> > +
> > +/* PCIE - SATA configuration registers */
> > +#define SPEAR1340_PCIE_SATA_CFG 0x424
> > + /* PCIE CFG MASks */
> > + #define SPEAR1340_PCIE_CFG_DEVICE_PRESENT (1 << 11)
> > + #define SPEAR1340_PCIE_CFG_POWERUP_RESET (1 << 10)
> > + #define SPEAR1340_PCIE_CFG_CORE_CLK_EN (1 << 9)
> > + #define SPEAR1340_PCIE_CFG_AUX_CLK_EN (1 << 8)
> > + #define SPEAR1340_SATA_CFG_TX_CLK_EN (1 << 4)
> > + #define SPEAR1340_SATA_CFG_RX_CLK_EN (1 << 3)
> > + #define SPEAR1340_SATA_CFG_POWERUP_RESET (1 << 2)
> > + #define SPEAR1340_SATA_CFG_PM_CLK_EN (1 << 1)
> > + #define SPEAR1340_PCIE_SATA_SEL_PCIE (0)
> > + #define SPEAR1340_PCIE_SATA_SEL_SATA (1)
> > + #define SPEAR1340_PCIE_SATA_CFG_MASK 0xF1F
> > + #define SPEAR1340_PCIE_CFG_VAL (SPEAR1340_PCIE_SATA_SEL_PCIE | \
> > + SPEAR1340_PCIE_CFG_AUX_CLK_EN | \
> > + SPEAR1340_PCIE_CFG_CORE_CLK_EN | \
> > + SPEAR1340_PCIE_CFG_POWERUP_RESET | \
> > + SPEAR1340_PCIE_CFG_DEVICE_PRESENT)
> > + #define SPEAR1340_SATA_CFG_VAL (SPEAR1340_PCIE_SATA_SEL_SATA | \
> > + SPEAR1340_SATA_CFG_PM_CLK_EN | \
> > + SPEAR1340_SATA_CFG_POWERUP_RESET | \
> > + SPEAR1340_SATA_CFG_RX_CLK_EN | \
> > + SPEAR1340_SATA_CFG_TX_CLK_EN)
> > +
> > +#define SPEAR1340_PCIE_MIPHY_CFG 0x428
> > + #define SPEAR1340_MIPHY_OSC_BYPASS_EXT (1 << 31)
> > + #define SPEAR1340_MIPHY_CLK_REF_DIV2 (1 << 27)
> > + #define SPEAR1340_MIPHY_CLK_REF_DIV4 (2 << 27)
> > + #define SPEAR1340_MIPHY_CLK_REF_DIV8 (3 << 27)
> > + #define SPEAR1340_MIPHY_PLL_RATIO_TOP(x) (x << 0)
> > + #define SPEAR1340_PCIE_MIPHY_CFG_MASK 0xF80000FF
> > + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA \
> > + (SPEAR1340_MIPHY_OSC_BYPASS_EXT | \
> > + SPEAR1340_MIPHY_CLK_REF_DIV2 | \
> > + SPEAR1340_MIPHY_PLL_RATIO_TOP(60))
> > + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK \
> > + (SPEAR1340_MIPHY_PLL_RATIO_TOP(120))
> > + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_PCIE \
> > + (SPEAR1340_MIPHY_OSC_BYPASS_EXT | \
> > + SPEAR1340_MIPHY_PLL_RATIO_TOP(25))
> > +
> > +struct spear13xx_cfg_priv {
> > + struct regmap *misc;
> > +};
> > +
> > +/* SATA device registration */
> > +static void spear1340_sata_miphy_init(struct spear13xx_cfg_priv *cfgpriv)
> > +{
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCIE_SATA_CFG,
> > + SPEAR1340_PCIE_SATA_CFG_MASK, SPEAR1340_SATA_CFG_VAL);
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCIE_MIPHY_CFG,
> > + SPEAR1340_PCIE_MIPHY_CFG_MASK,
> > + SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK);
> > + /* Switch on sata power domain */
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCM_CFG,
> > + SPEAR1340_PCM_CFG_SATA_POWER_EN,
> > + SPEAR1340_PCM_CFG_SATA_POWER_EN);
> > + msleep(20);
> > + /* Disable PCIE SATA Controller reset */
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PERIP1_SW_RST,
> > + SPEAR1340_PERIP1_SW_RST_SATA, 0);
> > + msleep(20);
> > +}
>
> Looking at the actual code now, this very much looks like it ought to
> be a "phy" driver and get put in drivers/phy/.
Actually these registers are part of common system configurations
register space (called as misc space) for SPEAr SOC. So we opted for
syscon framework.
PHY registers space starts from 0xEB800000, which can be
programmed for various phy specific functions like power management,
tx/rx settings, comparator settings etc. In most of the cases phy
works with default settings, however there are few exceptions for
which we will be adding a phy driver for further improvement of SPEAr
drivers.
Regards
Pratyush
>
> Please see the recent mailing list discussions about making the ahci
> driver more generic. Once you put this code in a proper phy driver,
> you should be able to avoid a lot of your workaround and just use
> the regular ahci-platform driver without any hand-crafted platform
> data callbacks.
>
> Arnd
^ permalink raw reply
* [PATCH V2 6/8] SPEAr13xx: Fix static mapping table
From: Pratyush Anand @ 2014-01-24 3:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401231312.15885.arnd@arndb.de>
On Thu, Jan 23, 2014 at 08:12:15PM +0800, Arnd Bergmann wrote:
> On Thursday 23 January 2014, Mohit Kumar wrote:
> > From: Pratyush Anand <pratyush.anand@st.com>
> >
> > SPEAr13xx was using virtual address space 0xFE000000 to map physical address
> > space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
> > change 0xFE000000 to 0xF9000000.
> >
> > Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> > Tested-by: Mohit Kumar <mohit.kumar@st.com>
> > Cc: Viresh Kumar <viresh.linux@gmail.com>
> > Cc: spear-devel at list.st.com
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: Arnd Bergmann <arnd@arndb.de>
>
> Surely this is needed in backports, so please add stable at vger.kernel.org
> to the Cc list in the changeset text. Otherwise
While sending v3 of series will cc stable list.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks :)
Regards
Pratyush
^ permalink raw reply
* [PATCH V2 3/8] ahci: Add a driver_data field to struct ahci_platform_data
From: Pratyush Anand @ 2014-01-24 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123113644.GA28621@htj.dyndns.org>
On Thu, Jan 23, 2014 at 07:36:44PM +0800, Tejun Heo wrote:
> On Thu, Jan 23, 2014 at 04:02:43PM +0530, Mohit Kumar wrote:
> > diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
> > index 73a2500..76d35e8 100644
> > --- a/include/linux/ahci_platform.h
> > +++ b/include/linux/ahci_platform.h
> > @@ -28,6 +28,7 @@ struct ahci_platform_data {
> > const struct ata_port_info *ata_port_info;
> > unsigned int force_port_map;
> > unsigned int mask_port_map;
> > + void *driver_data;
>
> Please use private_data instead for consistency with other ata data
> structures.
Ok.. ll do that in V3.
Thanks for your review.
Regards
Pratyush
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Anson.Huang at freescale.com @ 2014-01-24 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYPMApJ_uwMYgfDEDVWfBZ5et0pt+JVJxg_t-gZMn4PJSg@mail.gmail.com>
It may be enough, but I am afraid that there is chance that the time_after function's actual delay is shorter than 60us, as the timeout is only one jiffy(10ms), if the jiffy update comes right between the timeout value initialization and the time_after, then the delay may be not enough, is there such possibility? Correct me if I am wrong.
Best Regards.
Anson huang ???
?
Freescale Semiconductor Shanghai
?????????192?A?2?
201203
Tel:021-28937058
>-----Original Message-----
>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>Sent: Friday, January 24, 2014 10:24 AM
>To: Huang Yongcai-B20788
>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>
>Does the time_after function inside the loop is not enough to handle the
>situation?
>
>On Thu, Jan 23, 2014 at 6:05 PM, Anson.Huang at freescale.com
><Anson.Huang@freescale.com> wrote:
>> Hi, Tobias
>> Yes, the root cause is the reschedule introduced by the usleep, for
>our internal release, we use busy loop for PLL wait lock, just removing the
>usleep is not good enough, as the PLL hardware may need about 60~90us to lock,
>during this period, there will be no clock output in PLL. So, we need to
>figure out a way to fix this issue, either using busy loop instead of usleep
>or access the ccm register to adjust ARM divider instead of calling clk APIs.
>>
>> Best Regards.
>> Anson huang ???
>>
>> Freescale Semiconductor Shanghai
>> ?????????192?A?2?
>> 201203
>> Tel:021-28937058
>>
>>
>>>-----Original Message-----
>>>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>>>Sent: Friday, January 24, 2014 4:17 AM
>>>To: Huang Yongcai-B20788
>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>
>>>Hi Anson / Shawn,
>>>
>>>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of
>>>Freescale alpha release. In alpha, the usleep_range did not exist. I
>>>tried removing it, build the kernel again and it works.
>>>I didn't get crashes anymore...
>>>
>>>Regards,
>>>
>>>john
>>>
>>>
>>>
>>>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
>>><Anson.Huang@freescale.com> wrote:
>>>> Hi, Tobias and Shawn
>>>> I debug into this issue today, the root cause is that we
>>>> have a
>>>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's
>>>clk_pllv3_wait_lock function, which will cause kernel schedule during
>>>cpufreq change, and the idle thread has another clk operation which
>>>will cause mutex nest, and it will try to wake up previous mutex hold by
>cpufreq change's pll1 clk_set_rate.
>>>> So, to fix this issue, we should not use any usleep in the
>>>> wait
>>>function of pllv3's code, or we should not call any clk API in the
>>>imx6sl_set_wait_clk function. What do you think?
>>>>
>>>> BTW, I found another issue, if EVK board boot up with
>>>> 396MHz, then
>>>the initialized clock parent status is wrong, as ARM is from PFD
>>>396MHz, I will generate another patch to fix that once I have bandwidth.
>>>>
>>>> Best Regards.
>>>> Anson huang ???
>>>>
>>>> Freescale Semiconductor Shanghai
>>>> ?????????192?A?2?
>>>> 201203
>>>> Tel:021-28937058
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Huang Yongcai-B20788
>>>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>>>To: John Tobias
>>>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>>>
>>>>>Hi, Tobias
>>>>> I will debug it next week and feedback to you. Thanks.
>>>>>
>>>>>Sent from Anson's iPhone
>>>>>
>>>>>> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>>>>>>
>>>>>> Hi Anson,
>>>>>>
>>>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>>>> called in imx6sl_enter_wait.
>>>>>>
>>>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>>>> [<80045650>]
>>>>>> (deactivate_task+0x30/0x34)
>>>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>>>> (schedule+0x38/0x88)
>>>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>>>> (schedule_preempt_disabled+0x10/0x14)
>>>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585]
>>>>>> [<8001e54c>]
>>>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>>>> r4:00000001 [ 288.270949] [<8001ded0>]
>>>>>> (imx6sl_enter_wait+0x0/0x2c) from [<80317608>]
>>>>>> (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>>>> r7:00000001
>>>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>>>> r4:806d2000
>>>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>>>> [<800590f4>]
>>>>>> (cpu_startup_entry+0xe0/0x120)
>>>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>>>> [<806a2b00>]
>>>>>> (start_kernel+0x348/0x354)
>>>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>>>> (0x80008070)
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> john
>>>>>>
>>>>>>
>>>
>>
>
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: John Tobias @ 2014-01-24 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3acb9ee4a574bbaa1cdc5fa77050408@BY2PR03MB315.namprd03.prod.outlook.com>
Does the time_after function inside the loop is not enough to handle
the situation?
On Thu, Jan 23, 2014 at 6:05 PM, Anson.Huang at freescale.com
<Anson.Huang@freescale.com> wrote:
> Hi, Tobias
> Yes, the root cause is the reschedule introduced by the usleep, for our internal release, we use busy loop for PLL wait lock, just removing the usleep is not good enough, as the PLL hardware may need about 60~90us to lock, during this period, there will be no clock output in PLL. So, we need to figure out a way to fix this issue, either using busy loop instead of usleep or access the ccm register to adjust ARM divider instead of calling clk APIs.
>
> Best Regards.
> Anson huang ???
>
> Freescale Semiconductor Shanghai
> ?????????192?A?2?
> 201203
> Tel:021-28937058
>
>
>>-----Original Message-----
>>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>>Sent: Friday, January 24, 2014 4:17 AM
>>To: Huang Yongcai-B20788
>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>
>>Hi Anson / Shawn,
>>
>>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of Freescale
>>alpha release. In alpha, the usleep_range did not exist. I tried removing it,
>>build the kernel again and it works.
>>I didn't get crashes anymore...
>>
>>Regards,
>>
>>john
>>
>>
>>
>>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
>><Anson.Huang@freescale.com> wrote:
>>> Hi, Tobias and Shawn
>>> I debug into this issue today, the root cause is that we have a
>>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's clk_pllv3_wait_lock
>>function, which will cause kernel schedule during cpufreq change, and the idle
>>thread has another clk operation which will cause mutex nest, and it will try
>>to wake up previous mutex hold by cpufreq change's pll1 clk_set_rate.
>>> So, to fix this issue, we should not use any usleep in the wait
>>function of pllv3's code, or we should not call any clk API in the
>>imx6sl_set_wait_clk function. What do you think?
>>>
>>> BTW, I found another issue, if EVK board boot up with 396MHz, then
>>the initialized clock parent status is wrong, as ARM is from PFD 396MHz, I
>>will generate another patch to fix that once I have bandwidth.
>>>
>>> Best Regards.
>>> Anson huang ???
>>>
>>> Freescale Semiconductor Shanghai
>>> ?????????192?A?2?
>>> 201203
>>> Tel:021-28937058
>>>
>>>
>>>>-----Original Message-----
>>>>From: Huang Yongcai-B20788
>>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>>To: John Tobias
>>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>>
>>>>Hi, Tobias
>>>> I will debug it next week and feedback to you. Thanks.
>>>>
>>>>Sent from Anson's iPhone
>>>>
>>>>> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>>>>>
>>>>> Hi Anson,
>>>>>
>>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>>> called in imx6sl_enter_wait.
>>>>>
>>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>>> [<80045650>]
>>>>> (deactivate_task+0x30/0x34)
>>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>>> (schedule+0x38/0x88)
>>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>>> (schedule_preempt_disabled+0x10/0x14)
>>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585] [<8001e54c>]
>>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>>> r4:00000001 [ 288.270949] [<8001ded0>] (imx6sl_enter_wait+0x0/0x2c)
>>>>> from [<80317608>] (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>>> r7:00000001
>>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>>> r4:806d2000
>>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>>> [<800590f4>]
>>>>> (cpu_startup_entry+0xe0/0x120)
>>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>>> [<806a2b00>]
>>>>> (start_kernel+0x348/0x354)
>>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>>> (0x80008070)
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> john
>>>>>
>>>>>
>>
>
^ permalink raw reply
* [PATCH] ARM: moxart: DT fixups
From: Olof Johansson @ 2014-01-24 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390317973-24110-1-git-send-email-jonas.jensen@gmail.com>
On Tue, Jan 21, 2014 at 04:26:13PM +0100, Jonas Jensen wrote:
> Change DT files to remain coherent with changes in
> accompanying drivers.
>
> 1. replace "sdhci" with "mmc"
> 2. add bus-width property to mmc node
> 3. drop device_type property
> 4. replace "mac@" with "ethernet@"
> 5. replace CONFIG_MMC_SDHCI_MOXART with CONFIG_MMC_MOXART
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> ---
>
> Notes:
> Applies on top of:
>
> "[PATCH] ARM: moxart: move fixed rate clock child node to board level dts"
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226141.html
>
> Applies to next-20140121
Since the prereqs for this patch are in different branches right now, I'll have
to apply it after the merges have been done by Linus. I'll include it in
a batch of fixes later on -- remind me if we forget.
-Olof
^ permalink raw reply
* [PATCH] ARM: moxart: move fixed rate clock child node to board level dts
From: Olof Johansson @ 2014-01-24 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389886746-972-1-git-send-email-jonas.jensen@gmail.com>
On Thu, Jan 16, 2014 at 04:39:06PM +0100, Jonas Jensen wrote:
> When a skeleton "clocks { .. }" remain in .dtsi, the child node can
> be moved to .dts, "ref12" is then found by of_clk_get().
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
Applied to late/misc branch, will likely be included in 3.14-rc1
-Olof
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Anson.Huang at freescale.com @ 2014-01-24 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYOuuPzPHyUSm_zyq1iq1FeaCoQ03Ko4yO8mmM+PDGm5gw@mail.gmail.com>
Hi, Tobias
Yes, the root cause is the reschedule introduced by the usleep, for our internal release, we use busy loop for PLL wait lock, just removing the usleep is not good enough, as the PLL hardware may need about 60~90us to lock, during this period, there will be no clock output in PLL. So, we need to figure out a way to fix this issue, either using busy loop instead of usleep or access the ccm register to adjust ARM divider instead of calling clk APIs.
Best Regards.
Anson huang ???
?
Freescale Semiconductor Shanghai
?????????192?A?2?
201203
Tel:021-28937058
>-----Original Message-----
>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>Sent: Friday, January 24, 2014 4:17 AM
>To: Huang Yongcai-B20788
>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>
>Hi Anson / Shawn,
>
>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of Freescale
>alpha release. In alpha, the usleep_range did not exist. I tried removing it,
>build the kernel again and it works.
>I didn't get crashes anymore...
>
>Regards,
>
>john
>
>
>
>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
><Anson.Huang@freescale.com> wrote:
>> Hi, Tobias and Shawn
>> I debug into this issue today, the root cause is that we have a
>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's clk_pllv3_wait_lock
>function, which will cause kernel schedule during cpufreq change, and the idle
>thread has another clk operation which will cause mutex nest, and it will try
>to wake up previous mutex hold by cpufreq change's pll1 clk_set_rate.
>> So, to fix this issue, we should not use any usleep in the wait
>function of pllv3's code, or we should not call any clk API in the
>imx6sl_set_wait_clk function. What do you think?
>>
>> BTW, I found another issue, if EVK board boot up with 396MHz, then
>the initialized clock parent status is wrong, as ARM is from PFD 396MHz, I
>will generate another patch to fix that once I have bandwidth.
>>
>> Best Regards.
>> Anson huang ???
>>
>> Freescale Semiconductor Shanghai
>> ?????????192?A?2?
>> 201203
>> Tel:021-28937058
>>
>>
>>>-----Original Message-----
>>>From: Huang Yongcai-B20788
>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>To: John Tobias
>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>
>>>Hi, Tobias
>>> I will debug it next week and feedback to you. Thanks.
>>>
>>>Sent from Anson's iPhone
>>>
>>>> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>>>>
>>>> Hi Anson,
>>>>
>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>> called in imx6sl_enter_wait.
>>>>
>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>> [<80045650>]
>>>> (deactivate_task+0x30/0x34)
>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>> (schedule+0x38/0x88)
>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>> (schedule_preempt_disabled+0x10/0x14)
>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585] [<8001e54c>]
>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>> r4:00000001 [ 288.270949] [<8001ded0>] (imx6sl_enter_wait+0x0/0x2c)
>>>> from [<80317608>] (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>> r7:00000001
>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>> r4:806d2000
>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>> [<800590f4>]
>>>> (cpu_startup_entry+0xe0/0x120)
>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>> [<806a2b00>]
>>>> (start_kernel+0x348/0x354)
>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>> (0x80008070)
>>>>
>>>>
>>>> Regards,
>>>>
>>>> john
>>>>
>>>>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox