* [RFC PATCH 1/9] mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
From: Brian Norris @ 2014-01-23 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389190924-26226-2-git-send-email-b.brezillon@overkiz.com>
+ Huang
Hi Boris,
On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote:
> The Hynix nand flashes store their ECC requirements in byte 4 of its id
> (returned on READ ID command).
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
I haven't verified yet (perhaps Huang can confirm?), but this may be
similar to a patch Huang submitted recently. In his case, we found that
this table is actually quite unreliable and is likely hard to maintain.
Why do you need this ECC information, for my reference?
Brian
^ permalink raw reply
* Freescale FEC packet loss
From: fugang.duan at freescale.com @ 2014-01-23 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401222255.29467.marex@denx.de>
Hi, Marek,
From: Marek Vasut <marex@denx.de>
Data: Thursday, January 23, 2014 5:55 AM
>To: netdev at vger.kernel.org
>Cc: Li Frank-B20596; Duan Fugang-B38611; Estevam Fabio-R49496; Hector Palacios;
>linux-arm-kernel at lists.infradead.org; Detlev Zundel; Eric Nelson
>Subject: Freescale FEC packet loss
>
>Hi guys,
>
>I am running stock Linux 3.13 on i.MX6Q SabreLite board. The CPU is i.MX6Q TO
>1.0 .
>
>I am hitting a WARNING when I use the FEC ethernet to transfer data, thus I
>started investigating this problem. TL;DR I am not able to figure this problem
>out, so I am not attaching a patch :-(
>
>Steps to reproduce:
>-------------------
>1) Boot stock Linux 3.13 on i.MX6Q SabreLite board
>2) Plug in an SD card into one of the SD slots (I use the full-size one)
>3) Plug in an USB stick into one of the USB ports (I use the upper one)
>4) Plug in an ethernet cable into the board
> -> Connect the other side into a gigabit-capable PC
> -> Let us assume the PC has IP address 192.168.1.1/24 and
> the board 192.168.1.2/24
>5) Install iperf on both boards
>6) Bring up the ethernet link on both ends:
> $ ifconfig ...
>7) On the PC, run:
> $ iperf -s -i 1
>8) Start producing load on the in-CPU busses. Run this on the board:
> $ sha1sum /dev/mmcblk0 &
> $ sha1sum /dev/sda &
>9) Now let the board generate ethernet traffic:
> $ iperf -c 192.168.1.1 -t 1000 -i 1
>
>Now wait about 10 minutes and the system will produce a warning and you will
>observe dips in the transmission speed. You can see the output at the end of
>the email.
>
>I observe that this happens more often when there is a severe load on the
>busses, which in this case I simulate by running the sha1sum on /dev/mmcblk0
>and sha1sum /dev/sda in the background in step 8) . I can also well simulate
>this by running 'sha1sum /dev/mmcblk0 & sha1sum /dev/mmcblk1 &' when I have
>both SD cards populated on the MX6Q sabrelite with the same result (WARNING and
>dips in speed).
>
>There was apparently a thread about this problem already [1] where the person
>used SATA to produce high bus load and had exactly the same result.
>
>One more observation is that I managed to replicate this problem all the way
>back to Linux 3.3.8 , which is one of the first kernel versions where sabrelite
>was supported. I also see this one the Freescale's 3.0.35-4.1.0 .
>
>I have trouble figuring out what this problem is all about. Can you please help
>me? Thank you!
>
>[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-
>October/202519.html
>
>root@(none):~# iperf -c 192.168.1.1 -t 1000 -i 1
>------------------------------------------------------------
>Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 43.8 KByte
>(default)
>------------------------------------------------------------
>[ 3] local 192.168.1.128 port 36760 connected with 192.168.1.1 port 5001
>[ ID] Interval Transfer Bandwidth
>[ 3] 0.0- 1.0 sec 25.5 MBytes 214 Mbits/sec
>[ 3] 1.0- 2.0 sec 28.9 MBytes 242 Mbits/sec
>[ 3] 2.0- 3.0 sec 24.1 MBytes 202 Mbits/sec
>[ 3] 3.0- 4.0 sec 21.1 MBytes 177 Mbits/sec
>[ 3] 4.0- 5.0 sec 20.2 MBytes 170 Mbits/sec
>[ 3] 5.0- 6.0 sec 20.0 MBytes 168 Mbits/sec
>[ 3] 6.0- 7.0 sec 20.0 MBytes 168 Mbits/sec
>[ 3] 7.0- 8.0 sec 20.1 MBytes 169 Mbits/sec
>[ 3] 8.0- 9.0 sec 20.5 MBytes 172 Mbits/sec
>[ 3] 9.0-10.0 sec 21.5 MBytes 180 Mbits/sec
>[ 3] 10.0-11.0 sec 20.0 MBytes 168 Mbits/sec
>[ 3] 11.0-12.0 sec 19.4 MBytes 163 Mbits/sec
>[ 3] 12.0-13.0 sec 19.6 MBytes 165 Mbits/sec
>[ 3] 13.0-14.0 sec 19.8 MBytes 166 Mbits/sec
>[ 3] 14.0-15.0 sec 19.4 MBytes 163 Mbits/sec
>[ 275.945247] ------------[ cut here ]------------ [ 275.949920] WARNING: CPU:
>3 PID: 1155 at net/sched/sch_generic.c:264
>dev_watchdog+0x280/0x2a4()
>[ 275.958679] NETDEV WATCHDOG: eth3 (fec): transmit queue 0 timed out
>[ 275.964985] Modules linked in:
>[ 275.968096] CPU: 3 PID: 1155 Comm: sha1sum Not tainted 3.13.0 #18
>[ 275.974217] Backtrace:
>[ 275.976787] [<80012410>] (dump_backtrace+0x0/0x10c) from [<800125ac>]
>(show_stack+0x18/0x1c)
>[ 275.985271] r6:00000108 r5:00000009 r4:00000000 r3:00000000
>[ 275.991050] [<80012594>] (show_stack+0x0/0x1c) from [<8060f9c8>]
>(dump_stack+0x80/0x9c)
>[ 275.999103] [<8060f948>] (dump_stack+0x0/0x9c) from [<8002703c>]
>(warn_slowpath_common+0x6c/0x90)
>[ 276.008017] r4:bef43e10 r3:bef96c00
>[ 276.011663] [<80026fd0>] (warn_slowpath_common+0x0/0x90) from [<80027104>]
>(warn_slowpath_fmt+0x3)
>[ 276.021170] r8:bf098240 r7:bef42000 r6:bf098200 r5:bf068000 r4:00000000
>[ 276.028083] [<800270cc>] (warn_slowpath_fmt+0x0/0x40) from [<804e2754>]
>(dev_watchdog+0x280/0x2a4)
>[ 276.037095] r3:bf068000 r2:807d2fb4
>[ 276.040734] [<804e24d4>] (dev_watchdog+0x0/0x2a4) from [<80030e1c>]
>(call_timer_fn+0x70/0xec)
>[ 276.049313] [<80030dac>] (call_timer_fn+0x0/0xec) from [<80031a90>]
>(run_timer_softirq+0x198/0x23)
>[ 276.058407] r8:00200200 r7:00000000 r6:bef43ec8 r5:bf836000 r4:bf068284
>[ 276.065257] [<800318f8>] (run_timer_softirq+0x0/0x230) from [<8002b480>]
>(__do_softirq+0x100/0x25)
>[ 276.074338] [<8002b380>] (__do_softirq+0x0/0x254) from [<8002b9a8>]
>(irq_exit+0xb0/0x108)
>[ 276.082570] [<8002b8f8>] (irq_exit+0x0/0x108) from [<8000f3dc>]
>(handle_IRQ+0x58/0xb8)
>[ 276.090528] r4:8086ccc8 r3:00000184
>[ 276.094162] [<8000f384>] (handle_IRQ+0x0/0xb8) from [<80008640>]
>(gic_handle_irq+0x30/0x64)
>[ 276.102552] r8:5590d9fa r7:f4000100 r6:bef43fb0 r5:8086ce14 r4:f400010c
>r3:000000a0
>[ 276.110575] [<80008610>] (gic_handle_irq+0x0/0x64) from [<800133a0>]
>(__irq_usr+0x40/0x60)
>[ 276.118871] Exception stack(0xbef43fb0 to 0xbef43ff8)
>[ 276.123942] 3fa0: fbe9d585 13e98d33
>6ed9eba1 21e67a57
>[ 276.132173] 3fc0: 170dd9fc bc58d89e 5d1b7878 c19f2bf4 5590d9fa 2577bcc4
>7b2ac1ea 6cee44dd [ 276.140398] 3fe0: cf486f09 7ea92a58 0000ba1f 0000ab72
>a0000030 ffffffff [ 276.147041] r7:c19f2bf4 r6:ffffffff r5:a0000030
>r4:0000ab72 [ 276.152846] ---[ end trace 054500acb8edb763 ]---
>[ 3] 15.0-16.0 sec 18.8 MBytes 157 Mbits/sec
>[ 3] 16.0-17.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 17.0-18.0 sec 0.00 Bytes
>0.00 bits/sec [ 3] 18.0-19.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 19.0-20.0
>sec 4.25 MBytes 35.7 Mbits/sec
>[ 3] 20.0-21.0 sec 19.8 MBytes 166 Mbits/sec
>[ 3] 21.0-22.0 sec 19.8 MBytes 166 Mbits/sec
>[ 3] 22.0-23.0 sec 19.5 MBytes 164 Mbits/sec
>[ 3] 23.0-24.0 sec 8.38 MBytes 70.3 Mbits/sec [ 3] 24.0-25.0 sec 0.00
>Bytes 0.00 bits/sec [ 3] 25.0-26.0 sec 7.88 MBytes 66.1 Mbits/sec
>[ 3] 26.0-27.0 sec 20.1 MBytes 169 Mbits/sec
>[...]
>[ 3] 71.0-72.0 sec 23.4 MBytes 196 Mbits/sec
>[ 3] 72.0-73.0 sec 12.2 MBytes 103 Mbits/sec
>[ 3] 73.0-74.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 74.0-75.0 sec 0.00 Bytes
>0.00 bits/sec [ 3] 75.0-76.0 sec 10.9 MBytes 91.2 Mbits/sec
>[ 3] 76.0-77.0 sec 22.4 MBytes 188 Mbits/sec
>[ 3] 77.0-78.0 sec 23.0 MBytes 193 Mbits/sec
>
I will debug the issue when I am free, and then report the result to you.
Thanks for your reporting the issue.
Thanks,
Andy
^ permalink raw reply
* [PATCH] clk: export __clk_get_hw for re-use in others
From: SeongJae Park @ 2014-01-23 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPtuhThZdDkKq_fruaduPknpXxCTHgCA7mCnDDh+vS_OiUy+1w@mail.gmail.com>
On Thu, Jan 23, 2014 at 3:11 AM, Mike Turquette <mturquette@linaro.org> wrote:
> On Wed, Jan 22, 2014 at 9:59 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> On 01/21/14 21:23, SeongJae Park wrote:
>>> On Wed, Jan 22, 2014 at 1:59 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>>>> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>>>>> Dear Greg, Mike,
>>>>>
>>>>> May I ask your answer or other opinion, please?
>>>> It's the middle of the merge window, it's not time for new development,
>>>> or much time for free-time for me, sorry. Feel free to fix it the best
>>>> way you know how.
>>> Oops, I've forgot about the merge window. Thank you very much for your
>>> kind answer.
>>> Sorry if I bothered you while you're in busy time.
>>> Because the build problem is not a big deal because it exists only in
>>> -next tree,
>>> I will wait until merge window be closed and then fix it again if it
>>> still exist.
>>>
>>
>> I've already sent a patch that exports this and other clock provider
>> functions. Please use this one:
>>
>> https://patchwork.kernel.org/patch/3507921/
>
> I'm going to take Stephen's patch into a fixes branch and send it as
> part of a pull request. Maybe -rc1 or -rc2 at the latest.
Got it. Thank you for let me know :)
>
> Thanks all.
>
> Regards,
> Mike
>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> hosted by The Linux Foundation
>>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6sl-evk: Add PFUZE100 support
From: Fabio Estevam @ 2014-01-23 2:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
imx6sl-evk board has Freescale PFUZE100 regulator, so add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6sl-evk.dts | 110 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6sl-pingrp.h | 4 ++
2 files changed, 114 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index f23b5d1..5ba15ab 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -46,6 +46,112 @@
};
};
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic: pfuze100 at 08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
&ecspi1 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 11 0>;
@@ -86,6 +192,10 @@
>;
};
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <MX6SL_I2C1_PINGRP1>;
+ };
+
pinctrl_ecspi1: ecspi1grp {
fsl,pins = <MX6SL_ECSPI1_PINGRP1>;
};
diff --git a/arch/arm/boot/dts/imx6sl-pingrp.h b/arch/arm/boot/dts/imx6sl-pingrp.h
index ead26d4..cada37a 100644
--- a/arch/arm/boot/dts/imx6sl-pingrp.h
+++ b/arch/arm/boot/dts/imx6sl-pingrp.h
@@ -15,6 +15,10 @@
MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1 \
MX6SL_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x100b1
+#define MX6SL_I2C1_PINGRP1 \
+ MX6SL_PAD_I2C1_SCL__I2C1_SCL 0x4001b8b1 \
+ MX6SL_PAD_I2C1_SDA__I2C1_SDA 0x4001b8b1
+
#define MX6SL_FEC_PINGRP1 \
MX6SL_PAD_FEC_MDC__FEC_MDC 0x1b0b0 \
MX6SL_PAD_FEC_MDIO__FEC_MDIO 0x1b0b0 \
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx6sl-evk: Add audio support
From: Fabio Estevam @ 2014-01-23 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390443213-14061-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
imx6sl-evk has a wm8962 codec. Add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6sl-evk.dts | 72 +++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6sl-pingrp.h | 11 ++++++
arch/arm/boot/dts/imx6sl.dtsi | 3 ++
3 files changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index 5ba15ab..9e1ab77 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -24,6 +24,22 @@
#address-cells = <1>;
#size-cells = <0>;
+ reg_aud3v: wm8962_supply_3v15 {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8962-supply-3v15";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+ regulator-boot-on;
+ };
+
+ reg_aud4v: wm8962_supply_4v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8962-supply-4v2";
+ regulator-min-microvolt = <4325000>;
+ regulator-max-microvolt = <4325000>;
+ regulator-boot-on;
+ };
+
reg_usb_otg1_vbus: regulator at 0 {
compatible = "regulator-fixed";
reg = <0>;
@@ -44,6 +60,28 @@
enable-active-high;
};
};
+
+ sound {
+ compatible = "fsl,imx6sl-evk-wm8962", "fsl,imx-audio-wm8962";
+ model = "wm8962-audio";
+ ssi-controller = <&ssi2>;
+ audio-codec = <&codec>;
+ audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "Ext Spk", "SPKOUTL",
+ "Ext Spk", "SPKOUTR",
+ "AMIC", "MICBIAS",
+ "IN3R", "AMIC";
+ mux-int-port = <2>;
+ mux-ext-port = <3>;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux3>;
+ status = "okay";
};
&i2c1 {
@@ -152,6 +190,27 @@
};
};
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ codec: wm8962 at 1a {
+ compatible = "wlf,wm8962";
+ reg = <0x1a>;
+ clocks = <&clks IMX6SL_CLK_EXTERN_AUDIO>;
+ DCVDD-supply = <&vgen3_reg>;
+ DBVDD-supply = <®_aud3v>;
+ AVDD-supply = <&vgen3_reg>;
+ CPVDD-supply = <&vgen3_reg>;
+ MICVDD-supply = <®_aud3v>;
+ PLLVDD-supply = <&vgen3_reg>;
+ SPKVDD1-supply = <®_aud4v>;
+ SPKVDD2-supply = <®_aud4v>;
+ };
+};
+
&ecspi1 {
fsl,spi-num-chipselects = <1>;
cs-gpios = <&gpio4 11 0>;
@@ -192,10 +251,18 @@
>;
};
+ pinctrl_audmux3: audmux3grp {
+ fsl,pins = <MX6SL_AUDMUX3_PINGRP1>;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <MX6SL_I2C1_PINGRP1>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <MX6SL_I2C2_PINGRP1>;
+ };
+
pinctrl_ecspi1: ecspi1grp {
fsl,pins = <MX6SL_ECSPI1_PINGRP1>;
};
@@ -277,6 +344,11 @@
status = "okay";
};
+&ssi2 {
+ fsl,mode = "i2s-slave";
+ status = "okay";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
diff --git a/arch/arm/boot/dts/imx6sl-pingrp.h b/arch/arm/boot/dts/imx6sl-pingrp.h
index cada37a..ee50ace 100644
--- a/arch/arm/boot/dts/imx6sl-pingrp.h
+++ b/arch/arm/boot/dts/imx6sl-pingrp.h
@@ -10,6 +10,13 @@
#ifndef __DTS_IMX6SL_PINGRP_H
#define __DTS_IMX6SL_PINGRP_H
+#define MX6SL_AUDMUX3_PINGRP1 \
+ MX6SL_PAD_AUD_RXD__AUD3_RXD 0x4130B0 \
+ MX6SL_PAD_AUD_TXC__AUD3_TXC 0x4130B0 \
+ MX6SL_PAD_AUD_TXD__AUD3_TXD 0x4110B0 \
+ MX6SL_PAD_AUD_TXFS__AUD3_TXFS 0x4130B0 \
+ MX6SL_PAD_AUD_MCLK__AUDIO_CLK_OUT 0x4130B0
+
#define MX6SL_ECSPI1_PINGRP1 \
MX6SL_PAD_ECSPI1_MISO__ECSPI1_MISO 0x100b1 \
MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1 \
@@ -19,6 +26,10 @@
MX6SL_PAD_I2C1_SCL__I2C1_SCL 0x4001b8b1 \
MX6SL_PAD_I2C1_SDA__I2C1_SDA 0x4001b8b1
+#define MX6SL_I2C2_PINGRP1 \
+ MX6SL_PAD_I2C2_SCL__I2C2_SCL 0x4001b8b1 \
+ MX6SL_PAD_I2C2_SDA__I2C2_SDA 0x4001b8b1
+
#define MX6SL_FEC_PINGRP1 \
MX6SL_PAD_FEC_MDC__FEC_MDC 0x1b0b0 \
MX6SL_PAD_FEC_MDIO__FEC_MDIO 0x1b0b0 \
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 95bb37b..04cf457 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -236,6 +236,7 @@
<&sdma 38 1 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
+ fsl,ssi-dma-events = <38 37>;
status = "disabled";
};
@@ -250,6 +251,7 @@
<&sdma 42 1 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
+ fsl,ssi-dma-events = <42 41>;
status = "disabled";
};
@@ -264,6 +266,7 @@
<&sdma 46 1 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
+ fsl,ssi-dma-events = <46 45>;
status = "disabled";
};
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Wang Nan @ 2014-01-23 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122132734.GB15937@n2100.arm.linux.org.uk>
On 2014/1/22 21:27, Russell King - ARM Linux wrote:
> On Wed, Jan 22, 2014 at 07:25:15PM +0800, Wang Nan wrote:
>> ARM's kdump is actually corrupted (at least for omap4460), mainly because of
>> cache problem: flush_icache_range can't reliably ensure the copied data
>> correctly goes into RAM.
>
> Quite right too. You're mistake here is thinking that flush_icache_range()
> should push it to RAM. That's incorrect.
>
> flush_icache_range() is there to deal with such things as loadable modules
> and self modifying code, where the MMU is not being turned off. Hence, it
> only flushes to the point of coherency between the I and D caches, and
> any further levels of cache between that point and memory are not touched.
> Why should it touch any more levels - it's not the function's purpose.
>
>> After mmu turned off and jump to the trampoline, kexec always failed due
>> to random undef instructions.
>
> We already have code in the kernel which deals with shutting the MMU off.
> An instance of how this can be done is illustrated in the soft_restart()
> code path, and kexec already uses this.
>
> One of the first things soft_restart() does is turn off the outer cache -
> which OMAP4 does have, but this can only be done if there is a single CPU
> running. If there's multiple CPUs running, then the outer cache can't be
> disabled, and that's the most likely cause of the problem you're seeing.
>
You are right, commit b25f3e1c (OMAP4/highbank: Flush L2 cache before disabling)
solves my problem, it flushes outer cache before disabling. I have tested it in
UP and SMP situations and it works (actually, omap4 has not ready to support kexec
in SMP case, I insert an empty cpu_kill() to make it work), so the first 2
patches are unneeded.
What about the 3rd one (ARM: allow kernel to be loaded in middle of phymem)?
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: Fabio Estevam @ 2014-01-23 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYPakuAGOWb+RetqNhEBvRP-+Pmtu2_4a2zuV0bFR0QJRA@mail.gmail.com>
On Wed, Jan 22, 2014 at 9:49 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hello all,
>
> Just to confirm that the error I posted previously exist in 3.13
> released. Just be noted that some patches related to eMMC/sdhci has
> been applied in order to boot the 3.13 on my board.
> Addition to that, I was getting additional errors (please see below):
> - It happened during the reboot.
>
> Cc'ng Dong Aisheng.
What are the steps to reproduce this? Which SoC are you using?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 0/3] clk: mmp: bug fix for clk-frac
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Chao Xie <chao.xie@marvell.com>
When use the clk-frac type of mmp, some bugs are found.
The following 3 patches are bug fix for clk-frac
Chao Xie (3):
clk: mmp: fix wrong mask when calculate denominator
clk: mmp: fix the wrong calculation formula
clk: mmp: try to use closer one when do round rate
drivers/clk/mmp/clk-frac.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/3] clk: mmp: fix wrong mask when calculate denominator
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390445262-27486-1-git-send-email-chao.xie@marvell.com>
From: Chao Xie <chao.xie@marvell.com>
The code has typo when calculate denominator. It should use
den_mask instead of num_mask.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/clk/mmp/clk-frac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 80c1dd1..f6e7691 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -64,7 +64,7 @@ static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
num = (val >> masks->num_shift) & masks->num_mask;
/* calculate denominator */
- den = (val >> masks->den_shift) & masks->num_mask;
+ den = (val >> masks->den_shift) & masks->den_mask;
if (!den)
return 0;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] clk: mmp: fix the wrong calculation formula
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390445262-27486-1-git-send-email-chao.xie@marvell.com>
From: Chao Xie <chao.xie@marvell.com>
The formula is numerator/denominator = Fin / (Fout * factor)
So
Fout = Fin * denominator / (numerator * factor).
Current clk_factor_round_rate and clk_factor_recalc_rate use
wrong formula. This patch will fix them.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/clk/mmp/clk-frac.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index f6e7691..5863a37 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -40,12 +40,12 @@ static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
for (i = 0; i < factor->ftbl_cnt; i++) {
prev_rate = rate;
- rate = (((*prate / 10000) * factor->ftbl[i].num) /
- (factor->ftbl[i].den * factor->masks->factor)) * 10000;
+ rate = (((*prate / 10000) * factor->ftbl[i].den) /
+ (factor->ftbl[i].num * factor->masks->factor)) * 10000;
if (rate > drate)
break;
}
- if (i == 0)
+ if ((i == 0) || (i == factor->ftbl_cnt))
return rate;
else
return prev_rate;
@@ -85,8 +85,8 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned long drate,
for (i = 0; i < factor->ftbl_cnt; i++) {
prev_rate = rate;
- rate = (((prate / 10000) * factor->ftbl[i].num) /
- (factor->ftbl[i].den * factor->masks->factor)) * 10000;
+ rate = (((prate / 10000) * factor->ftbl[i].den) /
+ (factor->ftbl[i].num * factor->masks->factor)) * 10000;
if (rate > drate)
break;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/3] clk: mmp: try to use closer one when do round rate
From: Chao Xie @ 2014-01-23 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390445262-27486-1-git-send-email-chao.xie@marvell.com>
From: Chao Xie <chao.xie@marvell.com>
The orignal code will use the bigger rate between
"previous rate" and "current rate" when caculate the
rate.
In fact, hardware cares about the closest one.
So choose the closer rate between "previous rate" and
"current rate".
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/clk/mmp/clk-frac.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 5863a37..23a56f5 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -45,10 +45,14 @@ static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
if (rate > drate)
break;
}
- if ((i == 0) || (i == factor->ftbl_cnt))
+ if ((i == 0) || (i == factor->ftbl_cnt)) {
return rate;
- else
- return prev_rate;
+ } else {
+ if ((drate - prev_rate) > (rate - drate))
+ return rate;
+ else
+ return prev_rate;
+ }
}
static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
--
1.8.3.2
^ permalink raw reply related
* Internal error: Oops: 17 [#1] ARM
From: walimis @ 2014-01-23 3:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYPXficVuqDgy6_Tnh9b-VOXDNK=+nqb6U5O6NpcZOGGpQ@mail.gmail.com>
On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote:
>Hello all,
>
>I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in
>eMMC running SDR50.
>Is anyone here encountered these problem and if there's any existing
>patch that I can get?.
hi,
Do you use gcc 4.8.1? If so, maybe you should look at following link
to see whether it's a similar issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
Liming Wang
>
>Regards,
>
>john
>
>[ 1552.394899] Unable to handle kernel NULL pointer dereference at
>virtual address 00000037
>[ 1552.403034] pgd = beef4000
>[ 1552.405855] [00000037] *pgd=bef60831, *pte=00000000, *ppte=00000000
>[ 1552.412245] Internal error: Oops: 17 [#1] ARM
>[ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O)
>[ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O 3.13.0-rc1 #7
>[ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000
>[ 1552.434844] PC is at lookup_fast+0x5c/0x318
>[ 1552.439067] LR is at mark_held_locks+0x78/0x13c
>[ 1552.443622] pc : [<80101184>] lr : [<80056e48>] psr: a00f0013
>[ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc
>[ 1552.455124] r10: 00000000 r9 : bec97e08 r8 : 80102d94
>[ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00
>[ 1552.466918] r3 : bee4f01d r2 : 00000000 r1 : ffffffff r0 : ffffffff
>[ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>[ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 00000015
>[ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238)
>[ 1552.492341] Stack: (0xbec97d88 to 0xbec98000)
>[ 1552.496728] 7d80: 80102b94 80057108 bfb95310
>bf133ac8 bf15f4e8 bfb95310
>[ 1552.504936] 7da0: c08bb14d ffffffff bee4f015 00000008 bfbc7500
>bec97e08 00000000 00000041
>[ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 00000000 bec97e3c
>bec97de0 80102d94 80101134
>[ 1552.521347] 7de0: bec97df8 00000000 800d982c bec96018 00000010
>bec97e00 00000000 bec97e08
>[ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 00000ff0 80d4e3a4
>00000001 bee4f000 bec97e60
>[ 1552.537758] 7e20: ffffff9c ffffff9c bec96000 00000000 bec97e5c
>bec97e40 801033bc 80102c70
>[ 1552.545964] 7e40: bee4f000 00000001 bec97e60 bec97f00 bec97ee4
>bec97e60 80105dc0 80103398
>[ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 0000000b bee4f015
>8005992c bfb95310 bf133398
>[ 1552.562375] 7e80: bf15f4e8 00000041 00000002 0000008a 00000000
>00000000 600f0013 bec96000
>[ 1552.570581] 7ea0: ffffffea bf8c1840 807b4430 80115444 801156e4
>8011563c 00000008 00000000
>[ 1552.578786] 7ec0: bec97f04 733fe4e0 00000001 ffffff9c 757e3810
>bec97f40 bec97efc bec97ee8
>[ 1552.586991] 7ee0: 80105e0c 80105d68 00000000 bc950fe0 bec97f2c
>bec97f00 800faf64 80105df4
>[ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0
>733fe61c 000000c3 8000f504
>[ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4
>bec97f40 800fb71c 800fafc4
>[ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c
>000000c3 bec97f84 bec97f68
>[ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c
>000000c3 bec97f94 bec97f88
>[ 1552.628019] 7f80: 80057110 80056f18 00000000 bec97f98 8000f458
>733fe550 00000000 bec97fa8
>[ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810
>733fe4e0 733fe550 00000003
>[ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 000000c3 00000000
>00000002 733fe92c 00000200
>[ 1552.652636] 7fe0: 000000c3 733fe4d8 7579b7e5 7572e276 200f0030
>757e3810 bfffd821 bfffdc21
>[ 1552.660828] Backtrace:
>[ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>]
>(path_lookupat+0x130/0x728)
>[ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from
>[<801033bc>] (filename_lookup.isra.40+0x30/0x70)
>[ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from
>[<80105dc0>] (user_path_at_empty+0x64/0x8c)
>[ 1552.691361] r7:bec97f00 r6:bec97e60 r5:00000001 r4:bee4f000
>[ 1552.697163] [<80105d5c>] (user_path_at_empty+0x0/0x8c) from
>[<80105e0c>] (user_path_at+0x24/0x2c)
>[ 1552.706053] r8:bec97f40 r7:757e3810 r6:ffffff9c r5:00000001 r4:733fe4e0
>[ 1552.712927] [<80105de8>] (user_path_at+0x0/0x2c) from [<800faf64>]
>(vfs_fstatat+0x54/0xa8)
>[ 1552.721232] [<800faf10>] (vfs_fstatat+0x0/0xa8) from [<800fafe0>]
>(vfs_stat+0x28/0x2c)
>[ 1552.729167] r8:8000f504 r7:000000c3 r6:733fe61c r5:733ff8f0 r4:733fe4e0
>[ 1552.736031] [<800fafb8>] (vfs_stat+0x0/0x2c) from [<800fb71c>]
>(SyS_stat64+0x24/0x40)
>[ 1552.743902] [<800fb6f8>] (SyS_stat64+0x0/0x40) from [<8000f280>]
>(ret_fast_syscall+0x0/0x48)
>[ 1552.752359] r4:733fe550
>[ 1552.754946] Code: eb00352d e3500000 e50b0038 0a000080 (e5903038)
>[ 1552.761270] ---[ end trace 02679086a39365e8 ]---
>[ 1552.765968] Kernel panic - not syncing: Fatal exception
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: John Tobias @ 2014-01-23 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BhZspH3FfDh+3z0xBpgxWEHK1Fa5KOYsN5og2VfGktXQ@mail.gmail.com>
Hi Fabio,
Attached are the two patch files that I applied in the 3.13 released
so that the kernel will detect my eMMC in DDR50.
(let me correct my previous email, I was mentioning SDR50 but it
should be DDR50).
eMMC info:
clock: 52000000 Hz
actual clock: 49500000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 3 (8 bits)
timing spec: 1 (mmc high-speed)
signal voltage: 0 (3.30 V)
I reboot my device often and it shows during the reboot.
Regards,
john
On Wed, Jan 22, 2014 at 6:28 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Jan 22, 2014 at 9:49 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Hello all,
>>
>> Just to confirm that the error I posted previously exist in 3.13
>> released. Just be noted that some patches related to eMMC/sdhci has
>> been applied in order to boot the 3.13 on my board.
>> Addition to that, I was getting additional errors (please see below):
>> - It happened during the reboot.
>>
>> Cc'ng Dong Aisheng.
>
> What are the steps to reproduce this? Which SoC are you using?
>
> Regards,
>
> Fabio Estevam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdhci-esdhc-imx.patch
Type: application/octet-stream
Size: 2464 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/15d70bc1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdhci.patch
Type: application/octet-stream
Size: 2522 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/15d70bc1/attachment-0001.obj>
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: John Tobias @ 2014-01-23 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123030103.GC18520@pek-lwang0-d1>
Hi Liming,
Yes, I am using 4.8.1. I switched back to 4.7.3 and will test it again
if I can re-produce it.
Regards,
john
On Wed, Jan 22, 2014 at 7:01 PM, walimis <walimisdev@gmail.com> wrote:
> On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote:
>>Hello all,
>>
>>I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in
>>eMMC running SDR50.
>>Is anyone here encountered these problem and if there's any existing
>>patch that I can get?.
> hi,
>
> Do you use gcc 4.8.1? If so, maybe you should look at following link
> to see whether it's a similar issue.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
>
> Liming Wang
>
>>
>>Regards,
>>
>>john
>>
>>[ 1552.394899] Unable to handle kernel NULL pointer dereference at
>>virtual address 00000037
>>[ 1552.403034] pgd = beef4000
>>[ 1552.405855] [00000037] *pgd=bef60831, *pte=00000000, *ppte=00000000
>>[ 1552.412245] Internal error: Oops: 17 [#1] ARM
>>[ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O)
>>[ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O 3.13.0-rc1 #7
>>[ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000
>>[ 1552.434844] PC is at lookup_fast+0x5c/0x318
>>[ 1552.439067] LR is at mark_held_locks+0x78/0x13c
>>[ 1552.443622] pc : [<80101184>] lr : [<80056e48>] psr: a00f0013
>>[ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc
>>[ 1552.455124] r10: 00000000 r9 : bec97e08 r8 : 80102d94
>>[ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00
>>[ 1552.466918] r3 : bee4f01d r2 : 00000000 r1 : ffffffff r0 : ffffffff
>>[ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>>[ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 00000015
>>[ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238)
>>[ 1552.492341] Stack: (0xbec97d88 to 0xbec98000)
>>[ 1552.496728] 7d80: 80102b94 80057108 bfb95310
>>bf133ac8 bf15f4e8 bfb95310
>>[ 1552.504936] 7da0: c08bb14d ffffffff bee4f015 00000008 bfbc7500
>>bec97e08 00000000 00000041
>>[ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 00000000 bec97e3c
>>bec97de0 80102d94 80101134
>>[ 1552.521347] 7de0: bec97df8 00000000 800d982c bec96018 00000010
>>bec97e00 00000000 bec97e08
>>[ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 00000ff0 80d4e3a4
>>00000001 bee4f000 bec97e60
>>[ 1552.537758] 7e20: ffffff9c ffffff9c bec96000 00000000 bec97e5c
>>bec97e40 801033bc 80102c70
>>[ 1552.545964] 7e40: bee4f000 00000001 bec97e60 bec97f00 bec97ee4
>>bec97e60 80105dc0 80103398
>>[ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 0000000b bee4f015
>>8005992c bfb95310 bf133398
>>[ 1552.562375] 7e80: bf15f4e8 00000041 00000002 0000008a 00000000
>>00000000 600f0013 bec96000
>>[ 1552.570581] 7ea0: ffffffea bf8c1840 807b4430 80115444 801156e4
>>8011563c 00000008 00000000
>>[ 1552.578786] 7ec0: bec97f04 733fe4e0 00000001 ffffff9c 757e3810
>>bec97f40 bec97efc bec97ee8
>>[ 1552.586991] 7ee0: 80105e0c 80105d68 00000000 bc950fe0 bec97f2c
>>bec97f00 800faf64 80105df4
>>[ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0
>>733fe61c 000000c3 8000f504
>>[ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4
>>bec97f40 800fb71c 800fafc4
>>[ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c
>>000000c3 bec97f84 bec97f68
>>[ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c
>>000000c3 bec97f94 bec97f88
>>[ 1552.628019] 7f80: 80057110 80056f18 00000000 bec97f98 8000f458
>>733fe550 00000000 bec97fa8
>>[ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810
>>733fe4e0 733fe550 00000003
>>[ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 000000c3 00000000
>>00000002 733fe92c 00000200
>>[ 1552.652636] 7fe0: 000000c3 733fe4d8 7579b7e5 7572e276 200f0030
>>757e3810 bfffd821 bfffdc21
>>[ 1552.660828] Backtrace:
>>[ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>]
>>(path_lookupat+0x130/0x728)
>>[ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from
>>[<801033bc>] (filename_lookup.isra.40+0x30/0x70)
>>[ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from
>>[<80105dc0>] (user_path_at_empty+0x64/0x8c)
>>[ 1552.691361] r7:bec97f00 r6:bec97e60 r5:00000001 r4:bee4f000
>>[ 1552.697163] [<80105d5c>] (user_path_at_empty+0x0/0x8c) from
>>[<80105e0c>] (user_path_at+0x24/0x2c)
>>[ 1552.706053] r8:bec97f40 r7:757e3810 r6:ffffff9c r5:00000001 r4:733fe4e0
>>[ 1552.712927] [<80105de8>] (user_path_at+0x0/0x2c) from [<800faf64>]
>>(vfs_fstatat+0x54/0xa8)
>>[ 1552.721232] [<800faf10>] (vfs_fstatat+0x0/0xa8) from [<800fafe0>]
>>(vfs_stat+0x28/0x2c)
>>[ 1552.729167] r8:8000f504 r7:000000c3 r6:733fe61c r5:733ff8f0 r4:733fe4e0
>>[ 1552.736031] [<800fafb8>] (vfs_stat+0x0/0x2c) from [<800fb71c>]
>>(SyS_stat64+0x24/0x40)
>>[ 1552.743902] [<800fb6f8>] (SyS_stat64+0x0/0x40) from [<8000f280>]
>>(ret_fast_syscall+0x0/0x48)
>>[ 1552.752359] r4:733fe550
>>[ 1552.754946] Code: eb00352d e3500000 e50b0038 0a000080 (e5903038)
>>[ 1552.761270] ---[ end trace 02679086a39365e8 ]---
>>[ 1552.765968] Kernel panic - not syncing: Fatal exception
>>
>>_______________________________________________
>>linux-arm-kernel mailing list
>>linux-arm-kernel at lists.infradead.org
>>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: walimis @ 2014-01-23 3:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYO-k0isyOvYtRMDQoSD+QrrifzLmpMZVG9tN_cfOX5Dcw@mail.gmail.com>
On Wed, Jan 22, 2014 at 07:28:55PM -0800, John Tobias wrote:
>Hi Liming,
>
>Yes, I am using 4.8.1. I switched back to 4.7.3 and will test it again
>if I can re-produce it.
Hi,
Or you can use the latest linaro 4.8.x toolchain, which has been applied that patch:
http://releases.linaro.org/13.12/components/toolchain/binaries/
Please select this one to try:
gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux.tar.bz2
Liming Wang
>
>Regards,
>
>john
>
>On Wed, Jan 22, 2014 at 7:01 PM, walimis <walimisdev@gmail.com> wrote:
>> On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote:
>>>Hello all,
>>>
>>>I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in
>>>eMMC running SDR50.
>>>Is anyone here encountered these problem and if there's any existing
>>>patch that I can get?.
>> hi,
>>
>> Do you use gcc 4.8.1? If so, maybe you should look at following link
>> to see whether it's a similar issue.
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
>>
>> Liming Wang
>>
>>>
>>>Regards,
>>>
>>>john
>>>
>>>[ 1552.394899] Unable to handle kernel NULL pointer dereference at
>>>virtual address 00000037
>>>[ 1552.403034] pgd = beef4000
>>>[ 1552.405855] [00000037] *pgd=bef60831, *pte=00000000, *ppte=00000000
>>>[ 1552.412245] Internal error: Oops: 17 [#1] ARM
>>>[ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O)
>>>[ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O 3.13.0-rc1 #7
>>>[ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000
>>>[ 1552.434844] PC is at lookup_fast+0x5c/0x318
>>>[ 1552.439067] LR is at mark_held_locks+0x78/0x13c
>>>[ 1552.443622] pc : [<80101184>] lr : [<80056e48>] psr: a00f0013
>>>[ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc
>>>[ 1552.455124] r10: 00000000 r9 : bec97e08 r8 : 80102d94
>>>[ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00
>>>[ 1552.466918] r3 : bee4f01d r2 : 00000000 r1 : ffffffff r0 : ffffffff
>>>[ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>>>[ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 00000015
>>>[ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238)
>>>[ 1552.492341] Stack: (0xbec97d88 to 0xbec98000)
>>>[ 1552.496728] 7d80: 80102b94 80057108 bfb95310
>>>bf133ac8 bf15f4e8 bfb95310
>>>[ 1552.504936] 7da0: c08bb14d ffffffff bee4f015 00000008 bfbc7500
>>>bec97e08 00000000 00000041
>>>[ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 00000000 bec97e3c
>>>bec97de0 80102d94 80101134
>>>[ 1552.521347] 7de0: bec97df8 00000000 800d982c bec96018 00000010
>>>bec97e00 00000000 bec97e08
>>>[ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 00000ff0 80d4e3a4
>>>00000001 bee4f000 bec97e60
>>>[ 1552.537758] 7e20: ffffff9c ffffff9c bec96000 00000000 bec97e5c
>>>bec97e40 801033bc 80102c70
>>>[ 1552.545964] 7e40: bee4f000 00000001 bec97e60 bec97f00 bec97ee4
>>>bec97e60 80105dc0 80103398
>>>[ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 0000000b bee4f015
>>>8005992c bfb95310 bf133398
>>>[ 1552.562375] 7e80: bf15f4e8 00000041 00000002 0000008a 00000000
>>>00000000 600f0013 bec96000
>>>[ 1552.570581] 7ea0: ffffffea bf8c1840 807b4430 80115444 801156e4
>>>8011563c 00000008 00000000
>>>[ 1552.578786] 7ec0: bec97f04 733fe4e0 00000001 ffffff9c 757e3810
>>>bec97f40 bec97efc bec97ee8
>>>[ 1552.586991] 7ee0: 80105e0c 80105d68 00000000 bc950fe0 bec97f2c
>>>bec97f00 800faf64 80105df4
>>>[ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0
>>>733fe61c 000000c3 8000f504
>>>[ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4
>>>bec97f40 800fb71c 800fafc4
>>>[ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c
>>>000000c3 bec97f84 bec97f68
>>>[ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c
>>>000000c3 bec97f94 bec97f88
>>>[ 1552.628019] 7f80: 80057110 80056f18 00000000 bec97f98 8000f458
>>>733fe550 00000000 bec97fa8
>>>[ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810
>>>733fe4e0 733fe550 00000003
>>>[ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 000000c3 00000000
>>>00000002 733fe92c 00000200
>>>[ 1552.652636] 7fe0: 000000c3 733fe4d8 7579b7e5 7572e276 200f0030
>>>757e3810 bfffd821 bfffdc21
>>>[ 1552.660828] Backtrace:
>>>[ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>]
>>>(path_lookupat+0x130/0x728)
>>>[ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from
>>>[<801033bc>] (filename_lookup.isra.40+0x30/0x70)
>>>[ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from
>>>[<80105dc0>] (user_path_at_empty+0x64/0x8c)
>>>[ 1552.691361] r7:bec97f00 r6:bec97e60 r5:00000001 r4:bee4f000
>>>[ 1552.697163] [<80105d5c>] (user_path_at_empty+0x0/0x8c) from
>>>[<80105e0c>] (user_path_at+0x24/0x2c)
>>>[ 1552.706053] r8:bec97f40 r7:757e3810 r6:ffffff9c r5:00000001 r4:733fe4e0
>>>[ 1552.712927] [<80105de8>] (user_path_at+0x0/0x2c) from [<800faf64>]
>>>(vfs_fstatat+0x54/0xa8)
>>>[ 1552.721232] [<800faf10>] (vfs_fstatat+0x0/0xa8) from [<800fafe0>]
>>>(vfs_stat+0x28/0x2c)
>>>[ 1552.729167] r8:8000f504 r7:000000c3 r6:733fe61c r5:733ff8f0 r4:733fe4e0
>>>[ 1552.736031] [<800fafb8>] (vfs_stat+0x0/0x2c) from [<800fb71c>]
>>>(SyS_stat64+0x24/0x40)
>>>[ 1552.743902] [<800fb6f8>] (SyS_stat64+0x0/0x40) from [<8000f280>]
>>>(ret_fast_syscall+0x0/0x48)
>>>[ 1552.752359] r4:733fe550
>>>[ 1552.754946] Code: eb00352d e3500000 e50b0038 0a000080 (e5903038)
>>>[ 1552.761270] ---[ end trace 02679086a39365e8 ]---
>>>[ 1552.765968] Kernel panic - not syncing: Fatal exception
>>>
>>>_______________________________________________
>>>linux-arm-kernel mailing list
>>>linux-arm-kernel at lists.infradead.org
>>>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: John Tobias @ 2014-01-23 4:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123034644.GD18520@pek-lwang0-d1>
Thanks!
I will try it tomorrow.
Regards,
John
Sent from my iPhone
> On Jan 22, 2014, at 7:46 PM, walimis <walimisdev@gmail.com> wrote:
>
>> On Wed, Jan 22, 2014 at 07:28:55PM -0800, John Tobias wrote:
>> Hi Liming,
>>
>> Yes, I am using 4.8.1. I switched back to 4.7.3 and will test it again
>> if I can re-produce it.
>
> Hi,
>
> Or you can use the latest linaro 4.8.x toolchain, which has been applied that patch:
>
> http://releases.linaro.org/13.12/components/toolchain/binaries/
>
> Please select this one to try:
>
> gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux.tar.bz2
>
> Liming Wang
>>
>> Regards,
>>
>> john
>>
>>> On Wed, Jan 22, 2014 at 7:01 PM, walimis <walimisdev@gmail.com> wrote:
>>>> On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote:
>>>> Hello all,
>>>>
>>>> I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in
>>>> eMMC running SDR50.
>>>> Is anyone here encountered these problem and if there's any existing
>>>> patch that I can get?.
>>> hi,
>>>
>>> Do you use gcc 4.8.1? If so, maybe you should look at following link
>>> to see whether it's a similar issue.
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
>>>
>>> Liming Wang
>>>
>>>>
>>>> Regards,
>>>>
>>>> john
>>>>
>>>> [ 1552.394899] Unable to handle kernel NULL pointer dereference at
>>>> virtual address 00000037
>>>> [ 1552.403034] pgd = beef4000
>>>> [ 1552.405855] [00000037] *pgd=bef60831, *pte=00000000, *ppte=00000000
>>>> [ 1552.412245] Internal error: Oops: 17 [#1] ARM
>>>> [ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O)
>>>> [ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O 3.13.0-rc1 #7
>>>> [ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000
>>>> [ 1552.434844] PC is at lookup_fast+0x5c/0x318
>>>> [ 1552.439067] LR is at mark_held_locks+0x78/0x13c
>>>> [ 1552.443622] pc : [<80101184>] lr : [<80056e48>] psr: a00f0013
>>>> [ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc
>>>> [ 1552.455124] r10: 00000000 r9 : bec97e08 r8 : 80102d94
>>>> [ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00
>>>> [ 1552.466918] r3 : bee4f01d r2 : 00000000 r1 : ffffffff r0 : ffffffff
>>>> [ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>>>> [ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 00000015
>>>> [ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238)
>>>> [ 1552.492341] Stack: (0xbec97d88 to 0xbec98000)
>>>> [ 1552.496728] 7d80: 80102b94 80057108 bfb95310
>>>> bf133ac8 bf15f4e8 bfb95310
>>>> [ 1552.504936] 7da0: c08bb14d ffffffff bee4f015 00000008 bfbc7500
>>>> bec97e08 00000000 00000041
>>>> [ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 00000000 bec97e3c
>>>> bec97de0 80102d94 80101134
>>>> [ 1552.521347] 7de0: bec97df8 00000000 800d982c bec96018 00000010
>>>> bec97e00 00000000 bec97e08
>>>> [ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 00000ff0 80d4e3a4
>>>> 00000001 bee4f000 bec97e60
>>>> [ 1552.537758] 7e20: ffffff9c ffffff9c bec96000 00000000 bec97e5c
>>>> bec97e40 801033bc 80102c70
>>>> [ 1552.545964] 7e40: bee4f000 00000001 bec97e60 bec97f00 bec97ee4
>>>> bec97e60 80105dc0 80103398
>>>> [ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 0000000b bee4f015
>>>> 8005992c bfb95310 bf133398
>>>> [ 1552.562375] 7e80: bf15f4e8 00000041 00000002 0000008a 00000000
>>>> 00000000 600f0013 bec96000
>>>> [ 1552.570581] 7ea0: ffffffea bf8c1840 807b4430 80115444 801156e4
>>>> 8011563c 00000008 00000000
>>>> [ 1552.578786] 7ec0: bec97f04 733fe4e0 00000001 ffffff9c 757e3810
>>>> bec97f40 bec97efc bec97ee8
>>>> [ 1552.586991] 7ee0: 80105e0c 80105d68 00000000 bc950fe0 bec97f2c
>>>> bec97f00 800faf64 80105df4
>>>> [ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0
>>>> 733fe61c 000000c3 8000f504
>>>> [ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4
>>>> bec97f40 800fb71c 800fafc4
>>>> [ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c
>>>> 000000c3 bec97f84 bec97f68
>>>> [ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c
>>>> 000000c3 bec97f94 bec97f88
>>>> [ 1552.628019] 7f80: 80057110 80056f18 00000000 bec97f98 8000f458
>>>> 733fe550 00000000 bec97fa8
>>>> [ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810
>>>> 733fe4e0 733fe550 00000003
>>>> [ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 000000c3 00000000
>>>> 00000002 733fe92c 00000200
>>>> [ 1552.652636] 7fe0: 000000c3 733fe4d8 7579b7e5 7572e276 200f0030
>>>> 757e3810 bfffd821 bfffdc21
>>>> [ 1552.660828] Backtrace:
>>>> [ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>]
>>>> (path_lookupat+0x130/0x728)
>>>> [ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from
>>>> [<801033bc>] (filename_lookup.isra.40+0x30/0x70)
>>>> [ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from
>>>> [<80105dc0>] (user_path_at_empty+0x64/0x8c)
>>>> [ 1552.691361] r7:bec97f00 r6:bec97e60 r5:00000001 r4:bee4f000
>>>> [ 1552.697163] [<80105d5c>] (user_path_at_empty+0x0/0x8c) from
>>>> [<80105e0c>] (user_path_at+0x24/0x2c)
>>>> [ 1552.706053] r8:bec97f40 r7:757e3810 r6:ffffff9c r5:00000001 r4:733fe4e0
>>>> [ 1552.712927] [<80105de8>] (user_path_at+0x0/0x2c) from [<800faf64>]
>>>> (vfs_fstatat+0x54/0xa8)
>>>> [ 1552.721232] [<800faf10>] (vfs_fstatat+0x0/0xa8) from [<800fafe0>]
>>>> (vfs_stat+0x28/0x2c)
>>>> [ 1552.729167] r8:8000f504 r7:000000c3 r6:733fe61c r5:733ff8f0 r4:733fe4e0
>>>> [ 1552.736031] [<800fafb8>] (vfs_stat+0x0/0x2c) from [<800fb71c>]
>>>> (SyS_stat64+0x24/0x40)
>>>> [ 1552.743902] [<800fb6f8>] (SyS_stat64+0x0/0x40) from [<8000f280>]
>>>> (ret_fast_syscall+0x0/0x48)
>>>> [ 1552.752359] r4:733fe550
>>>> [ 1552.754946] Code: eb00352d e3500000 e50b0038 0a000080 (e5903038)
>>>> [ 1552.761270] ---[ end trace 02679086a39365e8 ]---
>>>> [ 1552.765968] Kernel panic - not syncing: Fatal exception
>>>>
>>>> _______________________________________________
>>>> 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/6] arm64: Add macros to manage processor debug state
From: Vijay Kilari @ 2014-01-23 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122173117.GJ14108@mudshark.cambridge.arm.com>
On Wed, Jan 22, 2014 at 11:01 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hello,
>
> On Wed, Jan 22, 2014 at 02:42:48PM +0000, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>
>> Add macros to enable and disable to manage PSTATE.D
>> for debugging. The macros local_dbg_save and local_dbg_restore
>> are moved to irqflags.h file
>>
>> KGDB boot tests fail because of PSTATE.D is masked.
>> unmask it for debugging support
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>> ---
>> arch/arm64/include/asm/debug-monitors.h | 18 ++----------------
>> arch/arm64/include/asm/irqflags.h | 22 ++++++++++++++++++++++
>> arch/arm64/kernel/debug-monitors.c | 3 ++-
>> 3 files changed, 26 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
>> index 6231479..bc48880 100644
>> --- a/arch/arm64/include/asm/debug-monitors.h
>> +++ b/arch/arm64/include/asm/debug-monitors.h
>> @@ -43,22 +43,8 @@ enum debug_el {
>> #ifndef __ASSEMBLY__
>> struct task_struct;
>>
>> -#define local_dbg_save(flags) \
>> - do { \
>> - typecheck(unsigned long, flags); \
>> - asm volatile( \
>> - "mrs %0, daif // local_dbg_save\n" \
>> - "msr daifset, #8" \
>> - : "=r" (flags) : : "memory"); \
>> - } while (0)
>> -
>> -#define local_dbg_restore(flags) \
>> - do { \
>> - typecheck(unsigned long, flags); \
>> - asm volatile( \
>> - "msr daif, %0 // local_dbg_restore\n" \
>> - : : "r" (flags) : "memory"); \
>> - } while (0)
>> +#define local_dbg_enable() asm("msr daifclr, #8" : : : "memory")
>> +#define local_dbg_disable() asm("msr daifset, #8" : : : "memory")
>
> Any reason not to move these to irqflags.h too?
Can me moved to irqflags.h file
>
>> #define DBG_ARCH_ID_RESERVED 0 /* In case of ptrace ABI updates. */
>>
>> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
>> index b2fcfbc..f163b11 100644
>> --- a/arch/arm64/include/asm/irqflags.h
>> +++ b/arch/arm64/include/asm/irqflags.h
>> @@ -90,5 +90,27 @@ static inline int arch_irqs_disabled_flags(unsigned long flags)
>> return flags & PSR_I_BIT;
>> }
>>
>> +/*
>> + * save and restore debug state
>> + */
>> +static inline unsigned long local_dbg_save(void)
>> +{
>> + unsigned long flags;
>> + asm volatile(
>> + "mrs %0, daif // local_dbg_save"
>> + "msr daifset, #8"
>> + : "=r" (flags) : : "memory");
>> + return flags;
>> +}
>> +
>> +static inline void local_dbg_restore(unsigned long flags)
>> +{
>> + asm volatile(
>> + "msr daif, %0 // local_dbg_restore"
>> + :
>> + : "r" (flags)
>> + : "memory");
>> +}
>> +
>> #endif
>> #endif
>> diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
>> index 23586bd..774ad04 100644
>> --- a/arch/arm64/kernel/debug-monitors.c
>> +++ b/arch/arm64/kernel/debug-monitors.c
>> @@ -51,7 +51,7 @@ u8 debug_monitors_arch(void)
>> static void mdscr_write(u32 mdscr)
>> {
>> unsigned long flags;
>> - local_dbg_save(flags);
>> + flags = local_dbg_save();
>
> Why are you changing the API? This is now pointlessly different to irqs.
To be in line with arch_local_irq_save & arch_local_save_flags in irqflags.h,
I moved this macros into functions and accordingly changed the caller.
I could not find any code using this local_dbg_{save, restore} except
from debug-monitors.c file
If required, I can think of renaming local_dbg_{save,restore} as
local_dbg_{save,restore}_flags
>
> Will
^ permalink raw reply
* [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
From: swaminathan @ 2014-01-23 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388400186-22045-1-git-send-email-amit.grover@samsung.com>
Hi All,
Is there any review Comments for the patch "[PATCH] [media] s5p-mfc: Add
Horizontal and Vertical search range for Video Macro Blocks"
posted on 30-Dec-2013 ?
Regards,
Swaminathan
--------------------------------------------------
From: "Amit Grover" <amit.grover@samsung.com>
Sent: Monday, December 30, 2013 4:13 PM
To: <m.chehab@samsung.com>; <linux-media@vger.kernel.org>;
<linux-doc@vger.kernel.org>; <linux-kernel@vger.kernel.org>;
<linux-arm-kernel@lists.infradead.org>; <linux-samsung-soc@vger.kernel.org>;
<rob@landley.net>; <kyungmin.park@samsung.com>; <k.debski@samsung.com>;
<jtp.park@samsung.com>
Cc: <hans.verkuil@cisco.com>; <andrew.smirnov@gmail.com>;
<s.nawrocki@samsung.com>; <arun.kk@samsung.com>; <anatol.pomozov@gmail.com>;
<jmccrohan@gmail.com>; <austin.lobo@samsung.com>; "Swami Nathan"
<swaminath.p@samsung.com>
Subject: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range
for Video Macro Blocks
> This patch adds Controls to set Horizontal and Vertical search range
> for Motion Estimation block for Samsung MFC video Encoders.
>
> Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
> Signed-off-by: Amit Grover <amit.grover@samsung.com>
> ---
> Documentation/DocBook/media/v4l/controls.xml | 14 +++++++++++++
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24
> +++++++++++++++++++++++
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 ++------
> drivers/media/v4l2-core/v4l2-ctrls.c | 14 +++++++++++++
> include/uapi/linux/v4l2-controls.h | 2 ++
> 6 files changed, 58 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml
> index 7a3b49b..70a0f6f 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -2258,6 +2258,20 @@ Applicable to the MPEG1, MPEG2, MPEG4
> encoders.</entry>
> VBV buffer control.</entry>
> </row>
>
> + <row><entry></entry></row>
> + <row id="v4l2-mpeg-video-horz-search-range">
> + <entry
> spanname="id"><constant>V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE</constant> </entry>
> + <entry>integer</entry>
> + </row><row><entry spanname="descr">Sets the Horizontal search
> range for Video Macro blocks.</entry>
> + </row>
> +
> + <row><entry></entry></row>
> + <row id="v4l2-mpeg-video-vert-search-range">
> + <entry
> spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE</constant> </entry>
> + <entry>integer</entry>
> + </row><row><entry spanname="descr">Sets the Vertical search range
> for Video Macro blocks.</entry>
> + </row>
> +
> <row><entry></entry></row>
> <row>
> <entry
> spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 6920b54..f2c13c3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
> struct s5p_mfc_enc_params {
> u16 width;
> u16 height;
> + u32 horz_range;
> + u32 vert_range;
>
> u16 gop_size;
> enum v4l2_mpeg_video_multi_slice_mode slice_mode;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 4ff3b6c..a02e7b8 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
> .default_value = 0,
> },
> {
> + .id = V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "horizontal search range of video macro block",
> + .minimum = 16,
> + .maximum = 128,
> + .step = 16,
> + .default_value = 32,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "vertical search range of video macro block",
> + .minimum = 16,
> + .maximum = 128,
> + .step = 16,
> + .default_value = 32,
> + },
> + {
> .id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
> .type = V4L2_CTRL_TYPE_INTEGER,
> .minimum = 0,
> @@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl
> *ctrl)
> case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
> p->vbv_size = ctrl->val;
> break;
> + case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE:
> + p->horz_range = ctrl->val;
> + break;
> + case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE:
> + p->vert_range = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
> p->codec.h264.cpb_size = ctrl->val;
> break;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 461358c..47e1807 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -727,14 +727,10 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx
> *ctx)
> WRITEL(reg, S5P_FIMV_E_RC_CONFIG_V6);
>
> /* setting for MV range [16, 256] */
> - reg = 0;
> - reg &= ~(0x3FFF);
> - reg = 256;
> + reg = (p->horz_range & 0x3fff); /* conditional check in app */
> WRITEL(reg, S5P_FIMV_E_MV_HOR_RANGE_V6);
>
> - reg = 0;
> - reg &= ~(0x3FFF);
> - reg = 256;
> + reg = (p->vert_range & 0x3fff); /* conditional check in app */
> WRITEL(reg, S5P_FIMV_E_MV_VER_RANGE_V6);
>
> WRITEL(0x0, S5P_FIMV_E_FRAME_INSERTION_V6);
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index fb46790..7cf23d5 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video Decoder PTS";
> case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video Decoder Frame Count";
> case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial Delay for VBV
> Control";
> + case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE: return "hor search range of
> video MB";
> + case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE: return "vert search range of
> video MB";
> case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat Sequence
> Header";
>
> /* VPX controls */
> @@ -905,6 +907,18 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type,
> *min = 0;
> *max = *step = 1;
> break;
> + case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *min = 16;
> + *max = 128;
> + *step = 16;
> + break;
> + case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *min = 16;
> + *max = 128;
> + *step = 16;
> + break;
> case V4L2_CID_PAN_RESET:
> case V4L2_CID_TILT_RESET:
> case V4L2_CID_FLASH_STROBE:
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index 1666aab..bcce536 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -372,6 +372,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
> #define V4L2_CID_MPEG_VIDEO_DEC_FRAME (V4L2_CID_MPEG_BASE+224)
> #define V4L2_CID_MPEG_VIDEO_VBV_DELAY (V4L2_CID_MPEG_BASE+225)
> #define V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER (V4L2_CID_MPEG_BASE+226)
> +#define V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE (V4L2_CID_MPEG_BASE+227)
> +#define V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
>
> #define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP (V4L2_CID_MPEG_BASE+300)
> #define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP (V4L2_CID_MPEG_BASE+301)
> --
> 1.7.9.5
>
^ permalink raw reply
* Kconfig errors
From: Prabhakar Lad @ 2014-01-23 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122122653.GA15937@n2100.arm.linux.org.uk>
On Wed, Jan 22, 2014 at 5:56 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 22, 2014 at 05:54:29PM +0530, Prabhakar Lad wrote:
>> Hi Russell,
>>
>> On Fri, Jan 17, 2014 at 1:07 PM, Prabhakar Lad
>> <prabhakar.csengg@gmail.com> wrote:
>> > Hi,
>> >
>> > On Linux-next branch I see following errors for davinci_all_defconfig
>> > & da8xx_omapl_defconfig configs,
>> >
>> > arch/arm/Kconfig:1966:error: recursive dependency detected!
>> > arch/arm/Kconfig:1966: symbol ZBOOT_ROM depends on AUTO_ZRELADDR
>> > arch/arm/Kconfig:2154: symbol AUTO_ZRELADDR is selected by ZBOOT_ROM
>> > #
>> > # configuration written to .config
>> > #
>> >
>> I am seeing this errors on linux-next, with your recent patch,
>> "[PATCH] Fix select-induced Kconfig warning for ZBOOT_ROM"
>> and strangely I see that AUTO_ZRELADDR doesnt select ZBOOT_ROM
>> but still an error.
>>
>> Note: For the davinci configs CONFIG_AUTO_ZRELADDR is not set and
>> CONFIG_ZBOOT_ROM_TEXT=0x0, CONFIG_ZBOOT_ROM_BSS=0x0
>
> I've killed off the "select AUTO_ZRELADDR if !ZBOOT_ROM" in the IMX
> Kconfig now, so when linux-next picks up my tree, that should be gone.
>
Thanks that helps.
Regards,
--Prabhakar Lad
^ permalink raw reply
* [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
From: Prabhakar Lad @ 2014-01-23 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DA6097ED98694425932A6AF93513371A@sisodomain.com>
Hi Swaminathan,
On Thu, Jan 23, 2014 at 10:49 AM, swaminathan <swaminath.p@samsung.com> wrote:
> Hi All,
> Is there any review Comments for the patch "[PATCH] [media] s5p-mfc: Add
> Horizontal and Vertical search range for Video Macro Blocks"
> posted on 30-Dec-2013 ?
>
>
Just a side note, please don?t top post and always reply as plain text.
[Snip]
> Subject: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range
> for Video Macro Blocks
>
>
>> This patch adds Controls to set Horizontal and Vertical search range
>> for Motion Estimation block for Samsung MFC video Encoders.
>>
>> Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
>> Signed-off-by: Amit Grover <amit.grover@samsung.com>
>> ---
>> Documentation/DocBook/media/v4l/controls.xml | 14 +++++++++++++
>> drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
>> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24
>> +++++++++++++++++++++++
>> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 ++------
>> drivers/media/v4l2-core/v4l2-ctrls.c | 14 +++++++++++++
>> include/uapi/linux/v4l2-controls.h | 2 ++
>> 6 files changed, 58 insertions(+), 6 deletions(-)
>>
This patch from the outset looks OK, but you need to split up
into two, first adding a v4l control and second one using it up in the driver.
Regards,
--Prabhakar Lad
^ permalink raw reply
* [PATCH] arm: vt8500: Fix gpio mux setup in vt8500_init()
From: Tony Prisk @ 2014-01-23 6:28 UTC (permalink / raw)
To: linux-arm-kernel
With the switch to a pinctrl driver, and the dropping of the gpio driver,
the code in vt8500_init now always fails, and drops back to LEGACY mode.
Update the gpio mux init code, and removing the #ifdef's and the LEGACY
mode fallback.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
arch/arm/mach-vt8500/vt8500.c | 91 ++++++++++++++---------------------------
1 file changed, 30 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 4a73464..fe5243e 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -32,9 +32,6 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
-#define LEGACY_GPIO_BASE 0xD8110000
-#define LEGACY_PMC_BASE 0xD8130000
-
/* Registers in GPIO Controller */
#define VT8500_GPIO_MUX_REG 0x200
@@ -75,89 +72,61 @@ static void vt8500_power_off(void)
void __init vt8500_init(void)
{
struct device_node *np;
-#if defined(CONFIG_FB_VT8500) || defined(CONFIG_FB_WM8505)
struct device_node *fb;
- void __iomem *gpio_base;
-#endif
+ void __iomem *base;
-#ifdef CONFIG_FB_VT8500
fb = of_find_compatible_node(NULL, NULL, "via,vt8500-fb");
if (fb) {
- np = of_find_compatible_node(NULL, NULL, "via,vt8500-gpio");
- if (np) {
- gpio_base = of_iomap(np, 0);
-
- if (!gpio_base)
- pr_err("%s: of_iomap(gpio_mux) failed\n",
- __func__);
+ np = of_find_compatible_node(NULL, NULL, "via,vt8500-pinctrl");
+ if (!np) {
+ pr_err("pinctrl node required for framebuffer\n");
+ BUG();
+ }
- of_node_put(np);
+ base = of_iomap(np, 0);
+ if (base) {
+ writel(readl(base + VT8500_GPIO_MUX_REG) | 1,
+ base + VT8500_GPIO_MUX_REG);
+ iounmap(base);
} else {
- gpio_base = ioremap(LEGACY_GPIO_BASE, 0x1000);
- if (!gpio_base)
- pr_err("%s: ioremap(legacy_gpio_mux) failed\n",
- __func__);
+ pr_err("%s: of_iomap(gpio_mux) failed\n", __func__);
}
- if (gpio_base) {
- writel(readl(gpio_base + VT8500_GPIO_MUX_REG) | 1,
- gpio_base + VT8500_GPIO_MUX_REG);
- iounmap(gpio_base);
- } else
- pr_err("%s: Could not remap GPIO mux\n", __func__);
+ of_node_put(np);
of_node_put(fb);
}
-#endif
-#ifdef CONFIG_FB_WM8505
fb = of_find_compatible_node(NULL, NULL, "wm,wm8505-fb");
if (fb) {
- np = of_find_compatible_node(NULL, NULL, "wm,wm8505-gpio");
- if (!np)
- np = of_find_compatible_node(NULL, NULL,
- "wm,wm8650-gpio");
- if (np) {
- gpio_base = of_iomap(np, 0);
-
- if (!gpio_base)
- pr_err("%s: of_iomap(gpio_mux) failed\n",
- __func__);
-
- of_node_put(np);
+ np = of_find_compatible_node(NULL, NULL, "wm,prizm-pinctrl");
+ if (!np) {
+ pr_err("pinctrl node required for framebuffer\n");
+ BUG();
+ }
+
+ base = of_iomap(np, 0);
+ if (base) {
+ writel(readl(base + VT8500_GPIO_MUX_REG) |
+ 0x80000000, base + VT8500_GPIO_MUX_REG);
+ iounmap(base);
} else {
- gpio_base = ioremap(LEGACY_GPIO_BASE, 0x1000);
- if (!gpio_base)
- pr_err("%s: ioremap(legacy_gpio_mux) failed\n",
- __func__);
+ pr_err("%s: of_iomap(gpio_mux) failed\n", __func__);
}
- if (gpio_base) {
- writel(readl(gpio_base + VT8500_GPIO_MUX_REG) |
- 0x80000000, gpio_base + VT8500_GPIO_MUX_REG);
- iounmap(gpio_base);
- } else
- pr_err("%s: Could not remap GPIO mux\n", __func__);
+ of_node_put(np);
of_node_put(fb);
}
-#endif
np = of_find_compatible_node(NULL, NULL, "via,vt8500-pmc");
if (np) {
pmc_base = of_iomap(np, 0);
-
- if (!pmc_base)
- pr_err("%s:of_iomap(pmc) failed\n", __func__);
+ if (pmc_base)
+ pm_power_off = &vt8500_power_off;
+ else
+ pr_err("%s: of_iomap(pmc) failed\n", __func__);
of_node_put(np);
- } else {
- pmc_base = ioremap(LEGACY_PMC_BASE, 0x1000);
- if (!pmc_base)
- pr_err("%s:ioremap(power_off) failed\n", __func__);
}
- if (pmc_base)
- pm_power_off = &vt8500_power_off;
- else
- pr_err("%s: PMC Hibernation register could not be remapped, not enabling power off!\n", __func__);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] serial: vt8500: Add missing binding document for arch-vt8500 serial driver.
From: Tony Prisk @ 2014-01-23 6:30 UTC (permalink / raw)
To: linux-arm-kernel
The binding document for the vt8500/wm8xxx SoC UART driver is missing.
This patch adds the binding document.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
.../devicetree/bindings/serial/vt8500-uart.txt | 26 ++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/vt8500-uart.txt
diff --git a/Documentation/devicetree/bindings/serial/vt8500-uart.txt b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
new file mode 100644
index 0000000..795c393
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
@@ -0,0 +1,26 @@
+* VIA VT8500 and WonderMedia WM8xxx UART Controller
+
+Required properties:
+- compatible: should be "via,vt8500-uart"
+
+- reg: base physical address of the controller and length of memory mapped
+ region.
+
+- interrupts: hardware interrupt number
+
+- clocks: shall be the input parent clock phandle for the clock. This should
+ be the 24Mhz reference clock.
+
+Aliases may be defined to ensure the correct ordering of the uarts.
+
+Example:
+ aliases {
+ serial0 = &uart0;
+ };
+
+ uart0: serial at d8200000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8200000 0x1040>;
+ interrupts = <32>;
+ clocks = <&clkuart0>;
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH] vt8500: pinctrl: Change devicetree data parsing
From: Tony Prisk @ 2014-01-23 6:31 UTC (permalink / raw)
To: linux-arm-kernel
Due to an assumption in the VT8500 pinctrl driver, the value passed
from devicetree for 'wm,pull' was not explicitly translated before
being passed to pinconf.
With changes to 'enum pin_config_param', PIN_CONFIG_BIAS_PULL_(UP/DOWN)
no longer map 1-to-1 with the expected values in devicetree.
This patch adds a small translation between the devicetree values (0..2)
and the enum pin_config_param equivalent values.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/pinctrl/vt8500/pinctrl-wmt.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c b/drivers/pinctrl/vt8500/pinctrl-wmt.c
index 39aec08..fa4fdbd 100644
--- a/drivers/pinctrl/vt8500/pinctrl-wmt.c
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -276,6 +276,17 @@ static int wmt_pctl_dt_node_to_map_pull(struct wmt_pinctrl_data *data,
if (!configs)
return -ENOMEM;
+ switch (pull) {
+ case 0:
+ pull = PIN_CONFIG_BIAS_DISABLE;
+ break;
+ case 1:
+ pull = PIN_CONFIG_BIAS_PULL_DOWN;
+ break;
+ case 2:
+ pull = PIN_CONFIG_BIAS_PULL_UP;
+ break;
+ }
configs[0] = pull;
map->type = PIN_MAP_TYPE_CONFIGS_PIN;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] MAINTAINERS: vt8500: Update maintained files for arch/vt8500
From: Tony Prisk @ 2014-01-23 6:43 UTC (permalink / raw)
To: linux-arm-kernel
Removed maintainership of the ehci-platform.c and uhci-platform.c
drivers. These drivers are not solely used by arch-vt8500 anymore,
and are captured under Alan Stern's 'USB EHCI DRIVER' and
'USB UHCI DRIVER' wildcards.
Add maintainership for the VT8500's clock, irq and pinctrl drivers
which were added/migrated quite some time ago.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
MAINTAINERS | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6a6e4ac..ac26897 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1341,14 +1341,15 @@ M: Tony Prisk <linux@prisktech.co.nz>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-vt8500/
+F: drivers/clk/clk-vt8500.c
F: drivers/clocksource/vt8500_timer.c
F: drivers/i2c/busses/i2c-wmt.c
+F: drivers/irqchip/irq-vt8500.c
F: drivers/mmc/host/wmt-sdmmc.c
+F: drivers/pinctrl/vt8500/
F: drivers/pwm/pwm-vt8500.c
F: drivers/rtc/rtc-vt8500.c
F: drivers/tty/serial/vt8500_serial.c
-F: drivers/usb/host/ehci-platform.c
-F: drivers/usb/host/uhci-platform.c
F: drivers/video/vt8500lcdfb.*
F: drivers/video/wm8505fb*
F: drivers/video/wmt_ge_rops.*
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] clocksource: Remove outdated comments
From: Yijing Wang @ 2014-01-23 7:12 UTC (permalink / raw)
To: linux-arm-kernel
clocksource_register() and __clocksource_register_scale()
always return 0, so the comment is just pointless, it's
outdated, remove it.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
kernel/time/clocksource.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index ba3e502..9951575 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -779,8 +779,6 @@ EXPORT_SYMBOL_GPL(__clocksource_updatefreq_scale);
* @scale: Scale factor multiplied against freq to get clocksource hz
* @freq: clocksource frequency (cycles per second) divided by scale
*
- * Returns -EBUSY if registration fails, zero otherwise.
- *
* This *SHOULD NOT* be called directly! Please use the
* clocksource_register_hz() or clocksource_register_khz helper functions.
*/
@@ -805,7 +803,6 @@ EXPORT_SYMBOL_GPL(__clocksource_register_scale);
* clocksource_register - Used to install new clocksources
* @cs: clocksource to be registered
*
- * Returns -EBUSY if registration fails, zero otherwise.
*/
int clocksource_register(struct clocksource *cs)
{
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox