* [PATCH v6 2/7] ARM: dts: r8a7743: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-10-31 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1746536.qobnGdHRfV@wasted.cogentembedded.com>
Describe SYS-DMAC0/1 in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 6:
- refreshed the patch.
Changes in version 5:
- refreshed the patch.
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- resolved a reject;
- updated the "clocks" properties for the CPG/MSSR driver.
Changes in version 2:
- added Geert's tag.
arch/arm/boot/dts/r8a7743.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -93,6 +93,70 @@
compatible = "renesas,r8a7743-rst";
reg = <0 0xe6160000 0 0x100>;
};
+
+ dmac0: dma-controller at e6700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 219>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller at e6720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 218>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
};
/* External root clock */
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Stefan Wahren @ 2016-10-31 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031161700.GH1041@n2100.armlinux.org.uk>
> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 31. Oktober 2016 um
> 17:17 geschrieben:
>
>
> On Sat, Oct 29, 2016 at 01:44:14PM +0200, Stefan Wahren wrote:
> > unfortunately not:
> >
> > Setting: no_console_suspend not in cmdline, Debug UART wakeup source enabled
> >
> > echo mem > /sys/power/state
> >
> > Result: Able to wakeup via Debug UART
> > Expected result: Able to wakeup via Debug UART
> >
> > ---
> >
> > Setting: no_console_suspend not in cmdline, Debug UART wakeup source enabled
> >
> > echo freeze > /sys/power/state
> >
> > Result: Unable to wakeup via Debug UART (no hung task warning)
> > Expected result: Able to wakeup via Debug UART
>
> Okay - I know that certain actions are bypassed when no_console_suspend
> is set, which has detrimental effects on some ARM platforms, so it was
> worth testing - iirc, working no_console_suspend is reliant on the boot
> loader re-setting up the serial port after its lost state.
>
I also made the basic PM debugging tests with the available options for pm_test:
freezer: suspend and resume as expected
devices: suspend and resume as expected
platform: suspend and resume as expected
Since these tests use a clock to wakeup, i assume my issue is related to the
debug UART and its required components.
Btw the irqchip/irq-mxs.c doesn't implement neither the irq_set_wake or the
syscore_ops. Could this be the problem?
FWIW here are the debug outputs for "echo mem > /sys/power/state" (no hang) and
"echo freeze > /sys/power/state" (hang). I need to mention that after adding
initcall_debug to the cmdline "echo mem > /sys/power/state" the system wakeups
immediately after the suspend.
echo mem > /sys/power/state
[ 62.010376] PM: Syncing filesystems ... [ 65.607842] done.
[ 65.660964] Freezing user space processes ... (elapsed 0.007 seconds) done.
[ 65.676976] Freezing remaining freezable tasks ... (elapsed 0.003 seconds)
done.
[ 65.697881] calling mmc0:0007+ @ 93, parent: mmc0
[ 65.704356] call mmc0:0007+ returned 0 after 1532 usecs
[ 65.710605] calling snd-soc-dummy+ @ 385, parent: platform
[ 65.716472] call snd-soc-dummy+ returned 0 after 16 usecs
[ 65.722356] calling duckbill:red:status+ @ 385, parent: leds
[ 65.728360] call duckbill:red:status+ returned 0 after 22 usecs
[ 65.734417] calling duckbill:green:status+ @ 385, parent: leds
[ 65.740564] call duckbill:green:status+ returned 0 after 18 usecs
[ 65.747329] calling stmp3xxx_rtc_wdt+ @ 385, parent: 80056000.rtc
[ 65.753600] call stmp3xxx_rtc_wdt+ returned 0 after 13 usecs
[ 65.759529] calling rtc0+ @ 385, parent: 80056000.rtc
[ 65.765084] call rtc0+ returned 0 after 212 usecs
[ 65.771252] calling usb1+ @ 93, parent: ci_hdrc.0
[ 65.805743] call usb1+ returned 0 after 28753 usecs
[ 65.811994] calling ci_hdrc.0+ @ 385, parent: 80080000.usb
[ 65.819188] call ci_hdrc.0+ returned 0 after 1319 usecs
[ 65.824875] calling 800f0000.etherne:00+ @ 385, parent: 800f0000.etherne
[ 65.832856] call 800f0000.etherne:00+ returned 0 after 1072 usecs
[ 65.839345] calling Fixed MDIO bus.0+ @ 385, parent: platform
[ 65.845388] call Fixed MDIO bus.0+ returned 0 after 13 usecs
[ 65.851432] calling alarmtimer+ @ 385, parent: platform
[ 65.858186] call alarmtimer+ returned 0 after 1193 usecs
[ 65.868024] calling leds+ @ 385, parent: soc0
[ 65.872567] call leds+ returned 0 after 12 usecs
[ 65.877472] calling regulators:regulator at 0+ @ 385, parent: regulators
[ 65.884088] call regulators:regulator at 0+ returned 0 after 14 usecs
[ 65.890534] calling regulators+ @ 385, parent: soc0
[ 65.895699] call regulators+ returned 0 after 14 usecs
[ 65.900971] calling iio-hwmon+ @ 385, parent: soc0
[ 65.906096] call iio-hwmon+ returned 0 after 15 usecs
[ 65.912643] calling 800f0000.ethernet+ @ 385, parent: 80080000.ahb
[ 65.920952] call 800f0000.ethernet+ returned 0 after 1743 usecs
[ 65.927181] calling 80080000.usb+ @ 385, parent: 80080000.ahb
[ 65.933350] call 80080000.usb+ returned 0 after 243 usecs
[ 65.939063] calling 80080000.ahb+ @ 385, parent: soc0
[ 65.944289] call 80080000.ahb+ returned 0 after 14 usecs
[ 65.949867] calling 8007c000.usbphy+ @ 385, parent: 80040000.apbx
[ 65.956248] call 8007c000.usbphy+ returned 0 after 15 usecs
[ 65.961960] calling 80074000.serial+ @ 385, parent: 80040000.apbx
[ 65.968832] call 80074000.serial+ returned 0 after 472 usecs
[ 65.974888] calling 80068000.timrot+ @ 385, parent: 80040000.apbx
[ 65.981162] call 80068000.timrot+ returned 0 after 13 usecs
[ 65.987008] calling 80056000.rtc+ @ 385, parent: 80040000.apbx
[ 65.993012] call 80056000.rtc+ returned 0 after 14 usecs
[ 65.998601] calling 80040000.apbx+ @ 385, parent: 80000000.apb
[ 66.004720] call 80040000.apbx+ returned 0 after 13 usecs
[ 66.010259] calling 8002c000.ocotp+ @ 385, parent: 80000000.apbh
[ 66.016565] call 8002c000.ocotp+ returned 0 after 14 usecs
[ 66.022191] calling 80028000.dcp+ @ 385, parent: 80000000.apbh
[ 66.028322] call 80028000.dcp+ returned 0 after 13 usecs
[ 66.033833] calling 80024000.dma-apbx+ @ 385, parent: 80000000.apbh
[ 66.040396] call 80024000.dma-apbx+ returned 0 after 14 usecs
[ 66.046474] calling 80018000.pinctrl:gpio at 4+ @ 385, parent: 80018000.pinctrl
[ 66.053695] call 80018000.pinctrl:gpio at 4+ returned 0 after 15 usecs
[ 66.060303] calling 80018000.pinctrl:gpio at 3+ @ 385, parent: 80018000.pinctrl
[ 66.067640] call 80018000.pinctrl:gpio at 3+ returned 0 after 14 usecs
[ 66.074124] calling 80018000.pinctrl:gpio at 2+ @ 385, parent: 80018000.pinctrl
[ 66.081478] call 80018000.pinctrl:gpio at 2+ returned 0 after 13 usecs
[ 66.088068] calling 80018000.pinctrl:gpio at 1+ @ 385, parent: 80018000.pinctrl
[ 66.095426] call 80018000.pinctrl:gpio at 1+ returned 0 after 14 usecs
[ 66.101917] calling 80018000.pinctrl:gpio at 0+ @ 385, parent: 80018000.pinctrl
[ 66.109292] call 80018000.pinctrl:gpio at 0+ returned 0 after 14 usecs
[ 66.115828] calling 80018000.pinctrl+ @ 385, parent: 80000000.apbh
[ 66.122177] call 80018000.pinctrl+ returned 0 after 13 usecs
[ 66.128103] calling 80010000.ssp+ @ 385, parent: 80000000.apbh
[ 66.134173] call 80010000.ssp+ returned 0 after 73 usecs
[ 66.139808] calling 80004000.dma-apbh+ @ 385, parent: 80000000.apbh
[ 66.146361] call 80004000.dma-apbh+ returned 0 after 14 usecs
[ 66.152266] calling 80000000.apbh+ @ 385, parent: 80000000.apb
[ 66.158402] call 80000000.apbh+ returned 0 after 14 usecs
[ 66.163947] calling 80000000.apb+ @ 385, parent: soc0
[ 66.169297] call 80000000.apb+ returned 0 after 13 usecs
[ 66.174993] calling reg-dummy+ @ 385, parent: platform
[ 66.180303] call reg-dummy+ returned 0 after 14 usecs
[ 66.185780] PM: suspend of devices complete after 491.347 msecs
[ 66.199593] PM: late suspend of devices complete after 7.795 msecs
[ 66.213823] PM: noirq suspend of devices complete after 7.810 msecs
[ 66.220384] PM: Calling sched_clock_suspend+0x0/0x30
[ 66.225386] PM: Calling timekeeping_suspend+0x0/0x248
[ 66.225386] PM: Calling irq_gc_suspend+0x0/0x6c
[ 66.225386] PM: Calling fw_suspend+0x0/0x14
[ 66.225386] PM: Calling cpu_pm_suspend+0x0/0x18
[ 66.225386] PM: Calling cpu_pm_resume+0x0/0x10
[ 66.225386] PM: Calling irq_gc_resume+0x0/0x68
[ 66.225386] PM: Calling irq_pm_syscore_resume+0x0/0x8
[ 66.225386] PM: Calling timekeeping_resume+0x0/0x388
[ 66.225386] PM: Calling sched_clock_resume+0x0/0x50
[ 66.235681] PM: noirq resume of devices complete after 9.970 msecs
[ 66.249836] PM: early resume of devices complete after 6.354 msecs
[ 66.257903] calling reg-dummy+ @ 385, parent: platform
[ 66.263393] call reg-dummy+ returned 0 after 14 usecs
[ 66.269048] calling 80000000.apb+ @ 385, parent: soc0
[ 66.274433] call 80000000.apb+ returned 0 after 14 usecs
[ 66.279854] calling 80000000.apbh+ @ 385, parent: 80000000.apb
[ 66.285986] call 80000000.apbh+ returned 0 after 13 usecs
[ 66.291488] calling 80004000.dma-apbh+ @ 385, parent: 80000000.apbh
[ 66.298050] call 80004000.dma-apbh+ returned 0 after 13 usecs
[ 66.304032] calling 80010000.ssp+ @ 385, parent: 80000000.apbh
[ 66.310100] call 80010000.ssp+ returned 0 after 71 usecs
[ 66.315901] calling mmc0:0007+ @ 390, parent: mmc0
[ 66.322084] call mmc0:0007+ returned 0 after 1186 usecs
[ 66.327863] calling 80018000.pinctrl+ @ 385, parent: 80000000.apbh
[ 66.334390] call 80018000.pinctrl+ returned 0 after 14 usecs
[ 66.340292] calling 80018000.pinctrl:gpio at 0+ @ 385, parent: 80018000.pinctrl
[ 66.347660] call 80018000.pinctrl:gpio at 0+ returned 0 after 14 usecs
[ 66.354395] calling 80018000.pinctrl:gpio at 1+ @ 385, parent: 80018000.pinctrl
[ 66.361622] call 80018000.pinctrl:gpio at 1+ returned 0 after 13 usecs
[ 66.368166] calling 80018000.pinctrl:gpio at 2+ @ 385, parent: 80018000.pinctrl
[ 66.375520] call 80018000.pinctrl:gpio at 2+ returned 0 after 13 usecs
[ 66.381932] calling 80018000.pinctrl:gpio at 3+ @ 385, parent: 80018000.pinctrl
[ 66.389309] call 80018000.pinctrl:gpio at 3+ returned 0 after 12 usecs
[ 66.399315] calling 80018000.pinctrl:gpio at 4+ @ 385, parent: 80018000.pinctrl
[ 66.406746] call 80018000.pinctrl:gpio at 4+ returned 0 after 13 usecs
[ 66.413534] calling 80024000.dma-apbx+ @ 385, parent: 80000000.apbh
[ 66.420065] call 80024000.dma-apbx+ returned 0 after 15 usecs
[ 66.426220] calling 80028000.dcp+ @ 385, parent: 80000000.apbh
[ 66.432320] call 80028000.dcp+ returned 0 after 14 usecs
[ 66.438018] calling 8002c000.ocotp+ @ 385, parent: 80000000.apbh
[ 66.444341] call 8002c000.ocotp+ returned 0 after 14 usecs
[ 66.449936] calling 80040000.apbx+ @ 385, parent: 80000000.apb
[ 66.456067] call 80040000.apbx+ returned 0 after 13 usecs
[ 66.461564] calling 80056000.rtc+ @ 385, parent: 80040000.apbx
[ 66.467729] call 80056000.rtc+ returned 0 after 23 usecs
[ 66.473447] calling 80068000.timrot+ @ 385, parent: 80040000.apbx
[ 66.479804] call 80068000.timrot+ returned 0 after 14 usecs
[ 66.485778] calling 80074000.serial+ @ 385, parent: 80040000.apbx
[ 66.492439] call 80074000.serial+ returned 0 after 303 usecs
[ 66.498644] calling 8007c000.usbphy+ @ 385, parent: 80040000.apbx
[ 66.505118] call 8007c000.usbphy+ returned 0 after 14 usecs
[ 66.511030] calling 80080000.ahb+ @ 385, parent: soc0
[ 66.516461] call 80080000.ahb+ returned 0 after 13 usecs
[ 66.522156] calling 80080000.usb+ @ 385, parent: 80080000.ahb
[ 66.528349] call 80080000.usb+ returned 0 after 72 usecs
[ 66.535063] calling 800f0000.ethernet+ @ 385, parent: 80080000.ahb
[ 66.545846] call 800f0000.ethernet+ returned 0 after 4310 usecs
[ 66.552190] calling iio-hwmon+ @ 385, parent: soc0
[ 66.557331] call iio-hwmon+ returned 0 after 13 usecs
[ 66.562680] calling regulators+ @ 385, parent: soc0
[ 66.567874] call regulators+ returned 0 after 13 usecs
[ 66.573247] calling regulators:regulator at 0+ @ 385, parent: regulators
[ 66.580022] call regulators:regulator at 0+ returned 0 after 15 usecs
[ 66.587259] calling leds+ @ 385, parent: soc0
[ 66.591800] call leds+ returned 0 after 15 usecs
[ 66.598846] calling alarmtimer+ @ 385, parent: platform
[ 66.604503] call alarmtimer+ returned 0 after 23 usecs
[ 66.610176] calling Fixed MDIO bus.0+ @ 385, parent: platform
[ 66.616252] call Fixed MDIO bus.0+ returned 0 after 12 usecs
[ 66.622674] calling 800f0000.etherne:00+ @ 385, parent: 800f0000.etherne
[ 66.630092] call 800f0000.etherne:00+ returned 0 after 387 usecs
[ 66.636354] calling ci_hdrc.0+ @ 385, parent: 80080000.usb
[ 66.647310] call ci_hdrc.0+ returned 0 after 5048 usecs
[ 66.652757] calling usb1+ @ 391, parent: ci_hdrc.0
[ 66.658084] calling rtc0+ @ 385, parent: 80056000.rtc
[ 66.664251] call usb1+ returned 0 after 6224 usecs
[ 66.670162] call rtc0+ returned 0 after 6462 usecs
[ 66.675361] calling stmp3xxx_rtc_wdt+ @ 385, parent: 80056000.rtc
[ 66.681633] call stmp3xxx_rtc_wdt+ returned 0 after 13 usecs
[ 66.687854] calling duckbill:green:status+ @ 385, parent: leds
[ 66.694074] call duckbill:green:status+ returned 0 after 22 usecs
[ 66.700951] calling duckbill:red:status+ @ 385, parent: leds
[ 66.706956] call duckbill:red:status+ returned 0 after 20 usecs
[ 66.713180] calling snd-soc-dummy+ @ 385, parent: platform
[ 66.718969] call snd-soc-dummy+ returned 0 after 13 usecs
[ 66.725823] PM: resume of devices complete after 469.549 msecs
[ 66.739348] Restarting tasks ... [ 66.783319] done.
echo freeze > /sys/power/state
[ 189.939554] PM: Syncing filesystems ... [ 191.084732] done.
[ 191.090589] Freezing user space processes ... [ 191.100074] (elapsed 0.004
seconds) done.
[ 191.104444] Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
done.
[ 191.121118] calling mmc0:0007+ @ 391, parent: mmc0
[ 191.126437] calling snd-soc-dummy+ @ 385, parent: platform
[ 191.132104] call snd-soc-dummy+ returned 0 after 14 usecs
[ 191.139007] call mmc0:0007+ returned 0 after 12458 usecs
[ 191.144846] calling duckbill:red:status+ @ 385, parent: leds
[ 191.150693] call duckbill:red:status+ returned 0 after 20 usecs
[ 191.156887] calling duckbill:green:status+ @ 385, parent: leds
[ 191.163035] call duckbill:green:status+ returned 0 after 20 usecs
[ 191.169680] calling stmp3xxx_rtc_wdt+ @ 385, parent: 80056000.rtc
[ 191.176097] call stmp3xxx_rtc_wdt+ returned 0 after 14 usecs
[ 191.181889] calling rtc0+ @ 385, parent: 80056000.rtc
[ 191.187289] call rtc0+ returned 0 after 58 usecs
[ 191.193635] calling usb1+ @ 391, parent: ci_hdrc.0
[ 191.223649] call usb1+ returned 0 after 24451 usecs
[ 191.228801] calling ci_hdrc.0+ @ 385, parent: 80080000.usb
[ 191.234867] call ci_hdrc.0+ returned 0 after 249 usecs
[ 191.240183] calling 800f0000.etherne:00+ @ 385, parent: 800f0000.etherne
[ 191.247628] call 800f0000.etherne:00+ returned 0 after 428 usecs
[ 191.254012] calling Fixed MDIO bus.0+ @ 385, parent: platform
[ 191.259933] call Fixed MDIO bus.0+ returned 0 after 12 usecs
[ 191.266098] calling alarmtimer+ @ 385, parent: platform
[ 191.271513] call alarmtimer+ returned 0 after 31 usecs
[ 191.280964] calling leds+ @ 385, parent: soc0
[ 191.285646] call leds+ returned 0 after 15 usecs
[ 191.290408] calling regulators:regulator at 0+ @ 385, parent: regulators
[ 191.297152] call regulators:regulator at 0+ returned 0 after 14 usecs
[ 191.303602] calling regulators+ @ 385, parent: soc0
[ 191.308648] call regulators+ returned 0 after 13 usecs
[ 191.314044] calling iio-hwmon+ @ 385, parent: soc0
[ 191.319008] call iio-hwmon+ returned 0 after 13 usecs
[ 191.324325] calling 800f0000.ethernet+ @ 385, parent: 80080000.ahb
[ 191.330828] call 800f0000.ethernet+ returned 0 after 152 usecs
[ 191.336942] calling 80080000.usb+ @ 385, parent: 80080000.ahb
[ 191.343135] call 80080000.usb+ returned 0 after 62 usecs
[ 191.348600] calling 80080000.ahb+ @ 385, parent: soc0
[ 191.353949] call 80080000.ahb+ returned 0 after 13 usecs
[ 191.359397] calling 8007c000.usbphy+ @ 385, parent: 80040000.apbx
[ 191.365789] call 8007c000.usbphy+ returned 0 after 14 usecs
[ 191.371504] calling 80074000.serial+ @ 385, parent: 80040000.apbx
[ 191.377944] call 80074000.serial+ returned 0 after 51 usecs
[ 191.383782] calling 80068000.timrot+ @ 385, parent: 80040000.apbx
[ 191.390043] call 80068000.timrot+ returned 0 after 13 usecs
[ 191.395885] calling 80056000.rtc+ @ 385, parent: 80040000.apbx
[ 191.401889] call 80056000.rtc+ returned 0 after 14 usecs
[ 191.407472] calling 80040000.apbx+ @ 385, parent: 80000000.apb
[ 191.413607] call 80040000.apbx+ returned 0 after 12 usecs
[ 191.419146] calling 8002c000.ocotp+ @ 385, parent: 80000000.apbh
[ 191.425447] call 8002c000.ocotp+ returned 0 after 13 usecs
[ 191.431064] calling 80028000.dcp+ @ 385, parent: 80000000.apbh
[ 191.437198] call 80028000.dcp+ returned 0 after 13 usecs
[ 191.442706] calling 80024000.dma-apbx+ @ 385, parent: 80000000.apbh
[ 191.449272] call 80024000.dma-apbx+ returned 0 after 14 usecs
[ 191.455345] calling 80018000.pinctrl:gpio at 4+ @ 385, parent: 80018000.pinctrl
[ 191.462570] call 80018000.pinctrl:gpio at 4+ returned 0 after 14 usecs
[ 191.469179] calling 80018000.pinctrl:gpio at 3+ @ 385, parent: 80018000.pinctrl
[ 191.476533] call 80018000.pinctrl:gpio at 3+ returned 0 after 13 usecs
[ 191.483150] calling 80018000.pinctrl:gpio at 2+ @ 385, parent: 80018000.pinctrl
[ 191.490374] call 80018000.pinctrl:gpio at 2+ returned 0 after 15 usecs
[ 191.496983] calling 80018000.pinctrl:gpio at 1+ @ 385, parent: 80018000.pinctrl
[ 191.504340] call 80018000.pinctrl:gpio at 1+ returned 0 after 14 usecs
[ 191.510828] calling 80018000.pinctrl:gpio at 0+ @ 385, parent: 80018000.pinctrl
[ 191.518177] call 80018000.pinctrl:gpio at 0+ returned 0 after 13 usecs
[ 191.524725] calling 80018000.pinctrl+ @ 385, parent: 80000000.apbh
[ 191.531076] call 80018000.pinctrl+ returned 0 after 14 usecs
[ 191.536998] calling 80010000.ssp+ @ 385, parent: 80000000.apbh
[ 191.543197] call 80010000.ssp+ returned 0 after 72 usecs
[ 191.548705] calling 80004000.dma-apbh+ @ 385, parent: 80000000.apbh
[ 191.555270] call 80004000.dma-apbh+ returned 0 after 14 usecs
[ 191.561178] calling 80000000.apbh+ @ 385, parent: 80000000.apb
[ 191.567310] call 80000000.apbh+ returned 0 after 13 usecs
[ 191.573063] calling 80000000.apb+ @ 385, parent: soc0
[ 191.578290] call 80000000.apb+ returned 0 after 11 usecs
[ 191.583997] calling reg-dummy+ @ 385, parent: platform
[ 191.589308] call reg-dummy+ returned 0 after 12 usecs
[ 191.594782] PM: suspend of devices complete after 474.663 msecs
[ 191.608635] PM: late suspend of devices complete after 7.831 msecs
[ 191.622637] PM: noirq suspend of devices complete after 7.569 msecs
[ 366.696043] INFO: task ext4lazyinit:70 blocked for more than 120 seconds.
[ 366.703046] Not tainted 4.9.0-rc1 #7
[ 366.707188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 366.715161] ext4lazyinit D c05aa6ac 0 70 2 0x00000000
[ 366.721713] [<c05aa6ac>] (__schedule) from [<c05aafb8>] (schedule+0x3c/0xbc)
[ 366.728972] [<c05aafb8>] (schedule) from [<c05aee38>]
(schedule_timeout+0x23c/0x3d8)
[ 366.736917] [<c05aee38>] (schedule_timeout) from [<c05aa398>]
(io_schedule_timeout+0xb8/0x13c)
[ 366.745721] [<c05aa398>] (io_schedule_timeout) from [<c05ab9d8>]
(T.1434+0xac/0x12c)
[ 366.753671] [<c05ab9d8>] (T.1434) from [<c02c7668>]
(submit_bio_wait+0x50/0x68)
[ 366.761078] [<c02c7668>] (submit_bio_wait) from [<c02d9a58>]
(blkdev_issue_zeroout+0x174/0x1ec)
[ 366.769984] [<c02d9a58>] (blkdev_issue_zeroout) from [<c0196e4c>]
(ext4_init_inode_table+0x1ac/0x3b0)
[ 366.779410] [<c0196e4c>] (ext4_init_inode_table) from [<c01ba770>]
(ext4_lazyinit_thread+0x280/0x398)
[ 366.788803] [<c01ba770>] (ext4_lazyinit_thread) from [<c003bce4>]
(kthread+0xc4/0xe0)
[ 366.796828] [<c003bce4>] (kthread) from [<c000a34c>]
(ret_from_fork+0x14/0x28)
[ 366.804200]
[ 366.804200] Showing all locks held in the system:
[ 366.810465] 2 locks held by khungtaskd/10:
[ 366.814707] #0: [ 366.816500] (
rcu_read_lock[ 366.819360] ){......}
, at: [ 366.822236] [<c0093a10>] watchdog+0xb4/0x61c
[ 366.826656] #1: [ 366.828450] (
tasklist_lock[ 366.831312] ){.+.+..}
, at: [ 366.834320] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
[ 366.839701] 4 locks held by ext4lazyinit/70:
[ 366.844107] #0: [ 366.845897] (
&type->s_umount_key[ 366.849280] #22
){++++++}[ 366.851866] , at:
[ 366.854044] [<c01ba5c4>] ext4_lazyinit_thread+0xd4/0x398
[ 366.859400] #1: [ 366.861178] (
sb_writers[ 366.863897] #3
){.+.+.+}[ 366.866412] , at:
[ 366.868475] [<c01ba5dc>] ext4_lazyinit_thread+0xec/0x398
[ 366.873925] #2: [ 366.875716] (
jbd2_handle[ 366.878405] ){++++..}
, at: [ 366.881292] [<c01f661c>] start_this_handle+0xec/0x404
[ 366.886492] #3: [ 366.888284] (
&meta_group_info[i]->alloc_sem[ 366.892620] ){++++..}
, at: [ 366.895624] [<c0196d58>] ext4_init_inode_table+0xb8/0x3b0
[ 366.901093] 4 locks held by bash/385:
[ 366.904895] #0: [ 366.906686] (
sb_writers[ 366.909288] #4
){.+.+.+}[ 366.911787] , at:
[ 366.913972] [<c011f7d4>] vfs_write+0x194/0x1a4
[ 366.918456] #1: [ 366.920234] (
&of->mutex[ 366.922824] ){+.+.+.}
, at: [ 366.925940] [<c019029c>] kernfs_fop_write+0xc0/0x1d0
[ 366.930942] #2: [ 366.932714] (
s_active[ 366.935265] #43
){.+.+.+}[ 366.937864] , at:
[ 366.939927] [<c01902a4>] kernfs_fop_write+0xc8/0x1d0
[ 366.945029] #3: [ 366.946818] (
pm_mutex[ 366.949242] ){+.+.+.}
, at: [ 366.952111] [<c005b7e4>] pm_suspend+0x90/0x81c
[ 366.956697]
[ 366.958229] =============================================
^ permalink raw reply
* [PATCH v6 1/7] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-10-31 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1746536.qobnGdHRfV@wasted.cogentembedded.com>
The initial R8A7743 SoC device tree including CPU0, GIC, timer, SYSC, RST,
CPG, and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 6:
- corrected the "reg" prop of the RST node;
- removed leading zero from the SYSC "reg" property's cell;
- fixed the typo in "overriden".
Changes in version 5:
- added the RST device node, updated the patch description accordingly.
Changes in version 4:
- removed the CPU1 node, updated the patch description accordingly;
- reformatted the "interrupts" props of the GIC/timer device nodes;
- added Geert's tag.
Changes in version 3:
- changed the R8A7743 clock header #include;
- replaced the multiple clock nodes with the single CPG node, updated the
"clocks" property in the CPU0 node, updated the patch description.
Changes in version 2:
- added the IRQC and Ether clocks.
arch/arm/boot/dts/r8a7743.dtsi | 120 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 120 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,120 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7743-cpg-mssr.h>
+#include <dt-bindings/power/r8a7743-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU0>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ L2_CA15: cache-controller at 0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7743_PD_CA15_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller at f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ cpg: clock-controller at e6150000 {
+ compatible = "renesas,r8a7743-cpg-mssr";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk>, <&usb_extal_clk>;
+ clock-names = "extal", "usb_extal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ };
+
+ sysc: system-controller at e6180000 {
+ compatible = "renesas,r8a7743-sysc";
+ reg = <0 0xe6180000 0 0x200>;
+ #power-domain-cells = <1>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7743-rst";
+ reg = <0 0xe6160000 0 0x100>;
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
^ permalink raw reply
* [PATCH] staging: vc04_services: setup DMA and coherent mask
From: Michael Zoran @ 2016-10-31 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477939258.30971.1.camel@crowfest.net>
On Mon, 2016-10-31 at 11:40 -0700, Michael Zoran wrote:
> On Mon, 2016-10-31 at 11:36 -0700, Eric Anholt wrote:
> > Michael Zoran <mzoran@crowfest.net> writes:
> >
> > > Setting the DMA mask is optional on 32 bit but
> > > is mandatory on 64 bit.??Set the DMA mask and coherent
> > > to force all DMA to be in the 32 bit address space.
> > >
> > > This is considered a "good practice" and most drivers
> > > already do this.
> > >
> > > Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> > > ---
> > > ?.../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c |
> > > 10 ++++++++++
> > > ?1 file changed, 10 insertions(+)
> > >
> > > diff --git
> > > a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_ar
> > > m.
> > > c
> > > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_ar
> > > m.
> > > c
> > > index a5afcc5..6fa2b5a 100644
> > > ---
> > > a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_ar
> > > m.
> > > c
> > > +++
> > > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_ar
> > > m.
> > > c
> > > @@ -97,6 +97,16 @@ int vchiq_platform_init(struct platform_device
> > > *pdev, VCHIQ_STATE_T *state)
> > > ? int slot_mem_size, frag_mem_size;
> > > ? int err, irq, i;
> > > ?
> > > + /*
> > > + ?* Setting the DMA mask is necessary in the 64 bit
> > > environment.
> > > + ?* It isn't necessary in a 32 bit environment but is
> > > considered
> > > + ?* a good practice.
> > > + ?*/
> > > + err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
> >
> > I think a better comment here would be simply:
> >
> > /* VCHI messages between the CPU and firmware use 32-bit bus
> > addresses. */
> >
> > explaining why the value is chosen (once you know that the 32 bit
> > restriction exists, reporting it is obviously needed).??I'm
> > curious,
> > though: what failed when you didn't set it?
> >
>
> The comment is easy to change.
>
> I don't have the log available ATM, but if I remember the DMA API's
> bugcheck the first time that are used.??
>
> I think this was a policy decision or something because the
> information
> should be available in the dma-ranges.
>
> If it's important, I can setup a test again without the change and e-
> mail the logs.
>
> If you look at the DWC2 driver you will see that it also sets this
> mask.
OK, I'm begging to understand this. It appears the architecture
specific paths are very different.
In arm the mask and coherent is set to DMA_BIT_MASK(32) in mm/dma-
mapping.c the first time the dma APIs are used. On arm64, it appears
this variable is uninitialized and will contain random crude.
Like I said, I don't know if this is a policy decision or if it just
slipped through the cracks.
arch/arm/mm/dma-mapping.c(Note the call to get_coherent_dma_mask(dev))
static u64 get_coherent_dma_mask(struct device *dev)
{
u64 mask = (u64)DMA_BIT_MASK(32);
if (dev) {
mask = dev->coherent_dma_mask;
/*
?* Sanity check the DMA mask - it must be non-zero, and
?* must be able to be satisfied by a DMA allocation.
?*/
if (mask == 0) {
dev_warn(dev, "coherent DMA mask is unset\n");
return 0;
}
if (!__dma_supported(dev, mask, true))
return 0;
}
return mask;
}
static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t
*handle,
?gfp_t gfp, pgprot_t prot, bool is_coherent,
?unsigned long attrs, const void *caller)
{
u64 mask = get_coherent_dma_mask(dev);
struct page *page = NULL;
void *addr;
bool allowblock, cma;
struct arm_dma_buffer *buf;
struct arm_dma_alloc_args args = {
.dev = dev,
.size = PAGE_ALIGN(size),
.gfp = gfp,
.prot = prot,
.caller = caller,
.want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) ==
0),
.coherent_flag = is_coherent ? COHERENT : NORMAL,
};
arch/arm64/include/asm/dma-mapping.h
/* do not use this function in a driver */
static inline bool is_device_dma_coherent(struct device *dev)
{
if (!dev)
return false;
return dev->archdata.dma_coherent;
}
arch/arm64/mm/dma-mapping.c(Note no call to get_coherent_dma_mask)
static void *__dma_alloc(struct device *dev, size_t size,
?dma_addr_t *dma_handle, gfp_t flags,
?unsigned long attrs)
{
struct page *page;
void *ptr, *coherent_ptr;
bool coherent = is_device_dma_coherent(dev);
pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, false);
size = PAGE_ALIGN(size);
if (!coherent && !gfpflags_allow_blocking(flags)) {
struct page *page = NULL;
void *addr = __alloc_from_pool(size, &page, flags);
if (addr)
*dma_handle = phys_to_dma(dev,
page_to_phys(page));
return addr;
}
ptr = __dma_alloc_coherent(dev, size, dma_handle, flags,
attrs);
^ permalink raw reply
* [PATCH v6 0/7] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-31 19:52 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 7 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20161031-v4.9-rc3' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems identical to the R8A7791/Porter board. The device tree patches depend on
the R8A7743 CPG/MSSR driver series in order to compile and work. Already merged
patches from this series won't be re-posted.
[1/7] ARM: dts: r8a7743: initial SoC device tree
[2/7] ARM: dts: r8a7743: add SYS-DMAC support
[3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
[4/7] ARM: dts: r8a7743: add Ether support
[5/7] ARM: dts: r8a7743: add IRQC support
[6/7] ARM: dts: sk-rzg1m: initial device tree
[7/7] ARM: dts: sk-rzg1m: add Ether support
WBR, Sergei
^ permalink raw reply
* [PATCH] arm64: errata: Check for --fix-cortex-a53-843419 and --fix-cortex-a53
From: Markus Mayer @ 2016-10-31 19:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Mayer <mmayer@broadcom.com>
The new errata check leads to a warning with some older versions of the
linker that do know how to work around the errata, but still use the
original name of the command line option: --fix-cortex-a53. The commit
in question that changed the name of the option can be found at [1].
It looks like only "gold" is affected by this rename. Traditional "ld"
isn't. (There, the argument was always called --fix-cortex-a53-843419.)
To allow older versions of gold to properly handle the erratum if they
can, check whether ld supports the old name of this option in addition
to checking the new one.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=7a2a1c793578a8468604e661dda025ecb8d0bd20;hp=cfbf0e3c5b637d66b2b1aeadecae9c187b825b2f
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
Using the change proposed here, things work for me as expected:
$ aarch64-linux-ld -v
GNU ld (GNU Binutils) Linaro 2014.11-2 2.24.0.20141017
$ grep fix-cortex aarch64.log
/bin/bash scripts/link-vmlinux.sh aarch64-linux-ld -EL -p --no-undefined
-X --fix-cortex-a53 --build-id ; true
+ aarch64-linux-ld -EL -p --no-undefined -X --fix-cortex-a53 --build-id -o
.tmp_vmlinux1 -T ./arch/arm64/kernel/vmlinux.lds arch/arm64/kernel/head.o
init/built-in.o --start-group usr/built-in.o arch/arm64/kernel/built-in.o
arch/arm64/mm/built-in.o arch/arm64/net/built-in.o arch/arm64/kvm/built-in.o
arch/arm64/xen/built-in.o arch/arm64/crypto/built-in.o
./drivers/firmware/efi/libstub/lib.a kernel/built-in.o certs/built-in.o
mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o
crypto/built-in.o block/built-in.o arch/arm64/lib/lib.a lib/lib.a
arch/arm64/lib/built-in.o lib/built-in.o drivers/built-in.o sound/built-in.o
firmware/built-in.o net/built-in.o virt/built-in.o --end-group
[...]
arch/arm64/Makefile | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index ab51aed..231ba69 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -20,7 +20,13 @@ endif
ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
ifeq ($(call ld-option, --fix-cortex-a53-843419),)
-$(warning ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum)
+ ifeq ($(call ld-option, --fix-cortex-a53),)
+$(warning ld does not support --fix-cortex-a53-843419 or --fix-cortex-a53; kernel may be susceptible to erratum)
+ else
+# When this option was first introduced, it was called --fix-cortex-a53 in gold.
+# So, let's use that as fall-back if the linker understands it.
+LDFLAGS_vmlinux += --fix-cortex-a53
+ endif
else
LDFLAGS_vmlinux += --fix-cortex-a53-843419
endif
--
2.7.4
^ permalink raw reply related
* [PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property
From: Krzysztof Kozlowski @ 2016-10-31 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030204124.wwvv2qfshj7lvggx@rob-hp-laptop>
On Sun, Oct 30, 2016 at 03:41:24PM -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 05:05:54PM +0300, Krzysztof Kozlowski wrote:
> > The samsung,power-domain property is obsolete since commit 0da658704136
> > ("ARM: dts: convert to generic power domain bindings for exynos DT").
> > Replace it with generic one.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > ---
> > Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> You didn't send this To me, so I assume someone else is applying it.
>
> Acked-by: Rob Herring <robh@kernel.org>
Thanks for the ack. I assumed it will go through the Exynos DRM
subsystem maintainer.
Dear Inki Dae,
Could you pick it up or share your comments?
Best regards,
Krzysztof
^ permalink raw reply
* [RFC PATCH v2 2/5] net: phy: Add Meson GXL Internal PHY driver
From: Andrew Lunn @ 2016-10-31 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-3-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:24PM +0100, Neil Armstrong wrote:
> Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
>
> This PHY seems to only implement some standard registers and need some
> workarounds to provide autoneg values from vendor registers.
>
> Some magic values are currently used to configure the PHY, and this a
> temporary setup until clarification about these registers names and
> registers fields are provided by Amlogic.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/net/phy/Kconfig | 5 +++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/meson-gxl.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 87 insertions(+)
> create mode 100644 drivers/net/phy/meson-gxl.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 2651c8d..09342b6 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -226,6 +226,11 @@ config DP83867_PHY
> ---help---
> Currently supports the DP83867 PHY.
>
> +config MESON_GXL_PHY
> + tristate "Amlogic Meson GXL Internal PHY"
> + ---help---
> + Currently has a driver for the Amlogic Meson GXL Internal PHY
> +
Hi Neil
Please keep them in alphabetic order. This goes after Marvell.
> config FIXED_PHY
> tristate "MDIO Bus/PHY emulation with fixed speed/link PHYs"
> depends on PHYLIB
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index e58667d..1511b3e 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_MARVELL_PHY) += marvell.o
> obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
> obj-$(CONFIG_MICREL_PHY) += micrel.o
> obj-$(CONFIG_MICROCHIP_PHY) += microchip.o
> +obj-$(CONFIG_MESON_GXL_PHY) += meson-gxl.o
> obj-$(CONFIG_MICROSEMI_PHY) += mscc.o
Again, alphabetic order.
Andrew
^ permalink raw reply
* [RFC PATCH v2 1/5] net: mdio-mux-mmioreg: Add support for 16bit and 32bit register sizes
From: Andrew Lunn @ 2016-10-31 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-2-git-send-email-narmstrong@baylibre.com>
On Mon, Oct 31, 2016 at 05:56:23PM +0100, Neil Armstrong wrote:
> In order to support PHY switching on Amlogic GXL SoCs, add support for
> 16bit and 32bit registers sizes.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Nice.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] staging: vc04_services: setup DMA and coherent mask
From: Michael Zoran @ 2016-10-31 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87twbsqsb4.fsf@eliezer.anholt.net>
On Mon, 2016-10-31 at 11:36 -0700, Eric Anholt wrote:
> Michael Zoran <mzoran@crowfest.net> writes:
>
> > Setting the DMA mask is optional on 32 bit but
> > is mandatory on 64 bit.??Set the DMA mask and coherent
> > to force all DMA to be in the 32 bit address space.
> >
> > This is considered a "good practice" and most drivers
> > already do this.
> >
> > Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> > ---
> > ?.../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c |
> > 10 ++++++++++
> > ?1 file changed, 10 insertions(+)
> >
> > diff --git
> > a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.
> > c
> > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.
> > c
> > index a5afcc5..6fa2b5a 100644
> > ---
> > a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.
> > c
> > +++
> > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.
> > c
> > @@ -97,6 +97,16 @@ int vchiq_platform_init(struct platform_device
> > *pdev, VCHIQ_STATE_T *state)
> > ? int slot_mem_size, frag_mem_size;
> > ? int err, irq, i;
> > ?
> > + /*
> > + ?* Setting the DMA mask is necessary in the 64 bit
> > environment.
> > + ?* It isn't necessary in a 32 bit environment but is
> > considered
> > + ?* a good practice.
> > + ?*/
> > + err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
>
> I think a better comment here would be simply:
>
> /* VCHI messages between the CPU and firmware use 32-bit bus
> addresses. */
>
> explaining why the value is chosen (once you know that the 32 bit
> restriction exists, reporting it is obviously needed).??I'm curious,
> though: what failed when you didn't set it?
>
The comment is easy to change.
I don't have the log available ATM, but if I remember the DMA API's
bugcheck the first time that are used.
I think this was a policy decision or something because the information
should be available in the dma-ranges.
If it's important, I can setup a test again without the change and e-
mail the logs.
If you look at the DWC2 driver you will see that it also sets this
mask.
^ permalink raw reply
* SMR masking and PCI
From: Robin Murphy @ 2016-10-31 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB1321DED0E75BD607BB52889EFFAE0@HE1PR04MB1321.eurprd04.prod.outlook.com>
On 31/10/16 15:57, Diana Madalina Craciun wrote:
> Hi Robin,
>
> On 10/28/2016 07:16 PM, Robin Murphy wrote:
>> Hi Stuart,
>>
>> On 27/10/16 18:10, Stuart Yoder wrote:
>>> Hi Robin,
>>>
>>> A question about how the SMR masking defined in the arm,smmu binding
>>> relates to the PCI iommu-map.
>>>
>>> The #iommu-cells property defines the number of cells an "IOMMU specifier"
>>> takes and 2 is specified to be:
>>>
>>> SMMUs with stream matching support and complex masters
>>> may use a value of 2, where the second cell represents
>>> an SMR mask to combine with the ID in the first cell.
>>>
>>> An iommu-map entry is defined as:
>>>
>>> (rid-base,iommu,iommu-base,length)
>>>
>>> What seems to be currently missing in the iommu-map support is
>>> the possibility the case where #iommu-cells=<2>.
>> Indeed. The bindings have so far rather implicitly assumed the case of
>> #{msi,iommu}-cells = 1, and the code has followed suit.
>>
>>> In this case iommu-base which is an IOMMU specifier should
>>> occupy 2 cells. For example on an ls2085a we would want:
>>>
>>> iommu-map = <0x0 0x6 0x7 0x3ff 0x1
>>> 0x100 0x6 0x8 0x3ff 0x1>;
>>>
>>> ...to mask our stream IDs to 10 bits.
>>>
>>> This should work in theory and comply with the bindings, no?
>> In theory, but now consider:
>>
>> iommu-map = <0x0 0x6 0x7 0x3ff 0x2>;
>>
>> faced with ID 1. The input base is 0, the output base is the 2-cell
>> value 0x7000003ff, so the final ID value should be 0x700000400, right?
>>
>>> of_pci_map_rid() seems to have a hardcoded assumption that
>>> each field in the map is 4 bytes.
>> It does. I guess we should explicitly check that #{msi,iommu}-cells = 1
>> on the target node, and maybe clarify in the binding that that cell
>> should represent a plain linear ID value (although that's pretty obvious
>> from context IMO).
>>
>>> (Also, I guess that msi-map is not affected by this since it
>>> is not related to the IOMMU...but we do have common code
>>> handling both maps.)
>> I'd say it's definitely affected, since #msi-cells can equally be more
>> than 1, and encodes an equally opaque value.
>>
>> It seems pretty reasonable to me that we could extend the binding to
>> accommodate #cells > 1 iff length == 1. Mark?
>>
>> That said, is there a concrete need for this, i.e. do you actually have
>> one device with a single requester ID, which maps to multiple output IDs
>> (which differ only in the upper bits) in a non-predictable manner?
>>
> Actually in the example presented by Stuart, the SMR mask should be
> 0x7C00 (as 0 means that the bit is relevant for matching). So, we have
> the stream ID 7, but the SMMU 500 is appending the TBU bits which makes
> the stream ID look like 0x1407 (TBU 5). In our platform the relationship
> device-TBU is not exposed and documented.
To be fair, that's only the fault of the folks who neglected to document
it (and if this really was the anticipated use-case, possibly also the
integration folks for not simply using the 15-bit Stream ID
configuration and tying any extra bits off). The TBU IDs are still an
undeniable property of the hardware, and not exactly difficult to
discover either. For instance, an LS2085a has been running with the
following map for PCIe for quite some time:
/* Squash 8:5:3 BDF down to 2:2:3 */
iommu-map-mask = <0x031f>;
iommu-map = <0x000 &smmu 0x1400 0x20>,
<0x100 &smmu 0x1420 0x20>,
<0x200 &smmu 0x1440 0x20>,
<0x300 &smmu 0x1460 0x20>;
(with the obligatory hacks to program the PEX LUT entries to match, and
the SATA ICIDs not to alias as they apparently go through the same TBU).
> The SMMU-500 ref manual
> describes this case:
>
> "If the Stream ID presented to each TBU is already unique, and the TBU
> ID addition is not required, then you must ensure that the TBU ID field
> is masked in the SMR."
>
> This is the reason that we need the SMR mask, to mask the TBU bits in
> the SMR.
The PCIe example might be a reason to *want* masking, in order to work
around inadequate documentation, but it certainly isn't a *need*.
Fortunately, Stuart's description of the DPAA complex mastering through
multiple TBUs such that a single device's ICID may map to multiple
stream IDs *is* a compelling justification, because iommu-map isn't
designed for one-to-many mappings. You just need to be very careful the
ICIDs really are completely unique system-wide once you start masking,
or the aliasing will result in weird, and possibly impractical, group
assignment.
Anyway, from the SMMU driver perspective SMR masking does work nicely
now, so I'm happy to review patches to of_pci_map_rid() ;)
Robin.
>
> Thank you,
>
> Diana
>
>
>
^ permalink raw reply
* [PATCH] staging: vc04_services: setup DMA and coherent mask
From: Eric Anholt @ 2016-10-31 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028171159.23973-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> Setting the DMA mask is optional on 32 bit but
> is mandatory on 64 bit. Set the DMA mask and coherent
> to force all DMA to be in the 32 bit address space.
>
> This is considered a "good practice" and most drivers
> already do this.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> ---
> .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> index a5afcc5..6fa2b5a 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> @@ -97,6 +97,16 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
> int slot_mem_size, frag_mem_size;
> int err, irq, i;
>
> + /*
> + * Setting the DMA mask is necessary in the 64 bit environment.
> + * It isn't necessary in a 32 bit environment but is considered
> + * a good practice.
> + */
> + err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
I think a better comment here would be simply:
/* VCHI messages between the CPU and firmware use 32-bit bus addresses. */
explaining why the value is chosen (once you know that the 32 bit
restriction exists, reporting it is obviously needed). I'm curious,
though: what failed when you didn't set it?
> +
> + if (err < 0)
> + return err;
> +
> (void)of_property_read_u32(dev->of_node, "cache-line-size",
> &g_cache_line_size);
> g_fragments_size = 2 * g_cache_line_size;
> --
> 2.10.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/9e41b8fa/attachment.sig>
^ permalink raw reply
* [PATCH] staging: vc04_services: call sg_init_table to init scatterlist
From: Eric Anholt @ 2016-10-31 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028175813.28022-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> Call the sg_init_table function to correctly initialze
> the DMA scatterlist. This function is required to completely
> initialize the list and is mandatory if DMA debugging is
> enabled in the build configuration.
>
> One of the purposes of sg_init_table is to set
> the magic "cookie" on each list element and ensure
> the chain end is marked.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>
> ---
> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> index 6fa2b5a..21b26e5 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> @@ -464,6 +464,12 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
> pagelist->type = type;
> pagelist->offset = offset;
>
> + /*
> + * Initialize the scatterlist so that the magic cookie
> + * is filled if debugging is enabled
> + */
> + sg_init_table(scatterlist, num_pages);
> + /* Now set the pages for each scatterlist */
I feel like the comments don't add much, but either way:
Acked-by: Eric Anholt <eric@anholt.net>
> for (i = 0; i < num_pages; i++)
> sg_set_page(scatterlist + i, pages[i], PAGE_SIZE, 0);
>
> --
> 2.10.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/620e7f68/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl: meson: Add GXL pinctrl definitions
From: Kevin Hilman @ 2016-10-31 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477931531-27120-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-31 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2291876.8LAt3RcuXX@amdc3058>
On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > Hi,
> > >
> > > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > >
> > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > > > (no IDE host drivers are selected in this config so there is no
> > > > > > > valid reason to enable IDE subsystem itself).
> > > > > > >
> > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > > >
> > > > > > I think the series makes a lot of sense. I have checked your assertions
> > > > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > > > take them all through arm-soc unless there are other concerns.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Should I resend everything or just patches that were not reposted yet
> > > > > (the ones that were marked as RFT initially and got no feedback)?
> > > >
> > > > I'd be fine with just getting a pull request with all the patches that
> > > > had no negative feedback and that were not already applied (if any).
> > >
> > > Here it is (sorry for taking so long).
> >
> > I've just been digging in the dmesg logs from when I was using the
> > Assabet+Neponset as my firewall, and it was having to use the IDE
> > ide-cs driver rather than the pata pcmcia driver.
> >
> > I don't recall whether the pata pcmcia driver was a problem or not,
> > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> > think PATA tries to use the "highest" possible access size by
> > default...
>
> It doesn't actually - it defaults to 16-bits for PIO data access and
> you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
> (pata_pcmcia doesn't set it so it should be okay). Also taskfile
> registers are accessed using 8-bits access by default transport
> functions (which are used by pata_pcmcia).
Please also note that:
- assebet_defconfig currently doesn't even enable ide-cs
(CONFIG_BLK_DEV_IDECS) in the mainline kernel
- neponset_defconfig doesn't even enable IDE (CONFIG_IDE)
in the mainline kernel
so there is no risk of breaking anything.. :-)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Andrew F. Davis @ 2016-10-31 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029094641.GA23362@ermac>
On 10/29/2016 04:46 AM, Jens Wiklander wrote:
> On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
>> On 10/28/2016 05:19 AM, Jens Wiklander wrote:
>>> Hi,
>>>
>>> This patch set introduces a generic TEE subsystem. The TEE subsystem will
>>> contain drivers for various TEE implementations. A TEE (Trusted Execution
>>> Environment) is a trusted OS running in some secure environment, for
>>> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
>>>
>>> Regarding use cases, TrustZone has traditionally been used for
>>> offloading secure tasks to the secure world. Examples include:
>>> - Secure key handling where the OS may or may not have direct access to key
>>> material.
>>> - E-commerce and payment technologies. Credentials, credit card numbers etc
>>> could be stored in a more secure environment.
>>> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
>>> etc.
>>> - Secure boot to ensure that loaded binaries haven?t been tampered with.
>>> It?s not strictly needed for secure boot, but you could enhance security
>>> by leveraging a TEE during boot.
>>> - Digital Rights Management (DRM), the studios provides content with
>>> different resolution depending on the security of the device. Higher
>>> security means higher resolution.
>>>
>>> A TEE could also be used in existing and new technologies. For example IMA
>>> (Integrity Measurement Architecture) which has been in the kernel for quite
>>> a while. Today you can enhance security by using a TPM-chip to sign the IMA
>>> measurement list. This is something that you also could do by leveraging a
>>> TEE.
>>>
>>> Another example could be in 2-factor authentication which is becoming
>>> increasingly more important. FIDO (https://fidoalliance.org) for example
>>> are using public key cryptography in their 2-factor authentication standard
>>> (U2F). With FIDO, a private and public key pair will be generated for every
>>> site you visit and the private key should never leave the local device.
>>> This is an example where you could use secure storage in a TEE for the
>>> private key.
>>>
>>> Today you will find a quite a few different out of tree implementations of
>>> TEE drivers which tends to fragment the TEE ecosystem and development. We
>>> think it would be a good idea to have a generic TEE driver integrated in
>>> the kernel which would serve as a base for several different TEE solutions,
>>> no matter if they are on-chip like TrustZone or if they are on a separate
>>> crypto co-processor.
>>>
>>> To develop this TEE subsystem we have been using the open source TEE called
>>> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
>>> first TEE solution supported by this new subsystem. OP-TEE is a
>>> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
>>> only GlobalPlatform TEEs, instead we have tried to design it so that it
>>> should work with other TEE solutions also.
>>>
>>
>> The above is my biggest concern with this whole subsystem, to me it
>> still feels very OPTEE specific. As much as I would love to believe
>> OPTEE will be the end-all TEE, I'm sure we soon will start to see wider
>> use of vendor TEEs (like TI's own legacy Trustzone thing we are hoping
>> to depreciate with OPTEE moving forward), possibly Google's Trusty TEE,
>> and whatever Intel/AMD are cooking up for x86.
>
> I'd rather say that it's slightly GlobalPlatform specific, but a bit
> more flexible.
>
>>
>> As we all know when things are upstreamed we lose the ability to make
>> radical changes easily, especially to full subsystems. What happens when
>> this framework, built with only one existing TEE, built by the one
>> existing TEE's devs, is not as flexible as we need when other TEEs start
>> rolling out?
>
> Initially the TEE subsystem was much more flexible and was criticized
> for that.
>
That's rather strange, I haven't been following this from the start so I
will just take your word that this is where the community wants this
subsystem to go.
>>
>> Do we see this as a chicken and egg situation, or is there any harm
>> beyond the pains of supporting an out-of-tree driver for a while, to
>> wait until we have at least one other TEE to add to this subsystem
>> before merging?
>
> This proposal is the bare minimum to have something useful. On top of
> this there's more things we'd like to add, for example an in-kernel API
> for accessing the TEE and secure buffer handling. The way we're dealing
> with shared memory need to be improved to better support multiple guests
> communicating with one TEE.
>
> What we can do now with the subsystem now is somewhat limited by the
> fact that we're trying to upstream it and want to do that it in
> manageable increments.
>
Fair enough.
For now this series is being used in our production SDKs so it has at
least some basic testing from us, so for the whole series:
Tested-by: Andrew F. Davis <afd@ti.com>
> Thanks,
> Jens
>
>>
>> This may also help with the perceived lack of reviewers for this series.
>>
>> Thanks,
>> Andrew
>>
>>> "tee: generic TEE subsystem" brings in the generic TEE subsystem which
>>> helps when writing a driver for a specific TEE, for example, OP-TEE.
>>>
>>> "tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
>>> its work.
>>>
>>> This patch set has been prepared in cooperation with Javier Gonz?lez who
>>> proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
>>> https://lwn.net/Articles/623380/ . We've since then changed the scope to
>>> TEE instead of TrustZone.
>>>
>>> We have discussed the design on tee-dev at lists.linaro.org (archive at
>>> https://lists.linaro.org/pipermail/tee-dev/) with people from other
>>> companies, including Valentin Manea <valentin.manea@huawei.com>,
>>> Emmanuel MICHEL <emmanuel.michel@st.com>,
>>> Jean-michel DELORME <jean-michel.delorme@st.com>,
>>> and Joakim Bech <joakim.bech@linaro.org>. Our main concern has been to
>>> agree on something that is generic enough to support many different
>>> TEEs while still keeping the interface together.
>>>
>>> v12-resend:
>>> * Rebased on v4.9-rc2
>>>
>>> v12:
>>> * Rebased on v4.8-rc5
>>> * Addressed review comments from Andrew F. Davis
>>> * Removed Acked-by: Andreas Dannenberg <dannenberg@ti.com> as the
>>> mail bounces
>>> * Bugfix possible null dereference in error cleanup path of
>>> optee_probe().
>>> * Bugfix optee_from_msg_param() when calculating offset of memref
>>> into a shared memory object
>>>
>>> v11:
>>> * Rebased on v4.8-rc3
>>> * Addressed review comments from Nishanth Menon
>>> * Made the TEE framework available as a loadable module.
>>> * Reviewed-by: Javier Gonz?lez <javier@javigon.com>
>>> * Zeroes shared memory on allocation to avoid information leakage
>>> * Links shared memory objects to context to avoid stealing of shared memory
>>> object from an unrelated process
>>> * Allow RPC interruption if supplicant is unavailable
>>>
>>> v10:
>>> * Rebased on v4.7-rc1
>>> * Addressed private review comments from Nishanth Menon
>>> * Optee driver only accepts one supplicant process on the privileged device
>>> * Optee driver avoids long delayed releases of shm objects
>>> * Added more comments on functions and structs
>>>
>>> v9:
>>> * Rebased on v4.6-rc1
>>> * Acked-by: Andreas Dannenberg <dannenberg@ti.com>
>>> * Addressed comments from Al Viro how file descriptors are passed to
>>> user space
>>> * Addressed comments from Randy Dunlap on documentation
>>> * Changed license for include/uapi/linux/tee.h
>>>
>>> v8:
>>> * Rebased on v4.5-rc3
>>> * dt/bindings: add bindings for optee
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> * Fixes build error for X86
>>> * Fixes spell error in "dt/bindings: add bindings for optee"
>>>
>>> v7:
>>> * Rebased on v4.5-rc2
>>> * Moved the ARM SMC Calling Convention support into a separate patch
>>> set, which is now merged
>>>
>>> v6:
>>> * Rebased on v4.3-rc7
>>> * Changed smccc interface to let the compiler marshal most of the
>>> parameters
>>> * Added ARCH64 capability for smccc interface
>>> * Changed the PSCI firmware calls (both arm and arm64) to use the new
>>> generic smccc interface instead instead of own assembly functions.
>>> * Move optee DT bindings to below arm/firmware
>>> * Defines method for OP-TEE driver to call secure world in DT, smc or hvc
>>> * Exposes implementation id of a TEE driver in sysfs
>>> to easily spawn corresponding tee-supplicant when device is ready
>>> * Update OP-TEE Message Protocol to better cope with fragmented physical
>>> memory
>>> * Read time directly from OP-TEE driver instead of forwarding the RPC
>>> request to tee-supplicant
>>>
>>> v5:
>>> * Replaced kref reference counting for the device with a size_t instead as
>>> the counter is always protected by a mutex
>>>
>>> v4:
>>> * Rebased on 4.1
>>> * Redesigned the synchronization around entry exit of normal SMC
>>> * Replaced rwsem on the driver instance with kref and completion since
>>> rwsem wasn't intended to be used in this way
>>> * Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
>>> future additional parameter types
>>> * Documents TEE subsystem and OP-TEE driver
>>> * Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
>>> TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
>>> * DT bindings in a separate patch
>>> * Assembly parts moved to arch/arm and arch/arm64 respectively, in a
>>> separate patch
>>> * Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
>>> * Removed CMA usage to limit the scope of the patch set
>>>
>>> v3:
>>> * Rebased on 4.1-rc3 (dma_buf_export() API change)
>>> * A couple of small sparse fixes
>>> * Documents bindings for OP-TEE driver
>>> * Updated MAINTAINERS
>>>
>>> v2:
>>> * Replaced the stubbed OP-TEE driver with a real OP-TEE driver
>>> * Removed most APIs not needed by OP-TEE in current state
>>> * Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
>>> * Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
>>> * Moved tee.h into include/uapi/linux/
>>> * Redefined tee.h IOCTL macros to be directly based on _IOR and friends
>>> * Removed version info on the API to user space, a data blob which
>>> can contain an UUID is left for user space to be able to tell which
>>> protocol to use in TEE_IOC_CMD
>>> * Changed user space exposed structures to only have types with __ prefix
>>> * Dropped THIS_MODULE from tee_fops
>>> * Reworked how the driver is registered and ref counted:
>>> - moved from using an embedded struct miscdevice to an embedded struct
>>> device.
>>> - uses an struct rw_semaphore as synchronization for driver detachment
>>> - uses alloc/register pattern from TPM
>>>
>>> Thanks,
>>> Jens
>>>
>>> Jens Wiklander (4):
>>> dt/bindings: add bindings for optee
>>> tee: generic TEE subsystem
>>> tee: add OP-TEE driver
>>> Documentation: tee subsystem and op-tee driver
>>>
>>> Documentation/00-INDEX | 2 +
>>> .../bindings/arm/firmware/linaro,optee-tz.txt | 31 +
>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>> Documentation/ioctl/ioctl-number.txt | 1 +
>>> Documentation/tee.txt | 118 +++
>>> MAINTAINERS | 13 +
>>> drivers/Kconfig | 2 +
>>> drivers/Makefile | 1 +
>>> drivers/tee/Kconfig | 18 +
>>> drivers/tee/Makefile | 5 +
>>> drivers/tee/optee/Kconfig | 7 +
>>> drivers/tee/optee/Makefile | 5 +
>>> drivers/tee/optee/call.c | 435 ++++++++++
>>> drivers/tee/optee/core.c | 598 ++++++++++++++
>>> drivers/tee/optee/optee_msg.h | 435 ++++++++++
>>> drivers/tee/optee/optee_private.h | 185 +++++
>>> drivers/tee/optee/optee_smc.h | 446 ++++++++++
>>> drivers/tee/optee/rpc.c | 404 +++++++++
>>> drivers/tee/optee/supp.c | 273 +++++++
>>> drivers/tee/tee_core.c | 901 +++++++++++++++++++++
>>> drivers/tee/tee_private.h | 129 +++
>>> drivers/tee/tee_shm.c | 357 ++++++++
>>> drivers/tee/tee_shm_pool.c | 158 ++++
>>> include/linux/tee_drv.h | 278 +++++++
>>> include/uapi/linux/tee.h | 403 +++++++++
>>> 25 files changed, 5206 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
>>> create mode 100644 Documentation/tee.txt
>>> create mode 100644 drivers/tee/Kconfig
>>> create mode 100644 drivers/tee/Makefile
>>> create mode 100644 drivers/tee/optee/Kconfig
>>> create mode 100644 drivers/tee/optee/Makefile
>>> create mode 100644 drivers/tee/optee/call.c
>>> create mode 100644 drivers/tee/optee/core.c
>>> create mode 100644 drivers/tee/optee/optee_msg.h
>>> create mode 100644 drivers/tee/optee/optee_private.h
>>> create mode 100644 drivers/tee/optee/optee_smc.h
>>> create mode 100644 drivers/tee/optee/rpc.c
>>> create mode 100644 drivers/tee/optee/supp.c
>>> create mode 100644 drivers/tee/tee_core.c
>>> create mode 100644 drivers/tee/tee_private.h
>>> create mode 100644 drivers/tee/tee_shm.c
>>> create mode 100644 drivers/tee/tee_shm_pool.c
>>> create mode 100644 include/linux/tee_drv.h
>>> create mode 100644 include/uapi/linux/tee.h
>>>
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Kevin Hilman @ 2016-10-31 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b80010f7-196a-abeb-e4a2-5009f3b7f13b@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 10/24/2016 03:03 AM, Linus Walleij wrote:
>> On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>>> Add support for the Amlogic Meson GXL SoC, this is a partially complete
>>> definition only based on the Amlogic Vendor tree.
>>>
>>> This definition differs a lot from the GXBB and needs a separate entry.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Looks good to me. Tell me when I may apply it, it looks orthogonal
>> to the rest of the patches.
>>
>> Yours,
>> Linus Walleij
>>
>
> Hi Linus,
>
> I'm ok to have it applied as soon as possible, but I can send a clean non-rfc patch if needed.
>
Acked-by: Kevin Hilman <khilman@baylibre.com>
I was hoping to have a bit clearer info from the vendor, but based on
vendor BSP, I think we have most of the info, and can do the minor
fixups if/when we get detailed documentation.
Kevin
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Kevin Hilman @ 2016-10-31 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d5d1e41-b8e6-5d60-6da1-5b6ddd9bc07e@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Monday 31 October 2016 03:24 PM, Bartosz Golaszewski wrote:
>> 2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>>> Hi Bartosz,
>>>
>>> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>>>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>>>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>>>> Create the driver for the da8xx master peripheral priority
>>>>>> configuration and implement support for writing to the three
>>>>>> Master Priority registers on da850 SoCs.
>>>>>>
>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>>>>> drivers/bus/Kconfig | 9 +
>>>>>> drivers/bus/Makefile | 2 +
>>>>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>>>>> 4 files changed, 297 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..225af09
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>> @@ -0,0 +1,20 @@
>>>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>>>> + priority driver
>>>>>> +
>>>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>>>> +peripherals classified as masters.
>>>>>> +
>>>>>> +Documentation:
>>>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>>>>
>>>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>>>> match.
>>>>
>>>> Hi Rob,
>>>>
>>>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>>>> fixed the example instead.
>>>
>>> Why are master priority registers under syscon? This driver should be
>>> the only entity touching them. So do we need an MFD driver?
>>>
>>
>> It should, but syscfg0 registers are mapped all over the place. I
>
> Not sure what you mean by this. Yes, the sysconfig module has many
> functionalities. But the registers for a given functionality are all
> grouped together AFAICS (except CHIPCFGn, see below).
>
> Pinmux registers are part of syscfg module, but don't use syscon.
>
> In the work going on for OHCI support, chipcfg registers are being put
> under a syscon node. But that makes sense, I think, because chipcfg
> registers are catering to really diverse functionality like PLL and EDMA
> related stuff being placed in the same register - CHIPCFG0.
>
>> thought it would be safer to put them under syscon and Kevin agreed.
>
> Before using syscon for the whole syscfg space, I think we need some
> analysis as to where the likely races are going to be.
I'm OK with that for now. It makes the most sense to use sycon only for
the register (ranges) that will actually be shared.
Kevin
^ permalink raw reply
* [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Rob Herring @ 2016-10-31 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <895cf1ec-929a-8c41-c74a-948efcb89222@opensource.altera.com>
On Mon, Oct 31, 2016 at 10:28 AM, Thor Thayer
<tthayer@opensource.altera.com> wrote:
> Hi Rob,
>
> On 10/31/2016 12:36 AM, Rob Herring wrote:
>>
>> On Thu, Oct 27, 2016 at 03:00:23PM -0500, tthayer at opensource.altera.com
>> wrote:
>>>
>>> From: Thor Thayer <tthayer@opensource.altera.com>
>>>
>>> Add the Arria10 DevKit System Resource Chip register and state
>>> monitoring module to the MFD.
>>>
>>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>>> ---
>>> Note: This needs to be applied to the bindings document that
>>> was Acked & Applied but didn't reach the for-next branch.
>>> See https://patchwork.ozlabs.org/patch/629397/
>>> ---
>>> v2 Change compatible string -mon to -monitor for clarity
>>> ---
>>> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> index ea151f2..c47be28 100644
>>> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>>> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
>>> Device Description
>>> ------ ----------
>>> a10sr_gpio GPIO Controller
>>
>>
>> This should be just "gpio" BTW.
>
>
> I reason I preprend a10sr_ is to distinguish this GPIO from the other GPIOs
> when binding to our LEDs (see below). I think the LEDs need a unique node
> name (unless I'm not understanding something).
You are confusing DTS labels and node names. Labels are global and
just convenience for the DTS source only instead of using full paths
(and can be anything you want). The node name is local to the level it
is at.
> A less important reason I use a10sr_gpio on the node name is that I can cat
> the /sys/class/gpio/gpioxxx/label and see that it is associated with the
> a10sr instead of one of our other general GPIOs. Is there a better way to
> distinguish these?
label should come from the label property I think. This is one of the
problems with the GPIO sysfs interface and why it is being replaced
with the char dev interface.
Rob
>
>>
>>> +a10sr_monitor Register and State Monitoring
>>
>>
>> s/_/-/ or maybe just "monitor". Not really a generic node name to use
>> for this.
>>
>
> The reason I use _ for the node name is that the DTC fails if I reference a
> node name with "-" but works OK for "_". For instance, I get an error if the
> LEDs reference "a10sr-gpio" but "a10sr_gpio" compiles ok.
Again, I'm talking node names. You are talking labels. And yes, DTS
labels can't use '-'.
Rob
^ permalink raw reply
* [PATCH v2] irqchip/bcm2836: Prevent spurious interrupts
From: Thomas Gleixner @ 2016-10-31 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737jcs8mc.fsf@eliezer.anholt.net>
On Mon, 31 Oct 2016, Eric Anholt wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>
> > On Fri, 28 Oct 2016, Eric Anholt wrote:
> >
> >> Thomas Gleixner <tglx@linutronix.de> writes:
> >> > This is missing a fixes tag. I have no idea when that problem was
> >> > introduced, so I have no way to decide whether this needs to be tagged
> >> > stable or not.
> >>
> >> This code has been there since introduction of the driver, so:
> >>
> >> Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")
> >
> > So it want's a stable tag, right?
>
> I'm not the author here, and I was just trying to provide an assist with
> upstreaming, so I'm not going to get too involved. I'd say this is an
> edge case for being a stable tree candidate (it's produces a scary dmesg
> warning but no other functional problems that I know of), and I didn't
> add a fixes tag myself because of that.
A fixes tag is not the same as a stable tag, I really want to see Fixes
tags on patches which are bug fixes as it makes it simple to see the
context in which a bug was introduced.
vs. the stable tag: scary warnings tend to confuse users and cause people
to send bug reports. So in this case I'd add one.
Thanks,
tglx
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-31 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031154622.GB1041@n2100.armlinux.org.uk>
Hi,
On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > > (no IDE host drivers are selected in this config so there is no
> > > > > > valid reason to enable IDE subsystem itself).
> > > > > >
> > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > >
> > > > > I think the series makes a lot of sense. I have checked your assertions
> > > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > > take them all through arm-soc unless there are other concerns.
> > > >
> > > > Thank you.
> > > >
> > > > Should I resend everything or just patches that were not reposted yet
> > > > (the ones that were marked as RFT initially and got no feedback)?
> > >
> > > I'd be fine with just getting a pull request with all the patches that
> > > had no negative feedback and that were not already applied (if any).
> >
> > Here it is (sorry for taking so long).
>
> I've just been digging in the dmesg logs from when I was using the
> Assabet+Neponset as my firewall, and it was having to use the IDE
> ide-cs driver rather than the pata pcmcia driver.
>
> I don't recall whether the pata pcmcia driver was a problem or not,
> as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> think PATA tries to use the "highest" possible access size by
> default...
It doesn't actually - it defaults to 16-bits for PIO data access and
you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
(pata_pcmcia doesn't set it so it should be okay). Also taskfile
registers are accessed using 8-bits access by default transport
functions (which are used by pata_pcmcia).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
From: Scott Branden @ 2016-10-31 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029111229.26875-1-zajec5@gmail.com>
Hi Rafal,
On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> Since early BCM5301X days we got abort handler that was removed by
> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise abort
> fault handler"). It assumed we need to deal only with pending aborts
> left by the bootloader. Unfortunately this isn't true for BCM5301X.
>
> When probing PCI config space (device enumeration) it is expected to
> have master aborts on the PCI bus. Most bridges don't forward (or they
> allow disabling it) these errors onto the AXI/AMBA bus but not the
> Northstar (BCM5301X) one.
Should we only add this workaround code if CONFIG_PCI is on then?
>
> iProc PCIe controller on Northstar seems to be some older one, without
> a control register for errors forwarding. It means we need to workaround
> this at platform level. All newer platforms are not affected by this
> issue.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
> arch/arm/mach-bcm/bcm_5301x.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/mach-bcm/bcm_5301x.c b/arch/arm/mach-bcm/bcm_5301x.c
> index c8830a2..fe067f6 100644
> --- a/arch/arm/mach-bcm/bcm_5301x.c
> +++ b/arch/arm/mach-bcm/bcm_5301x.c
> @@ -9,14 +9,42 @@
> #include <asm/hardware/cache-l2x0.h>
>
> #include <asm/mach/arch.h>
> +#include <asm/siginfo.h>
> +#include <asm/signal.h>
> +
> +#define FSR_EXTERNAL (1 << 12)
> +#define FSR_READ (0 << 10)
> +#define FSR_IMPRECISE 0x0406
>
> static const char *const bcm5301x_dt_compat[] __initconst = {
> "brcm,bcm4708",
> NULL,
> };
>
> +static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
> + struct pt_regs *regs)
> +{
> + /*
> + * We want to ignore aborts forwarded from the PCIe bus that are
> + * expected and shouldn't really be passed by the PCIe controller.
> + * The biggest disadvantage is the same FSR code may be reported when
> + * reading non-existing APB register and we shouldn't ignore that.
> + */
> + if (fsr == (FSR_EXTERNAL | FSR_READ | FSR_IMPRECISE))
> + return 0;
> +
> + return 1;
> +}
> +
> +static void __init bcm5301x_init_early(void)
> +{
> + hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
> + "imprecise external abort");
> +}
> +
> DT_MACHINE_START(BCM5301X, "BCM5301X")
> .l2c_aux_val = 0,
> .l2c_aux_mask = ~0,
> .dt_compat = bcm5301x_dt_compat,
> + .init_early = bcm5301x_init_early,
> MACHINE_END
>
Regards,
Scott
^ permalink raw reply
* [PATCH v14 1/4] clk: mediatek: Add MT2701 clock support
From: Stephen Boyd @ 2016-10-31 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477896558.5376.13.camel@mtksdaap41>
On 10/31, James Liao wrote:
> On Thu, 2016-10-27 at 18:17 -0700, Stephen Boyd wrote:
> > On 10/21, Erin Lo wrote:
> > > @@ -244,3 +256,31 @@ void mtk_clk_register_composites(const struct mtk_composite *mcs,
> > > clk_data->clks[mc->id] = clk;
> > > }
> > > }
> > > +
> > > +void mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
> > > + int num, void __iomem *base, spinlock_t *lock,
> > > + struct clk_onecell_data *clk_data)
> > > +{
> > > + struct clk *clk;
> > > + int i;
> > > +
> > > + for (i = 0; i < num; i++) {
> > > + const struct mtk_clk_divider *mcd = &mcds[i];
> > > +
> > > + if (clk_data && !IS_ERR_OR_NULL(clk_data->clks[mcd->id]))
> >
> > NULL is a valid clk. IS_ERR_OR_NULL is usually wrong.
>
> Why NULL is a valid clk?
Perhaps at some point we'll want to return a NULL pointer to
clk_get() callers so that they can handle things like optional
clocks easily without having any storage requirements. I don't
know if we'll ever do that, but that's just a possibility.
>
> clk_data is designed for multiple initialization from different clock
> types, such as infra_clk_data in clk-mt2701.c. So it will ignore valid
> clocks to avoid duplicated clock registration. Here I assume a clock
> pointer with error code or NULL to be an invalid (not initialized)
> clock.
>
Ok. Would it be possible to initialize the array with all error
pointers? That would make things less error prone, but it
probably doesn't matter at all anyway because this is done during
registration time. IS_ERR_OR_NULL makes me take a second look
each time, because it's usually wrong.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V2 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Eric Anholt @ 2016-10-31 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477848139-32267-1-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> The address of the mailbox node in the bcm283x.dtsi also has a typo.
> So fix it accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Reviewed-by: Andreas F?rber <afaerber@suse.de>
> Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
Pulled to bcm2835-dt-next. Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/becdf39e/attachment.sig>
^ permalink raw reply
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Stefan Wahren @ 2016-10-31 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877f8os8vo.fsf@eliezer.anholt.net>
> Eric Anholt <eric@anholt.net> hat am 31. Oktober 2016 um 18:53 geschrieben:
>
>
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
> > Hi Eric,
> >
> >> Eric Anholt <eric@anholt.net> hat am 27. Oktober 2016 um 18:52 geschrieben:
> >>
> >>
> >> From: Linus Walleij <linus.walleij@linaro.org>
> >>
> >> The idea is to give useful names to GPIO lines that an implementer
> >> will be using from userspace, e.g. for maker type projects. These are
> >> user-visible using tools/gpio/lsgpio.c
> >
> > sorry for the late feedback, but did you check your patch against the
> > Firmware
> > DTS [1]?
> >
> > As an example the GPIO38 is connected and named as USB_LIMIT_1A2 since
> > Raspberry
> > Pi 1 B Plus.
> >
> > [1] -
> > https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts
>
> I did use the dt-blob sometimes for cross-checking, but these are
> written against the schematics, not the dt-blob. If you've got things
> you'd like changed, could you send a patch?
A patch against your v3 or my own v4 based on your patch?
^ 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