* [PATCH v4 06/15] ARM: shmobile: r7s72100 dtsi: Add RSPI nodes
From: Geert Uytterhoeven @ 2014-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390567791-8988-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Cc: devicetree at vger.kernel.org
---
v4:
- Switch to named IRQs
v3:
- No changes
v2:
- No changes
arch/arm/boot/dts/r7s72100.dtsi | 70 +++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ff0bd6be454f..d7013df6bb10 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -34,6 +34,11 @@
gpio10 = &port10;
gpio11 = &port11;
gpio12 = &jtagport0;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ spi2 = &spi2;
+ spi3 = &spi3;
+ spi4 = &spi4;
};
cpus {
@@ -289,4 +294,69 @@
clock-frequency = <100000>;
status = "disabled";
};
+
+ spi0: spi at e800c800 {
+ compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
+ reg = <0xe800c800 0x24>;
+ interrupts = <0 238 IRQ_TYPE_LEVEL_HIGH>,
+ <0 239 IRQ_TYPE_LEVEL_HIGH>,
+ <0 240 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error", "rx", "tx";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi1: spi at e800d000 {
+ compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
+ reg = <0xe800d000 0x24>;
+ interrupts = <0 241 IRQ_TYPE_LEVEL_HIGH>,
+ <0 242 IRQ_TYPE_LEVEL_HIGH>,
+ <0 243 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error", "rx", "tx";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi2: spi at e800d800 {
+ compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
+ reg = <0xe800d800 0x24>;
+ interrupts = <0 244 IRQ_TYPE_LEVEL_HIGH>,
+ <0 245 IRQ_TYPE_LEVEL_HIGH>,
+ <0 246 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error", "rx", "tx";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi3: spi at e800e000 {
+ compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
+ reg = <0xe800e000 0x24>;
+ interrupts = <0 247 IRQ_TYPE_LEVEL_HIGH>,
+ <0 248 IRQ_TYPE_LEVEL_HIGH>,
+ <0 249 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error", "rx", "tx";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi4: spi at e800e800 {
+ compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
+ reg = <0xe800e800 0x24>;
+ interrupts = <0 250 IRQ_TYPE_LEVEL_HIGH>,
+ <0 251 IRQ_TYPE_LEVEL_HIGH>,
+ <0 252 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error", "rx", "tx";
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 05/15] ARM: shmobile: r7s72100 clock: Add RSPI clocks for DT
From: Geert Uytterhoeven @ 2014-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390567791-8988-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Add DT-style ("%08x.spi") clocks, as Genmai doesn't use the common
clock framework yet.
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
v2:
- No changes
arch/arm/mach-shmobile/clock-r7s72100.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r7s72100.c b/arch/arm/mach-shmobile/clock-r7s72100.c
index bf15b63c3d5a..f17a5db00221 100644
--- a/arch/arm/mach-shmobile/clock-r7s72100.c
+++ b/arch/arm/mach-shmobile/clock-r7s72100.c
@@ -194,6 +194,11 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("rspi-rz.2", &mstp_clks[MSTP105]),
CLKDEV_DEV_ID("rspi-rz.3", &mstp_clks[MSTP104]),
CLKDEV_DEV_ID("rspi-rz.4", &mstp_clks[MSTP103]),
+ CLKDEV_DEV_ID("e800c800.spi", &mstp_clks[MSTP107]),
+ CLKDEV_DEV_ID("e800d000.spi", &mstp_clks[MSTP106]),
+ CLKDEV_DEV_ID("e800d800.spi", &mstp_clks[MSTP105]),
+ CLKDEV_DEV_ID("e800e000.spi", &mstp_clks[MSTP104]),
+ CLKDEV_DEV_ID("e800e800.spi", &mstp_clks[MSTP103]),
CLKDEV_DEV_ID("fcfee000.i2c", &mstp_clks[MSTP97]),
CLKDEV_DEV_ID("fcfee400.i2c", &mstp_clks[MSTP96]),
CLKDEV_DEV_ID("fcfee800.i2c", &mstp_clks[MSTP95]),
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 04/15] ARM: shmobile: genmai defconfig: Enable RSPI
From: Geert Uytterhoeven @ 2014-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390567791-8988-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
v2:
- No changes
arch/arm/configs/genmai_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/genmai_defconfig b/arch/arm/configs/genmai_defconfig
index ede35f400df2..401285305251 100644
--- a/arch/arm/configs/genmai_defconfig
+++ b/arch/arm/configs/genmai_defconfig
@@ -79,6 +79,8 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=10
CONFIG_SERIAL_SH_SCI_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C_SH_MOBILE=y
+CONFIG_SPI=y
+CONFIG_SPI_RSPI=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
CONFIG_RCAR_THERMAL=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 03/15] [WIP] ARM: shmobile: genmai legacy: Add preliminary RSPI pinmux setup
From: Geert Uytterhoeven @ 2014-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390567791-8988-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
This does not work yet, as there's no pinmux configuration in
setup-r7s72100.c
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
v4:
- The platform device basename was changed from "rspi" to "rspi-rz"
v3:
- No changes
v2:
- New
arch/arm/mach-shmobile/board-genmai.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c
index 0b01b7f7e240..3d02167967ec 100644
--- a/arch/arm/mach-shmobile/board-genmai.c
+++ b/arch/arm/mach-shmobile/board-genmai.c
@@ -19,6 +19,7 @@
*/
#include <linux/kernel.h>
+#include <linux/pinctrl/machine.h>
#include <linux/platform_device.h>
#include <linux/sh_eth.h>
#include <linux/spi/rspi.h>
@@ -77,9 +78,25 @@ static const struct spi_board_info spi_info[] __initconst = {
},
};
+static const struct pinctrl_map genmai_pinctrl_map[] = {
+ /* RSPI4 */
+ PIN_MAP_MUX_GROUP_DEFAULT("rspi-rz.4", "pfc-r7s72100",
+ "rspi4_rspck_p4_0", "rspi4"),
+ PIN_MAP_MUX_GROUP_DEFAULT("rspi-rz.4", "pfc-r7s72100",
+ "rspi4_ssl0_p4_1", "rspi4"),
+ PIN_MAP_MUX_GROUP_DEFAULT("rspi-rz.4", "pfc-r7s72100",
+ "rspi4_mosi_p4_2", "rspi4"),
+ PIN_MAP_MUX_GROUP_DEFAULT("rspi-rz.4", "pfc-r7s72100",
+ "rspi4_miso_p4_3", "rspi4"),
+};
+
static void __init genmai_add_standard_devices(void)
{
r7s72100_clock_init();
+ pinctrl_register_mappings(genmai_pinctrl_map,
+ ARRAY_SIZE(genmai_pinctrl_map));
+ /* FIXME there's no pinmux configuration in setup-r7s72100.c yet */
+ /* r7s72100_pinmux_init(); */
r7s72100_add_dt_devices();
r7s72100_register_rspi(0);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 02/15] ARM: shmobile: genmai legacy: Add RSPI support
From: Geert Uytterhoeven @ 2014-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390567791-8988-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Add RSPI platform device, resources, platform data, and SPI child.
On this board, only rspi4 is in use. Its bus contains a single device
(a wm8978 audio codec).
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
v4:
- The platform device basename was changed from "rspi" to "rspi-rz",
dropping the platform data flags in the process
- Switch to named IRQs
v3:
- Move platform devices from setup-r7s72100.c to board-genmai.c, as
genmai-reference will use devices instantiated from DT
- Merge with "ARM: shmobile: genmai: Add RSPI children", as this now
touches the same file
- Instantiate SPI children in C on genmai only, as genmai-reference will
instantiate them from DT
v2:
- Correct platform device names ("rspi%u.0" -> "rspi.%u")
- Add missing platform data
- Correct summary (resources -> platform devices)
arch/arm/mach-shmobile/board-genmai.c | 42 +++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c
index a1f6fe1fb06f..0b01b7f7e240 100644
--- a/arch/arm/mach-shmobile/board-genmai.c
+++ b/arch/arm/mach-shmobile/board-genmai.c
@@ -21,6 +21,8 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/sh_eth.h>
+#include <linux/spi/rspi.h>
+#include <linux/spi/spi.h>
#include <mach/common.h>
#include <mach/irqs.h>
#include <mach/r7s72100.h>
@@ -41,11 +43,51 @@ static const struct resource ether_resources[] __initconst = {
DEFINE_RES_IRQ(gic_iid(359)),
};
+/* RSPI */
+#define RSPI_RESOURCE(idx, baseaddr, irq) \
+static const struct resource rspi##idx##_resources[] __initconst = { \
+ DEFINE_RES_MEM(baseaddr, 0x24), \
+ DEFINE_RES_IRQ_NAMED(irq, "error"), \
+ DEFINE_RES_IRQ_NAMED(irq + 1, "rx"), \
+ DEFINE_RES_IRQ_NAMED(irq + 2, "tx"), \
+}
+
+RSPI_RESOURCE(0, 0xe800c800, gic_iid(270));
+RSPI_RESOURCE(1, 0xe800d000, gic_iid(273));
+RSPI_RESOURCE(2, 0xe800d800, gic_iid(276));
+RSPI_RESOURCE(3, 0xe800e000, gic_iid(279));
+RSPI_RESOURCE(4, 0xe800e800, gic_iid(282));
+
+static const struct rspi_plat_data rspi_pdata __initconst = {
+ .num_chipselect = 1,
+};
+
+#define r7s72100_register_rspi(idx) \
+ platform_device_register_resndata(&platform_bus, "rspi-rz", idx, \
+ rspi##idx##_resources, \
+ ARRAY_SIZE(rspi##idx##_resources), \
+ &rspi_pdata, sizeof(rspi_pdata))
+
+static const struct spi_board_info spi_info[] __initconst = {
+ {
+ .modalias = "wm8978",
+ .max_speed_hz = 5000000,
+ .bus_num = 4,
+ .chip_select = 0,
+ },
+};
+
static void __init genmai_add_standard_devices(void)
{
r7s72100_clock_init();
r7s72100_add_dt_devices();
+ r7s72100_register_rspi(0);
+ r7s72100_register_rspi(1);
+ r7s72100_register_rspi(2);
+ r7s72100_register_rspi(3);
+ r7s72100_register_rspi(4);
+ spi_register_board_info(spi_info, ARRAY_SIZE(spi_info));
platform_device_register_resndata(&platform_bus, "r7s72100-ether", -1,
ether_resources,
ARRAY_SIZE(ether_resources),
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 01/15] ARM: shmobile: r7s72100 clock: Add RSPI clocks
From: Geert Uytterhoeven @ 2014-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390567791-8988-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
v4:
- The platform device basename was changed from "rspi" to "rspi-rz"
v3:
- No changes
v2:
- Correct platform device names ("rspi%u" -> "rspi.%u")
arch/arm/mach-shmobile/clock-r7s72100.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-r7s72100.c b/arch/arm/mach-shmobile/clock-r7s72100.c
index 0242ca5f499a..bf15b63c3d5a 100644
--- a/arch/arm/mach-shmobile/clock-r7s72100.c
+++ b/arch/arm/mach-shmobile/clock-r7s72100.c
@@ -22,13 +22,15 @@
#include <mach/common.h>
#include <mach/r7s72100.h>
-/* registers */
+/* Frequency Control Registers */
#define FRQCR 0xfcfe0010
#define FRQCR2 0xfcfe0014
+/* Standby Control Registers */
#define STBCR3 0xfcfe0420
#define STBCR4 0xfcfe0424
#define STBCR7 0xfcfe0430
#define STBCR9 0xfcfe0438
+#define STBCR10 0xfcfe043c
#define PLL_RATE 30
@@ -146,12 +148,20 @@ struct clk div4_clks[DIV4_NR] = {
| CLK_ENABLE_ON_INIT),
};
-enum { MSTP97, MSTP96, MSTP95, MSTP94,
+enum {
+ MSTP107, MSTP106, MSTP105, MSTP104, MSTP103,
+ MSTP97, MSTP96, MSTP95, MSTP94,
MSTP74,
MSTP47, MSTP46, MSTP45, MSTP44, MSTP43, MSTP42, MSTP41, MSTP40,
- MSTP33, MSTP_NR };
+ MSTP33, MSTP_NR
+};
static struct clk mstp_clks[MSTP_NR] = {
+ [MSTP107] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 7, 0), /* RSPI0 */
+ [MSTP106] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 6, 0), /* RSPI1 */
+ [MSTP105] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 5, 0), /* RSPI2 */
+ [MSTP104] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 4, 0), /* RSPI3 */
+ [MSTP103] = SH_CLK_MSTP8(&peripheral1_clk, STBCR10, 3, 0), /* RSPI4 */
[MSTP97] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 7, 0), /* RIIC0 */
[MSTP96] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 6, 0), /* RIIC1 */
[MSTP95] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 5, 0), /* RIIC2 */
@@ -179,6 +189,11 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("cpu_clk", &div4_clks[DIV4_I]),
/* MSTP clocks */
+ CLKDEV_DEV_ID("rspi-rz.0", &mstp_clks[MSTP107]),
+ CLKDEV_DEV_ID("rspi-rz.1", &mstp_clks[MSTP106]),
+ CLKDEV_DEV_ID("rspi-rz.2", &mstp_clks[MSTP105]),
+ CLKDEV_DEV_ID("rspi-rz.3", &mstp_clks[MSTP104]),
+ CLKDEV_DEV_ID("rspi-rz.4", &mstp_clks[MSTP103]),
CLKDEV_DEV_ID("fcfee000.i2c", &mstp_clks[MSTP97]),
CLKDEV_DEV_ID("fcfee400.i2c", &mstp_clks[MSTP96]),
CLKDEV_DEV_ID("fcfee800.i2c", &mstp_clks[MSTP95]),
--
1.7.9.5
^ permalink raw reply related
* [PATCH 00/15] ARM: shmobile: RSPI RZ and QSPI SoC and board integration
From: Geert Uytterhoeven @ 2014-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Simon, Magnus,
This patch series contains SoC and board integration for
1. RSPI in the r7s72100 aka RZ/A1H SoC on the Genmai reference board,
2. QSPI in the r8a7791 aka R-Car M2 SoC on the Koelsch reference board.
It was tested on the r7s72100-based Genmai reference board using loopback
mode, and on the r8a7791-based Koelsch reference board using the Spansion
s25fl512s SPI FLASH.
Actual functioning for some parts may depend on the series "[PATCH 0/14]
spi: rspi: Add support for RZ/A1H, DT, and Quad/Dual on QSPI" I posted
earlier today.
Overview:
[v4 01/15] ARM: shmobile: r7s72100 clock: Add RSPI clocks
[v4 02/15] ARM: shmobile: genmai legacy: Add RSPI support
[v4 03/15] [WIP] ARM: shmobile: genmai legacy: Add preliminary RSPI
pinmux setup
[v2 04/15] ARM: shmobile: genmai defconfig: Enable RSPI
[v2 05/15] ARM: shmobile: r7s72100 clock: Add RSPI clocks for DT
[v4 06/15] ARM: shmobile: r7s72100 dtsi: Add RSPI nodes
[v4 07/15] ARM: shmobile: genmai reference dts: Add RSPI nodes
[v3 08/15] ARM: shmobile: r8a7791 clock: add QSPI clocks
[v3 09/15] ARM: shmobile: koelsch legacy: Add QSPI support
[v3 10/15] ARM: shmobile: koelsch defconfig: Enable RSPI and MTD_M25P80
[v2 11/15] ARM: shmobile: r8a7791 dtsi: Add QSPI node
[v2 12/15] ARM: shmobile: koelsch dts: Add QSPI nodes
[ 13/15] ARM: shmobile: lager legacy: Switch QSPI to named IRQs
[ 14/15] ARM: shmobile: koelsch legacy: Enable Quad SPI transfers for
the SPI FLASH
[ 15/15] ARM: shmobile: koelsch dts: Enable Quad SPI transfers
Earlier versions of these have been posted before in:
"[PATCH V3 0/5] SoC and board integration for RSPI on r7s72100/genmai"
"[PATCH V2 0/4] SoC and board integration for QSPI on r8a7791/koelsch"
"[PATCH 0/9] Renesas RSPI/QSPI DT support"
The series is based on renesas-devel-v3.13-20140124, with pinctrl work
accepted by Linus, Magnus' pinctrl, Wolfram's riic, Simon's sh_eth,
Valentine's i2c, and Laurent's SCIF DT work applied on top.
[Simon: I don't know in which order you will merge these. If you want me
to rebase my patches, just ask! Thanks!]
All of these should be safe to apply, without runtime dependencies on other
parts, except for [14/15] and [15/15]: those must not go in before
"[14/14] spi: rspi: Add support for Quad and Dual SPI Transfers on QSPI",
as this would disable SPI FLASH access (the SPI core rejects Quad SPI slaves
without Quad SPI master support).
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Mark Rutland @ 2014-01-24 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E1AFE8.40601@linaro.org>
On Fri, Jan 24, 2014 at 12:12:24AM +0000, Hanjun Guo wrote:
> Hi Linus,
>
> Sorry for the late reply.
>
> On 2014?01?22? 16:26, Linus Walleij wrote:
> > On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >
> >> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
> >>
> >> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> >> name from the ACPI timer table is matched with all the registered
> >> timer controllers and matching initialisation routine is invoked.
> >>
> >> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
> > to TIMER_OF_DECLARE() and I think this macro, if needed, should
> > be named TIMER_ACPI_DECLARE().
> >
> > The reason is that "clocksource" is a Linux-internal name and this
> > macro pertains to the hardware name in respective system
> > description type.
>
> That make sense to me too, I will update in next version if
> this patch is still needed.
>
> >
> >> +#ifdef CONFIG_ACPI
> >> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
> >> + static const struct acpi_device_id __clksrc_acpi_table_##name \
> >> + __used __section(__clksrc_acpi_table) \
> >> + = { .id = compat, \
> >> + .driver_data = (kernel_ulong_t)fn }
> >> +#else
> >> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
> >> +#endif
> > This hammers down the world to compile one binary for ACPI
> > and one binary for device tree. Maybe that's fine, I don't know.
>
> This is a problem we can have some discussion on it.
> I prefer mutually exclusive ACPI and DT support.
A lot of work has been put into making a single kernel boot everywhere.
It's forced duplicated code to be factored out, and it's made the kernel
more flexible. While it has been painful, it's forced a far higher
quality standard across the board(s).
Having a separate ACPI-capable or DT-capable kernels goes completely
against that, and it's completely broken:
* It doubles the testing effort required for a particular kernel. I can
guarantee that we will miss bugs (even amazingly bad build bugs)
because no-one will be able to test a full suite of kernels.
* It introduces the possibility of completely pointles arbitrary
differences between the two. How long until we see the first bug-fix
that only works in one configuration?
* It creates additional work for distributions, which need to build more
kernels test them, distribute them, and document which platforms which
kernels are supported on. This creates more pain for end-users too.
Eventually we _will_ get fed up with all of those, and we'll have to do
painful invasive work to make the kernel decide at runtime.
Having separate kernels is a lazy shortcut. It's painful for everyone,
leads to a greater maintenance overhead, it's not what we want now and
not what we want in future.
No thanks.
Either the kernel figures out whether or not to deal with ACPI at
runtime, or it doesn't deal with it at all.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support
From: Fabio Estevam @ 2014-01-24 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124115005.GG814@e106331-lin.cambridge.arm.com>
Hi Mark,
On Fri, Jan 24, 2014 at 9:50 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> +
>> + regulators {
>> + compatible = "simple-bus";
>
> This is _not_ a simple bus. It doesn't have the required ranges
> property.
>
> Why do these need to be in a regulators container node? We don't group
> dma controllers under a dmas node, or uarts under a uarts node.
It seems we have this same issue on several imx6 dts files.
Would the below address your suggestion?
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-
index e75e11b..ba35560 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -15,33 +15,29 @@
reg = <0x10000000 0x40000000>;
};
- regulators {
- compatible = "simple-bus";
-
- reg_usb_otg_vbus: usb_otg_vbus {
- compatible = "regulator-fixed";
- regulator-name = "usb_otg_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio3 22 0>;
- enable-active-high;
- };
+ reg_usb_otg_vbus: regulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 0>;
+ enable-active-high;
+ };
- reg_usb_h1_vbus: usb_h1_vbus {
- compatible = "regulator-fixed";
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio1 29 0>;
- enable-active-high;
- };
+ reg_usb_h1_vbus: regulator at 1 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 29 0>;
+ enable-active-high;
+ };
- reg_audio: wm8962_supply {
- compatible = "regulator-fixed";
- regulator-name = "wm8962-supply";
- gpio = <&gpio4 10 0>;
- enable-active-high;
- };
+ reg_audio: regulator at 2 {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8962-supply";
+ gpio = <&gpio4 10 0>;
+ enable-active-high;
};
gpio-keys {
If so, I will prepare some patches to update other dts files.
Thanks,
Fabio Estevam
^ permalink raw reply related
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Mark Rutland @ 2014-01-24 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E1B1DE.5050507@linaro.org>
On Fri, Jan 24, 2014 at 12:20:46AM +0000, Hanjun Guo wrote:
> On 2014?01?22? 19:45, Mark Rutland wrote:
> > On Wed, Jan 22, 2014 at 08:26:50AM +0000, Linus Walleij wrote:
> >> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >>
> >>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
> >>>
> >>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> >>> name from the ACPI timer table is matched with all the registered
> >>> timer controllers and matching initialisation routine is invoked.
> >>>
> >>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> >>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
> >> to TIMER_OF_DECLARE() and I think this macro, if needed, should
> >> be named TIMER_ACPI_DECLARE().
> >>
> >> The reason is that "clocksource" is a Linux-internal name and this
> >> macro pertains to the hardware name in respective system
> >> description type.
> >>
> >>> +#ifdef CONFIG_ACPI
> >>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
> >>> + static const struct acpi_device_id __clksrc_acpi_table_##name \
> >>> + __used __section(__clksrc_acpi_table) \
> >>> + = { .id = compat, \
> >>> + .driver_data = (kernel_ulong_t)fn }
> >>> +#else
> >>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
> >>> +#endif
> >> This hammers down the world to compile one binary for ACPI
> >> and one binary for device tree. Maybe that's fine, I don't know.
> > How does it do that?
> >
> > As far as I could tell CONFIG_ACPI and CONFIG_OF are not mutually
> > exclusive, and this just means that we only build the datastructures for
> > matching from ACPI when CONFIG_ACPI is enabled.
> >
> > Have I missed something?
> >
> > I definitely don't want to see mutually exclusive ACPI and DT support.
>
> ACPI and DT did the same job so I think they should mutually exclusive.
> if we enable both DT and ACPI in one system, this will leading confusions.
ACPI and DT do similar jobs, and we should be mutually exclusive at
runtime. However, they should not be mutually exclusive at compile-time.
Being mutually exclusive at compile-time is just broken. It creates more
work for distributions (who need to ship double the number of kernels),
it increases the number of configurations requiring testing, and it
makes it easier for bugs to be introduced. It's just painful, and
there's no reason for it.
At boot time the kernel needs to decide which to use for hardware
description, and completely ignore the other (which should not be
present, but lets not assume that or inevitably someone will break that
assumption for a quick hack).
The same kernel should boot on a system that has a DTB or a system that
has ACPI tables. On a system that's provided both it should use one or
the other, but not both.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support
From: Mark Rutland @ 2014-01-24 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390555724-9779-1-git-send-email-ashutosh.s@phytec.in>
On Fri, Jan 24, 2014 at 09:28:44AM +0000, Ashutosh singh wrote:
> This patch adds support for USB_OTG on Phytec phyFLEX-i.MX6 Quad module.
>
> Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
> ---
> arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
> arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 22 ++++++++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
> index 7d37ec6..39e69bd 100644
> --- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
> +++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
> @@ -32,3 +32,7 @@
> &usdhc3 {
> status = "okay";
> };
> +
> +&usbotg {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> index 1a3b50d..dcb1d59 100644
> --- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> +++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
> @@ -18,6 +18,19 @@
> memory {
> reg = <0x10000000 0x80000000>;
> };
> +
> + regulators {
> + compatible = "simple-bus";
This is _not_ a simple bus. It doesn't have the required ranges
property.
Why do these need to be in a regulators container node? We don't group
dma controllers under a dmas node, or uarts under a uarts node.
> +
> + reg_usb_otg_vbus: usb_otg_vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio4 15 0>;
> + enable-active-low;
> + };
> + };
> };
Thanks,
Mark.
^ permalink raw reply
* [PATCHv3 30/41] ARM: omap3-n900.dts: add display information
From: Tomi Valkeinen @ 2014-01-24 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121152605.GA5983@earth.universe>
On 2014-01-21 17:26, Sebastian Reichel wrote:
> On Tue, Jan 21, 2014 at 12:57:02PM +0200, Tomi Valkeinen wrote:
>> Add DT data for OMAP3 N900 board. The board has the following
>> displays:
>>
>> lcd: LCD panel connected to OMAP's SDI output
>> tv: analog svideo
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Your dss-dt-review-3 branch boots on my N900 with working display.
>
> Tested-by: Sebastian Reichel <sre@debian.org>
Ok, thanks!
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140124/862ff532/attachment.sig>
^ permalink raw reply
* [PATCH V4 5/5] Documentation: power: reset: Add documentation for generic SYSCON reboot driver
From: Mark Rutland @ 2014-01-24 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390504801-24483-6-git-send-email-fkan@apm.com>
On Thu, Jan 23, 2014 at 07:20:01PM +0000, Feng Kan wrote:
> Add documentation for generic SYSCON reboot driver.
>
> Signed-off-by: Feng Kan <fkan@apm.com>
> ---
> .../bindings/power/reset/syscon-reboot.txt | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
>
> diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
> new file mode 100644
> index 0000000..e9eb1fe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
> @@ -0,0 +1,16 @@
> +Generic SYSCON mapped register reset driver
Bindings should describe hardware, not drivers.
What precisely does this binding describe?
> +
> +Required properties:
> +- compatible: should contain "syscon-reboot"
> +- regmap: this is phandle to the register map node
> +- offset: offset in the register map for the reboot register
> +- mask: the reset value written to the reboot register
> +
> +Examples:
> +
> +reboot {
> + compatible = "syscon-reboot";
> + regmap = <®mapnode>;
> + offset = <0x0>;
> + mask = <0x1>;
> +};
Access size? Endianness?
Why can we not have a binding for the register bank this exists in, and
have that pass on the appropriate details to a syscon-reboot driver?
That way we can change the way we poke things without requiring changes
to bindings or dts.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 2/3] serial: fsl_lpuart: add DMA support
From: Mark Rutland @ 2014-01-24 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390363773-24108-3-git-send-email-yao.yuan@freescale.com>
On Wed, Jan 22, 2014 at 04:09:32AM +0000, Yuan Yao wrote:
> Add dma support for lpuart. This function depend on DMA driver.
> You can turn on it by write both the dmas and dma-name properties in dts node.
>
> Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
> ---
> .../devicetree/bindings/serial/fsl-lpuart.txt | 19 +-
> drivers/tty/serial/fsl_lpuart.c | 430 ++++++++++++++++++++-
> 2 files changed, 433 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> index 6fd1dd1..6e1cbbf 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> @@ -5,10 +5,21 @@ Required properties:
> - reg : Address and length of the register set for the device
> - interrupts : Should contain uart interrupt
>
> +Optional properties:
> +- dmas: Generic dma devicetree binding as described
> + in Documentation/devicetree/bindings/dma/dma.txt.
> +- dma-names: Two dmas have to be defined, "rx" and "tx".
> + An ordered list of channel names affiliated to the above.
Please describe dmas in terms of dma-names (as with the patch describing
clocks and clock-names).
It would be nice to describe the type of the dmas property, but I see
that we have a propblem with inconsistent terminology in the area of
${THING}-specifiers, so I'll try to get that cleaned up separately.
Cheers,
Mark.
^ permalink raw reply
* [PATCH v4 3/3] serial: fsl_lpuart: documented the clock requirement.
From: Mark Rutland @ 2014-01-24 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390363773-24108-4-git-send-email-yao.yuan@freescale.com>
On Wed, Jan 22, 2014 at 04:09:33AM +0000, Yuan Yao wrote:
> It was previously required but not documented.
> Add the text to the binding along with the new "dmas" addition.
>
> Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
> ---
> Documentation/devicetree/bindings/serial/fsl-lpuart.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> index 6e1cbbf..9666f97 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> @@ -4,6 +4,8 @@ Required properties:
> - compatible : Should be "fsl,<soc>-lpuart"
> - reg : Address and length of the register set for the device
> - interrupts : Should contain uart interrupt
> +- clocks : phandle + clock specifier pairs, one for each entry in clock-names
> +- clock-names : should contain: "ipg" - the uart clock
>
> Optional properties:
> - dmas: Generic dma devicetree binding as described
> @@ -19,6 +21,8 @@ uart0: serial at 40027000 {
> compatible = "fsl,vf610-lpuart";
> reg = <0x40027000 0x1000>;
> interrupts = <0 61 0x00>;
> + clocks = <&clks VF610_CLK_UART0>;
> + clock-names = "ipg";
> dmas = <&edma0 0 2>,
> <&edma0 0 3>;
> dma-names = "rx","tx";
As this was a previous requirement, and this is a correction to the
documentation rather than a binding change:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Srikanth Thokala @ 2014-01-24 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0FC22.8060903@metafoo.de>
Hi Lars,
On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
> [...]
>> +/**
>> + * xilinx_vdma_device_control - Configure DMA channel of the device
>> + * @dchan: DMA Channel pointer
>> + * @cmd: DMA control command
>> + * @arg: Channel configuration
>> + *
>> + * Return: '0' on success and failure value on error
>> + */
>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
>> + enum dma_ctrl_cmd cmd, unsigned long arg)
>> +{
>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
>> +
>> + switch (cmd) {
>> + case DMA_TERMINATE_ALL:
>> + xilinx_vdma_terminate_all(chan);
>> + return 0;
>> + case DMA_SLAVE_CONFIG:
>> + return xilinx_vdma_slave_config(chan,
>> + (struct xilinx_vdma_config *)arg);
>
> You really shouldn't be overloading the generic API with your own semantics.
> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
Ok. The driver needs few additional configuration from the slave
device like Vertical
Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
defined for Freescale drivers?
>
>> + default:
>> + return -ENXIO;
>> + }
>> +}
>> +
> [...]
>> +
>> + /* Request the interrupt */
>> + chan->irq = irq_of_parse_and_map(node, 0);
>> + err = devm_request_irq(xdev->dev, chan->irq, xilinx_vdma_irq_handler,
>> + IRQF_SHARED, "xilinx-vdma-controller", chan);
>
> This is a clasic example of where to not use devm_request_irq. 'chan' is
> accessed in the interrupt handler, but if you use devm_request_irq 'chan'
> will be freed before the interrupt handler has been released, which means
> there is now a race condition where the interrupt handler can access already
> freed memory.
Ok, thank you for the clarification on this thread. I will fix it in v3.
>
>> + if (err) {
>> + dev_err(xdev->dev, "unable to request IRQ\n");
>> + return err;
>> + }
>> +
>> + /* Initialize the DMA channel and add it to the DMA engine channels
>> + * list.
>> + */
>> + chan->common.device = &xdev->common;
>> +
>> + list_add_tail(&chan->common.device_node, &xdev->common.channels);
>> + xdev->chan[chan->id] = chan;
>> +
>> + /* Reset the channel */
>> + err = xilinx_vdma_chan_reset(chan);
>> + if (err < 0) {
>> + dev_err(xdev->dev, "Reset channel failed\n");
>> + return err;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * struct of_dma_filter_xilinx_args - Channel filter args
>> + * @dev: DMA device structure
>> + * @chan_id: Channel id
>> + */
>> +struct of_dma_filter_xilinx_args {
>> + struct dma_device *dev;
>> + u32 chan_id;
>> +};
>> +
>> +/**
>> + * xilinx_vdma_dt_filter - VDMA channel filter function
>> + * @chan: DMA channel pointer
>> + * @param: Filter match value
>> + *
>> + * Return: true/false based on the result
>> + */
>> +static bool xilinx_vdma_dt_filter(struct dma_chan *chan, void *param)
>> +{
>> + struct of_dma_filter_xilinx_args *args = param;
>> +
>> + return chan->device == args->dev && chan->chan_id == args->chan_id;
>> +}
>> +
>> +/**
>> + * of_dma_xilinx_xlate - Translation function
>> + * @dma_spec: Pointer to DMA specifier as found in the device tree
>> + * @ofdma: Pointer to DMA controller data
>> + *
>> + * Return: DMA channel pointer on success and NULL on error
>> + */
>> +static struct dma_chan *of_dma_xilinx_xlate(struct of_phandle_args *dma_spec,
>> + struct of_dma *ofdma)
>> +{
>> + struct of_dma_filter_xilinx_args args;
>> + dma_cap_mask_t cap;
>> +
>> + args.dev = ofdma->of_dma_data;
>> + if (!args.dev)
>> + return NULL;
>> +
>> + if (dma_spec->args_count != 1)
>> + return NULL;
>> +
>> + dma_cap_zero(cap);
>> + dma_cap_set(DMA_SLAVE, cap);
>> +
>> + args.chan_id = dma_spec->args[0];
>> +
>> + return dma_request_channel(cap, xilinx_vdma_dt_filter, &args);
>
> There is a new helper function called dma_get_slave_channel, which makes
> this much easier. Take a look at the k3dma.c driver for an example.
Ok. I will check and fix it in v3.
Srikanth
>> +}
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH v5 8/8] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Mark Rutland @ 2014-01-24 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-9-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:52AM +0000, Marc Carino wrote:
> Add a sample DTS which will allow bootup of a board populated
> with the BCM7445 chip.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/boot/dts/bcm7445.dts | 111 +++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 111 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/bcm7445.dts
>
> diff --git a/arch/arm/boot/dts/bcm7445.dts b/arch/arm/boot/dts/bcm7445.dts
> new file mode 100644
> index 0000000..ffa3305
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm7445.dts
> @@ -0,0 +1,111 @@
> +/dts-v1/;
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + model = "Broadcom STB (bcm7445)";
> + compatible = "brcm,bcm7445", "brcm,brcmstb";
> + interrupt-parent = <&gic>;
> +
> + chosen {};
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00 0x00000000 0x00 0x40000000>,
> + <0x00 0x40000000 0x00 0x40000000>,
> + <0x00 0x80000000 0x00 0x40000000>;
> + };
As I commented on v3 [1], these are contiguous and can be described with
a single entry:
memory {
device_type = "memory";
reg = <0x0 0x00000000 0x0 0xc0000000>;
};
Is there any reason to have three entries?
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/225899.html
^ permalink raw reply
* [PATCH v5 6/8] ARM: brcmstb: add misc. DT bindings for brcmstb
From: Mark Rutland @ 2014-01-24 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-7-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:50AM +0000, Marc Carino wrote:
> Document the bindings that the Broadcom STB platform needs
> for proper bootup.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/arm/brcm-brcmstb.txt | 95 ++++++++++++++++++++
> 1 files changed, 95 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
> new file mode 100644
> index 0000000..3c436cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
> @@ -0,0 +1,95 @@
> +ARM Broadcom STB platforms Device Tree Bindings
> +-----------------------------------------------
> +Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
> +SoC shall have the following DT organization:
> +
> +Required root node properties:
> + - compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
> +
> +example:
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + model = "Broadcom STB (bcm7445)";
> + compatible = "brcm,bcm7445", "brcm,brcmstb";
> +
> +Further, syscon nodes that map platform-specific registers used for general
> +system control is required:
> +
> + - compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
> + - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
> + - compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
> +
> +example:
> + rdb {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges = <0 0x00 0xf0000000 0x1000000>;
> +
> + sun_top_ctrl: syscon at 404000 {
> + compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
> + reg = <0x404000 0x51c>;
> + };
> +
> + hif_cpubiuctrl: syscon at 3e2400 {
> + compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
> + reg = <0x3e2400 0x5b4>;
> + };
> +
> + hif_continuation: syscon at 452000 {
> + compatible = "brcm,bcm7445-hif-continuation", "syscon";
> + reg = <0x452000 0x100>;
> + };
> + };
> +
> +Lastly, nodes that allow for support of SMP initialization and reboot are
> +required:
> +
> +smpboot
> +-------
> +Required properties:
> +
> + - compatible
> + The string "brcm,brcmstb-smpboot".
> +
> + - syscon-cpu
> + A phandle / integer array property which lets the BSP know the location
> + of certain CPU power-on registers.
> +
> + The layout of the property is as follows:
> + o a phandle to the "hif_cpubiuctrl" syscon node
> + o offset to the base CPU power zone register
> + o offset to the base CPU reset register
How variable are these values?
> +
> + - syscon-cont
> + A phandle pointing to the syscon node which describes the CPU boot
> + continuation registers.
> + o a phandle to the "hif_continuation" syscon node
> +
> +example:
> + smpboot {
> + compatible = "brcm,brcmstb-smpboot";
> + syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
> + syscon-cont = <&hif_continuation>;
> + };
This looks odd. This doesn't seem like a device, but rather a grouping
of disparate devices used for a particular software purpose.
> +
> +reboot
> +-------
> +Required properties
> +
> + - compatible
> + The string property "brcm,brcmstb-reboot".
> +
> + - syscon
> + A phandle / integer array that points to the syscon node which describes
> + the general system reset registers.
> + o a phandle to "sun_top_ctrl"
> + o offset to the "reset source enable" register
> + o offset to the "software master reset" register
How variable are these values?
> +
> +example:
> + reboot {
> + compatible = "brcm,brcmstb-reboot";
> + syscon = <&sun_top_ctrl 0x304 0x308>;
> + };
As with smpboot, this seems odd.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 3/3] irqchip: orion: clear stale interrupts in irq_enable
From: Russell King - ARM Linux @ 2014-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123225208.GA24778@obsidianresearch.com>
On Thu, Jan 23, 2014 at 03:52:08PM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote:
> > Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
> > IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
> > them before unmask. This installs an .irq_enable callback to ensure stale
> > irqs are cleared before initial unmask.
>
> I'm not sure if putting this in irq_enable is correct. I think this
> should only happen at irq_startup.
>
> The question boils down to what is supposed to happen with this code
> sequence:
>
> disable_irq(..);
> write(.. something to cause an interrupt edge ..);
> .. synchronize ..
> enable_irq(..);
>
> Do we get the interrupt or not?
The answer is... yes, the interrupt should be delivered after the
interrupt is re-enabled.
> I found this message from Linus long ago:
> http://yarchive.net/comp/linux/edge_triggered_interrupts.html
> > Btw, the "disable_irq()/enable_irq()" subsystem has been written so that
> > when you disable an edge-triggered interrupt, and the edge happens while
> > the interrupt is disabled, we will re-play the interrupt at enable time.
> > Exactly so that drivers can have an easier time and don't have to
> > normally worry about whether something is edge or level-triggered.
>
> And found this note in Documentation/DocBook/genericirq.tmpl:
>
> > This prevents losing edge interrupts on hardware which does
> > not store an edge interrupt event while the interrupt is disabled at
> > the hardware level.
>
> So I think it is very clear that the chip driver should not discard
> edges that happened while the interrupt was disabled.
Correct.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v5 4/8] ARM: do CPU-specific init for Broadcom Brahma15 cores
From: Mark Rutland @ 2014-01-24 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-5-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:48AM +0000, Marc Carino wrote:
> Perform any CPU-specific initialization required on the
> Broadcom Brahma-15 core.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/mm/proc-v7.S | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index bd17819..98ea423 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -193,6 +193,7 @@ __v7_cr7mp_setup:
> b 1f
> __v7_ca7mp_setup:
> __v7_ca15mp_setup:
> +__v7_b15mp_setup:
> mov r10, #0
> 1:
> #ifdef CONFIG_SMP
> @@ -494,6 +495,16 @@ __v7_ca15mp_proc_info:
> .size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
>
> /*
> + * Broadcom Corporation Brahma-B15 processor.
> + */
> + .type __v7_b15mp_proc_info, #object
> +__v7_b15mp_proc_info:
> + .long 0x420f00f0
> + .long 0xff0ffff0
> + __v7_proc __v7_b15mp_setup, hwcaps = HWCAP_IDIV
On the third posting, Will Deacon asked if the hwcap override was really
required [1]. Two postings later there's been no answer.
Is your CPUID_EXT_ISAR0 value wrong? If so, please add a comment to that
effect (as with __krait_proc_info).
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/225895.html
^ permalink raw reply
* [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tomi Valkeinen @ 2014-01-24 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
On 2014-01-22 23:08, Ivaylo Dimitrov wrote:
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
I don't know, it wasn't immediately clear to me if the reserved memory
was handled with CMA or not.
Also, we have this funniness that omapfb is not present in DT data, so
we can't give reserved memory to omapfb directly like that.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140124/ee42870f/attachment.sig>
^ permalink raw reply
* [PATCH v5 1/8] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
From: Mark Rutland @ 2014-01-24 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390361452-3124-2-git-send-email-marc.ceeeee@gmail.com>
On Wed, Jan 22, 2014 at 03:30:45AM +0000, Marc Carino wrote:
> The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
>
> This patch adds machine support for the ARM-based Broadcom SoCs.
>
> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> arch/arm/mach-bcm/Kconfig | 14 ++
> arch/arm/mach-bcm/Makefile | 4 +
> arch/arm/mach-bcm/brcmstb.c | 110 ++++++++++++
> arch/arm/mach-bcm/brcmstb.h | 38 ++++
> arch/arm/mach-bcm/headsmp-brcmstb.S | 34 ++++
> arch/arm/mach-bcm/hotplug-brcmstb.c | 334 +++++++++++++++++++++++++++++++++++
> 7 files changed, 535 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-bcm/brcmstb.c
> create mode 100644 arch/arm/mach-bcm/brcmstb.h
> create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
> create mode 100644 arch/arm/mach-bcm/hotplug-brcmstb.c
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index c1df4e9..7028d11 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -7,6 +7,7 @@ CONFIG_MACH_ARMADA_370=y
> CONFIG_MACH_ARMADA_XP=y
> CONFIG_ARCH_BCM=y
> CONFIG_ARCH_BCM_MOBILE=y
> +CONFIG_ARCH_BRCMSTB=y
> CONFIG_GPIO_PCA953X=y
> CONFIG_ARCH_HIGHBANK=y
> CONFIG_ARCH_KEYSTONE=y
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 9fe6d88..2c1ae83 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -31,6 +31,20 @@ config ARCH_BCM_MOBILE
> BCM11130, BCM11140, BCM11351, BCM28145 and
> BCM28155 variants.
>
> +config ARCH_BRCMSTB
> + bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
> + depends on MMU
> + select ARM_GIC
> + select MIGHT_HAVE_PCI
> + select HAVE_SMP
> + select HAVE_ARM_ARCH_TIMER
> + help
> + Say Y if you intend to run the kernel on a Broadcom ARM-based STB
> + chipset.
> +
> + This enables support for Broadcom ARM-based set-top box chipsets,
> + including the 7445 family of chips.
> +
> endmenu
>
> endif
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index c2ccd5a..b744a12 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -13,3 +13,7 @@
> obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
> plus_sec := $(call as-instr,.arch_extension sec,+sec)
> AFLAGS_bcm_kona_smc_asm.o :=-Wa,-march=armv7-a$(plus_sec)
> +
> +obj-$(CONFIG_ARCH_BRCMSTB) := brcmstb.o
> +obj-$(CONFIG_SMP) += headsmp-brcmstb.o
> +obj-$(CONFIG_HOTPLUG_CPU) += hotplug-brcmstb.o
> diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
> new file mode 100644
> index 0000000..7a6093d
> --- /dev/null
> +++ b/arch/arm/mach-bcm/brcmstb.c
> @@ -0,0 +1,110 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/console.h>
> +#include <linux/clocksource.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/jiffies.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/printk.h>
> +#include <linux/smp.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/mach/time.h>
> +
> +#include "brcmstb.h"
> +
> +/***********************************************************************
> + * STB CPU (main application processor)
> + ***********************************************************************/
> +
> +static const char *brcmstb_match[] __initconst = {
> + "brcm,bcm7445",
> + "brcm,brcmstb",
> + NULL
> +};
> +
> +static void __init brcmstb_init_early(void)
> +{
> + add_preferred_console("ttyS", 0, "115200");
> +}
Is this really required?
> +
> +/***********************************************************************
> + * SMP boot
> + ***********************************************************************/
> +
> +#ifdef CONFIG_SMP
> +static DEFINE_SPINLOCK(boot_lock);
> +
> +static void __cpuinit brcmstb_secondary_init(unsigned int cpu)
> +{
> + /*
> + * Synchronise with the boot thread.
> + */
> + spin_lock(&boot_lock);
> + spin_unlock(&boot_lock);
> +}
> +
> +static int __cpuinit brcmstb_boot_secondary(unsigned int cpu,
> + struct task_struct *idle)
> +{
> + /*
> + * set synchronisation state between this boot processor
> + * and the secondary one
> + */
> + spin_lock(&boot_lock);
> +
> + /* Bring up power to the core if necessary */
> + if (brcmstb_cpu_get_power_state(cpu) == 0)
> + brcmstb_cpu_power_on(cpu);
> +
> + brcmstb_cpu_boot(cpu);
> +
> + /*
> + * now the secondary core is starting up let it run its
> + * calibrations, then wait for it to finish
> + */
> + spin_unlock(&boot_lock);
> +
> + return 0;
> +}
> +
> +struct smp_operations brcmstb_smp_ops __initdata = {
> + .smp_prepare_cpus = brcmstb_cpu_ctrl_setup,
> + .smp_secondary_init = brcmstb_secondary_init,
> + .smp_boot_secondary = brcmstb_boot_secondary,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_kill = brcmstb_cpu_kill,
> + .cpu_die = brcmstb_cpu_die,
> +#endif
> +};
> +#endif
> +
> +DT_MACHINE_START(BRCMSTB, "Broadcom STB (Flattened Device Tree)")
> + .dt_compat = brcmstb_match,
> +#ifdef CONFIG_SMP
> + .smp = smp_ops(brcmstb_smp_ops),
> +#endif
> + .init_early = brcmstb_init_early,
> +MACHINE_END
> diff --git a/arch/arm/mach-bcm/brcmstb.h b/arch/arm/mach-bcm/brcmstb.h
> new file mode 100644
> index 0000000..e49bde6
> --- /dev/null
> +++ b/arch/arm/mach-bcm/brcmstb.h
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __BRCMSTB_H__
> +#define __BRCMSTB_H__
> +
> +#if !defined(__ASSEMBLY__)
> +#include <linux/smp.h>
> +#endif
> +
> +#if !defined(__ASSEMBLY__)
> +extern void brcmstb_secondary_startup(void);
> +extern void brcmstb_cpu_boot(unsigned int cpu);
> +extern void brcmstb_cpu_power_on(unsigned int cpu);
> +extern int brcmstb_cpu_get_power_state(unsigned int cpu);
> +extern struct smp_operations brcmstb_smp_ops;
> +#if defined(CONFIG_HOTPLUG_CPU)
> +extern void brcmstb_cpu_die(unsigned int cpu);
> +extern int brcmstb_cpu_kill(unsigned int cpu);
> +void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus);
> +#else
> +static inline void brcmstb_cpu_die(unsigned int cpu) {}
> +static inline int brcmstb_cpu_kill(unsigned int cpu) {}
> +static inline void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus) {}
> +#endif
> +#endif
> +
> +#endif /* __BRCMSTB_H__ */
> diff --git a/arch/arm/mach-bcm/headsmp-brcmstb.S b/arch/arm/mach-bcm/headsmp-brcmstb.S
> new file mode 100644
> index 0000000..57ec438
> --- /dev/null
> +++ b/arch/arm/mach-bcm/headsmp-brcmstb.S
> @@ -0,0 +1,34 @@
> +/*
> + * SMP boot code for secondary CPUs
> + * Based on arch/arm/mach-tegra/headsmp.S
> + *
> + * Copyright (C) 2010 NVIDIA, Inc.
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <asm/assembler.h>
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +
> + .section ".text.head", "ax"
> + __CPUINIT
__CPUINIT is either going or gone by now. This should disappear.
> +
> +ENTRY(brcmstb_secondary_startup)
> + /*
> + * Ensure CPU is in a sane state by disabling all IRQs and switching
> + * into SVC mode.
> + */
> + setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r0
> +
> + bl v7_invalidate_l1
> + b secondary_startup
> +ENDPROC(brcmstb_secondary_startup)
> diff --git a/arch/arm/mach-bcm/hotplug-brcmstb.c b/arch/arm/mach-bcm/hotplug-brcmstb.c
> new file mode 100644
> index 0000000..ff4a732
> --- /dev/null
> +++ b/arch/arm/mach-bcm/hotplug-brcmstb.c
> @@ -0,0 +1,334 @@
> +/*
> + * Broadcom STB CPU hotplug support for ARM
> + *
> + * Copyright (C) 2013 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/jiffies.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/printk.h>
> +#include <linux/regmap.h>
> +#include <linux/smp.h>
> +#include <linux/mfd/syscon.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/mach-types.h>
> +
> +#include "brcmstb.h"
> +
> +enum {
> + ZONE_MAN_CLKEN_MASK = BIT(0),
> + ZONE_MAN_RESET_CNTL_MASK = BIT(1),
> + ZONE_MAN_MEM_PWR_MASK = BIT(4),
> + ZONE_RESERVED_1_MASK = BIT(5),
> + ZONE_MAN_ISO_CNTL_MASK = BIT(6),
> + ZONE_MANUAL_CONTROL_MASK = BIT(7),
> + ZONE_PWR_DN_REQ_MASK = BIT(9),
> + ZONE_PWR_UP_REQ_MASK = BIT(10),
> + ZONE_BLK_RST_ASSERT_MASK = BIT(10),
> + ZONE_PWR_OFF_STATE_MASK = BIT(26),
> + ZONE_PWR_ON_STATE_MASK = BIT(26),
> + ZONE_DPG_PWR_STATE_MASK = BIT(28),
> + ZONE_MEM_PWR_STATE_MASK = BIT(29),
> + ZONE_RESET_STATE_MASK = BIT(31),
> +};
> +
> +static void __iomem *cpubiuctrl_block;
> +static void __iomem *hif_cont_block;
> +static u32 cpu0_pwr_zone_ctrl_reg;
> +static u32 cpu_rst_cfg_reg;
> +static u32 hif_cont_reg;
> +DEFINE_PER_CPU(int, per_cpu_sw_state);
> +
> +static void __iomem *pwr_ctrl_get_base(unsigned int cpu)
> +{
> + void __iomem *base = cpubiuctrl_block + cpu0_pwr_zone_ctrl_reg;
> + base += (cpu * 4);
CPU isn't guaranteed to be the physical CPU ID (MPIDR.Aff*). While it
almost certainly will be, we can't guarantee it in the face of a kexec,
for example.
You can use cpu_logical_map(cpu) to get the physical ID.
> + return base;
> +}
> +
> +static u32 pwr_ctrl_rd(unsigned int cpu)
> +{
> + void __iomem *base = pwr_ctrl_get_base(cpu);
> + return readl_relaxed(base);
> +}
> +
> +static void pwr_ctrl_wr(unsigned int cpu, u32 val)
> +{
> + void __iomem *base = pwr_ctrl_get_base(cpu);
> + writel(val, base);
> +}
> +
> +static void cpu_rst_cfg_set(int cpu, int set)
> +{
> + u32 val;
> + val = readl_relaxed(cpubiuctrl_block + cpu_rst_cfg_reg);
> + if (set)
> + val |= BIT(cpu);
> + else
> + val &= ~BIT(cpu);
Likewise here.
> + writel_relaxed(val, cpubiuctrl_block + cpu_rst_cfg_reg);
> +}
> +
> +static void cpu_set_boot_addr(int cpu, unsigned long boot_addr)
> +{
> + const int reg_ofs = cpu * 8;
And here.
> + writel_relaxed(0, hif_cont_block + hif_cont_reg + reg_ofs);
> + writel_relaxed(boot_addr, hif_cont_block + hif_cont_reg + 4 + reg_ofs);
> +}
> +
> +void brcmstb_cpu_boot(unsigned int cpu)
> +{
> + pr_info("SMP: Booting CPU%d...\n", cpu);
> +
> + /*
> + * set the reset vector to point to the secondary_startup
> + * routine
> + */
> + cpu_set_boot_addr(cpu, virt_to_phys(brcmstb_secondary_startup));
> +
> + flush_cache_all();
Why? What does the new CPU need before its caches are coherent and up?
> +
> + /* unhalt the cpu */
> + cpu_rst_cfg_set(cpu, 0);
> +}
> +
> +void brcmstb_cpu_power_on(unsigned int cpu)
> +{
> + /*
> + * The secondary cores power was cut, so we must go through
> + * power-on initialization.
> + */
> + u32 tmp;
> +
> + pr_info("SMP: Powering up CPU%d...\n", cpu);
> +
> + /* Request zone power up */
> + pwr_ctrl_wr(cpu, ZONE_PWR_UP_REQ_MASK);
> +
> + /* Wait for the power up FSM to complete */
> + do {
> + tmp = pwr_ctrl_rd(cpu);
> + } while (!(tmp & ZONE_PWR_ON_STATE_MASK));
> +
> + per_cpu(per_cpu_sw_state, cpu) = 1;
> +}
> +
> +int brcmstb_cpu_get_power_state(unsigned int cpu)
> +{
> + int tmp = pwr_ctrl_rd(cpu);
> + return (tmp & ZONE_RESET_STATE_MASK) ? 0 : 1;
> +}
> +
> +void __ref brcmstb_cpu_die(unsigned int cpu)
> +{
> + /* Derived from misc_bpcm_arm.c */
> +
> + /* Clear SCTLR.C bit */
> + __asm__(
> + "mrc p15, 0, r0, c1, c0, 0\n"
> + "bic r0, r0, #(1 << 2)\n"
> + "mcr p15, 0, r0, c1, c0, 0\n"
> + : /* no output */
> + : /* no input */
> + : "r0" /* clobber r0 */
> + );
This is odd. Why not allow GCC to allocate the register?
> +
> + /*
> + * Instruction barrier to ensure cache is really disabled before
> + * cleaning/invalidating the caches
> + */
> + isb();
I think you could use:
set_cr(get_cr() & ~CR_C))
Which would do all of the above (including the isb), and will get GCC to
allocate the register.
> +
> + flush_cache_all();
> +
> + /* Invalidate all instruction caches to PoU (ICIALLU) */
> + /* Data sync. barrier to ensure caches have emptied out */
> + __asm__("mcr p15, 0, r0, c7, c5, 0\n" : : : "r0");
> + dsb();
Why do you need to invalidate the I-cache?
> +
> + /*
> + * Clear ACTLR.SMP bit to prevent broadcast TLB messages from reaching
> + * this core
> + */
> + __asm__(
> + "mrc p15, 0, r0, c1, c0, 1\n"
> + "bic r0, r0, #(1 << 6)\n"
> + "mcr p15, 0, r0, c1, c0, 1\n"
> + : /* no output */
> + : /* no input */
> + : "r0" /* clobber r0 */
> + );
Surely you can use an output operand to get GCC to allocate the register
for you?
> +
> + /* Disable all IRQs for this CPU */
> + arch_local_irq_disable();
> +
> + per_cpu(per_cpu_sw_state, cpu) = 0;
Your caches are off at this point, so this could be going straight to
memory. Yet readers of this value aren't cleaning their caches before
reading this, so they could hit a stale cached copy.
> +
> + /*
> + * Final full barrier to ensure everything before this instruction has
> + * quiesced.
> + */
> + isb();
> + dsb();
> +
> + /* Sit and wait to die */
> + wfi();
> +
> + /* We should never get here... */
> + nop();
Why the nop first?
> + panic("Spurious interrupt on CPU %d received!\n", cpu);
> +}
> +
> +int brcmstb_cpu_kill(unsigned int cpu)
> +{
> + u32 tmp;
> +
> + pr_info("SMP: Powering down CPU%d...\n", cpu);
> +
> + while (per_cpu(per_cpu_sw_state, cpu))
> + ;
As this was written to with caches disabled, the cached copy of the
value (which this is reading) could be stale. Surely you need to
clean+invalidate the line for this value each time you read it to give
it a chance to update?
> +
> + /* Program zone reset */
> + pwr_ctrl_wr(cpu, ZONE_RESET_STATE_MASK | ZONE_BLK_RST_ASSERT_MASK |
> + ZONE_PWR_DN_REQ_MASK);
> +
> + /* Verify zone reset */
> + tmp = pwr_ctrl_rd(cpu);
> + if (!(tmp & ZONE_RESET_STATE_MASK))
> + pr_err("%s: Zone reset bit for CPU %d not asserted!\n",
> + __func__, cpu);
> +
> + /* Wait for power down */
> + do {
> + tmp = pwr_ctrl_rd(cpu);
> + } while (!(tmp & ZONE_PWR_OFF_STATE_MASK));
> +
> + /* Settle-time from Broadcom-internal DVT reference code */
> + udelay(7);
> +
> + /* Assert reset on the CPU */
> + cpu_rst_cfg_set(cpu, 1);
> +
> + return 1;
> +}
> +
> +static int __init setup_hifcpubiuctrl_regs(struct device_node *np)
> +{
> + int rc = 0;
> + char *name;
> + int index;
> + struct device_node *syscon_np = NULL;
> +
> + name = "syscon-cpu";
> +
> + syscon_np = of_parse_phandle(np, name, 0);
> + if (!syscon_np) {
> + pr_err("can't find phandle %s\n", name);
> + rc = -EINVAL;
> + goto cleanup;
> + }
> +
> + cpubiuctrl_block = of_iomap(syscon_np, 0);
> + if (!cpubiuctrl_block) {
> + pr_err("iomap failed for cpubiuctrl_block\n");
> + rc = -EINVAL;
> + goto cleanup;
> + }
> +
> + index = 1;
> + rc = of_property_read_u32_index(np, name, index,
> + &cpu0_pwr_zone_ctrl_reg);
The index variable seems rather pointless. Why not just use the value
in-place?
> + if (rc) {
> + pr_err("failed to read %d from %s property (%d)\n", index, name,
> + rc);
It might be better to state _what_ you're looking for (what does the
value represent?).
> + rc = -EINVAL;
> + goto cleanup;
> + }
> +
> + index = 2;
> + rc = of_property_read_u32_index(np, name, index, &cpu_rst_cfg_reg);
Likewise for all of the above.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
From: Tomasz Figa @ 2014-01-24 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1873916.c2IkPH5hCW@phil>
On 24.01.2014 09:03, Heiko St?bner wrote:
> On Thursday 23 January 2014 23:35:29 Tomasz Figa wrote:
>> On 23.01.2014 20:02, Heiko St?bner wrote:
>>> Am Donnerstag, 23. Januar 2014, 19:51:34 schrieb Tomasz Figa:
>>>> On 23.01.2014 19:36, Heiko St?bner wrote:
>>> In general, I want to try establishing some sort of general restart way,
>>> as in the future one dt-board should hopefully be enough to cover all
>>> s3c24xx soc variants.
>>
>> If you make SAMSUNG_WDT_RESET always selected on S3C24XX then I guess
>> it's fine.
>>
>>>> Note that you can make the restart field NULL in mach_desc in board
>>>> files.
>>>
>>> As I said above, this is mainly meant for the dt-case. The legacy-board
>>> files are more or less only secondary, and the affected boards can of
>>> course then have a NULL restart handle :-) .
>>>
>>> So for this the dt-board could simply use the wdt-reset, which then gets
>>> replaced by the ccf-based reset if appropriate.
>>
>> OK. By the way, are there any benefits of using this software reset over
>> watchdog reset? Maybe all S3C24xx could simply use watchdog reset and no
>> special handling of those with swrst would be needed.
>
> According to the manuals I looked at, all S3C24XX SoCs seem to support the
> watchdog reset - I'm not sure why the swrst variant was choosen for the newer
> ones when they were added initially. So yes in theory all of them seem to be
> able to use the watchdog reset.
>
> But in any case the s3c2412 will need its own handling, due to the apparent
> clock problem during resets (mentioned in the code and the manuals of
> s3c2412/s3c2413).
OK. So WDT by default (always selected in Kconfig) and override to SWRST
in clock driver if available should work.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Andreas Herrmann @ 2014-01-24 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123192429.GB26399@alberich>
On Thu, Jan 23, 2014 at 08:24:29PM +0100, Andreas Herrmann wrote:
> On Wed, Jan 22, 2014 at 03:33:52PM +0000, Will Deacon wrote:
> > On Wed, Jan 22, 2014 at 01:54:11PM +0000, Varun Sethi wrote:
> > > > > > Ok, so are you suggesting that we perform the isolation mapping in
> > > > > > arm_smmu_add_device and drop the notifier altogether?
> > > > > I think that should be fine, until we want to delay mapping creation
> > > > > till driver bind time.
> > > >
> > > > Is there a hard dependency on that?
> > > >
> > > Not sure, may be Andreas can answer that.
> >
> > Ok. Andreas? I would have thought doing this *earlier* shouldn't be a
> > problem (the DMA ops must be swizzled before the driver is probed).
>
> Yes, I think, there is no hard dependency.
>
> (But still have to double check whether arm_smmu_add_device can be
> used instead of the notifier. Will finally see this when doing some
> tests.)
I think we have to keep the notifier and delay mapping creation until
device is bound to a driver.
Otherwise we might create mappings for devices which might not be used
at all. Who guarantees that the running kernel will have driver
support for all devices? If there is no driver for a device why create
a mapping for it -- no DMA will happen.
Andreas
^ permalink raw reply
* [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support
From: Ashutosh singh @ 2014-01-24 9:28 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for USB_OTG on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 22 ++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 7d37ec6..39e69bd 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -32,3 +32,7 @@
&usdhc3 {
status = "okay";
};
+
+&usbotg {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index 1a3b50d..dcb1d59 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -18,6 +18,19 @@
memory {
reg = <0x10000000 0x80000000>;
};
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_usb_otg_vbus: usb_otg_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 15 0>;
+ enable-active-low;
+ };
+ };
};
&ecspi3 {
@@ -134,6 +147,7 @@
MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x80000000
MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000 /* SPI NOR chipselect */
MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x80000000 /* PMIC interrupt */
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x80000000 /* USB_OTG_PWR_EN */
>;
};
};
@@ -178,3 +192,11 @@
wp-gpios = <&gpio1 29 0>;
status = "disabled";
};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg_1>;
+ disable-over-current;
+ status = "disabled";
+};
--
1.7.9.5
^ 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