* [v4 4/6] ARM: dt: tegra114: Add new board, Dalmore
From: Hiroshi Doyu @ 2013-01-24 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359025829-22306-1-git-send-email-hdoyu@nvidia.com>
Add a new evaluation board, Dalmore for Tegra 114 family.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/tegra114-dalmore.dts | 21 +++++++++++++++++++++
2 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/tegra114-dalmore.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..88ea9fc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -143,7 +143,8 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra20-ventana.dtb \
tegra20-whistler.dtb \
tegra30-cardhu-a02.dtb \
- tegra30-cardhu-a04.dtb
+ tegra30-cardhu-a04.dtb \
+ tegra114-dalmore.dtb
dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2p-ca5s.dtb \
vexpress-v2p-ca9.dtb \
vexpress-v2p-ca15-tc1.dtb \
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
new file mode 100644
index 0000000..a30aca6
--- /dev/null
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/include/ "tegra114.dtsi"
+
+/ {
+ model = "NVIDIA Tegra114 Dalmore evaluation board";
+ compatible = "nvidia,dalmore", "nvidia,tegra114";
+
+ memory {
+ reg = <0x80000000 0x40000000>;
+ };
+
+ serial at 70006300 {
+ status = "okay";
+ clock-frequency = <408000000>;
+ };
+
+ pmc {
+ nvidia,invert-interrupt;
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [v4 3/6] ARM: dt: tegra114: Add new SoC base, Tegra114 SoC
From: Hiroshi Doyu @ 2013-01-24 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359025829-22306-1-git-send-email-hdoyu@nvidia.com>
Initial support for Tegra 114 SoC. This is expected to be included in
the board DTS files, Tegra 114 SoC based evaluation board family.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 114 +++++++++++++++++++++++++++++++++++++++
1 file changed, 114 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra114.dtsi
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
new file mode 100644
index 0000000..c567916
--- /dev/null
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -0,0 +1,114 @@
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "nvidia,tegra114";
+ interrupt-parent = <&gic>;
+
+ gic: interrupt-controller {
+ compatible = "arm,cortex-a15-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x50041000 0x1000>,
+ <0x50042000 0x1000>,
+ <0x50044000 0x2000>,
+ <0x50046000 0x2000>;
+ interrupts = <1 9 0xf04>;
+ };
+
+ timer at 60005000 {
+ compatible = "nvidia,tegra114-timer", "nvidia,tegra20-timer";
+ reg = <0x60005000 0x400>;
+ interrupts = <0 0 0x04
+ 0 1 0x04
+ 0 41 0x04
+ 0 42 0x04
+ 0 121 0x04
+ 0 122 0x04>;
+ };
+
+ tegra_car: clock {
+ compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ serial at 70006000 {
+ compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
+ reg = <0x70006000 0x40>;
+ reg-shift = <2>;
+ interrupts = <0 36 0x04>;
+ status = "disabled";
+ };
+
+ serial at 70006040 {
+ compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
+ reg = <0x70006040 0x40>;
+ reg-shift = <2>;
+ interrupts = <0 37 0x04>;
+ status = "disabled";
+ };
+
+ serial at 70006200 {
+ compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
+ reg = <0x70006200 0x100>;
+ reg-shift = <2>;
+ interrupts = <0 46 0x04>;
+ status = "disabled";
+ };
+
+ serial at 70006300 {
+ compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
+ reg = <0x70006300 0x100>;
+ reg-shift = <2>;
+ interrupts = <0 90 0x04>;
+ status = "disabled";
+ };
+
+ rtc {
+ compatible = "nvidia,tegra114-rtc", "nvidia,tegra20-rtc";
+ reg = <0x7000e000 0x100>;
+ interrupts = <0 2 0x04>;
+ };
+
+ pmc {
+ compatible = "nvidia,tegra114-pmc", "nvidia,tegra30-pmc";
+ reg = <0x7000e400 0x400>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ };
+
+ cpu at 2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <2>;
+ };
+
+ cpu at 3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <3>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 13 0xf08>,
+ <1 14 0xf08>,
+ <1 11 0xf08>,
+ <1 10 0xf08>;
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [v4 2/6] ARM: tegra: fuse: Add chip ID Tegra114 0x35
From: Hiroshi Doyu @ 2013-01-24 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359025829-22306-1-git-send-email-hdoyu@nvidia.com>
Add tegra_chip_id TEGRA114 0x35
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/mach-tegra/fuse.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-tegra/fuse.h b/arch/arm/mach-tegra/fuse.h
index ff1383d..da78434 100644
--- a/arch/arm/mach-tegra/fuse.h
+++ b/arch/arm/mach-tegra/fuse.h
@@ -37,6 +37,7 @@ enum tegra_revision {
#define TEGRA20 0x20
#define TEGRA30 0x30
+#define TEGRA114 0x35
extern int tegra_sku_id;
extern int tegra_cpu_process_id;
--
1.7.9.5
^ permalink raw reply related
* [v4 1/6] ARM: tegra: Use DT /cpu node to detect number of CPU core
From: Hiroshi Doyu @ 2013-01-24 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359025829-22306-1-git-send-email-hdoyu@nvidia.com>
Tegra SoCs does not use SCU based to detect CPU core numbers but they
use DT /cpu node. If it's not provided or failed, it continues as a
single core.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
Based on the discussion:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140608.html
---
arch/arm/mach-tegra/platsmp.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 3ec7fc4..ee847896 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -177,23 +177,8 @@ done:
return status;
}
-/*
- * Initialise the CPU possible map early - this describes the CPUs
- * which may be present or become present in the system.
- */
static void __init tegra_smp_init_cpus(void)
{
- unsigned int i, ncores = scu_get_core_count(scu_base);
-
- if (ncores > nr_cpu_ids) {
- pr_warn("SMP: %u cores greater than maximum (%u), clipping\n",
- ncores, nr_cpu_ids);
- ncores = nr_cpu_ids;
- }
-
- for (i = 0; i < ncores; i++)
- set_cpu_possible(i, true);
-
set_smp_cross_call(gic_raise_softirq);
}
--
1.7.9.5
^ permalink raw reply related
* [v4 0/6] ARM: Initial support for Tegra114 SoC
From: Hiroshi Doyu @ 2013-01-24 11:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patchset adds initial support for NVIDIA's new Tegra114 SoC
(T114) based on the ARM Cortex-A15 MP. This has the minimal support to
allow the kernel to boot up into shell console. This can be used as a
basis for adding other device drivers for this SoC. Currently there
are 2 evaluation boards available, "Dalmore" and "Pluto".
For those who want to try:
$ make ARCH=arm tegra_defconfig
$ scripts/config -e ARCH_TEGRA_114_SOC -d SMP -d DRM -d SUSPEND \
-d PM_RUNTIME -d CPU_FREQ -d CPU_IDLE -d HOTPLUG_CPU
$ make ARCH=arm menuconfig # if needed to configure more
$ make ARCH=arm all -j9
You may also want to enable CONFIG_ARM_APPENDED_DTB and
CONFIG_ARM_ATAG_DTB_COMPAT if the bootloader doesn't support DT yet.
Verified that this single image booted up with "Dalmore(T114)",
"Pluto(T114)" and "Cardhu(T30)". For "Cardhu(T30)" with this single
image, SPI driver doesn't seem to afford the above configuration , it
hangs at boot-up. With SPI disabled, it's ok.
The following changes since commit ac8963ed5d41573c724ce6c1e17f5182d476f2e6:
ARM: tegra: Add CPU nodes to Tegra30 device tree (2013-01-23 10:16:18 -0700)
are available in the git repository at:
git://nv-tegra.nvidia.com/user/hdoyu/linux.git tegra114-base
for you to fetch changes up to ce08503daaffdffd00e8ebdea8c425d68f287efb:
ARM: tegra: Add initial support for Tegra114 SoC. (2013-01-24 10:10:12 +0200)
----------------------------------------------------------------
v4:
Rebased onto Stephen's for-3.9/soc(inc. CCF)
Removed SCU related pathces.
v3:
Rebased onto next-20130115.
Dropped TSC/arch timer patch.
Use /cpus entry in DT to detect cpu core #.
v2:
Rebased against the latest Stephen Warren's linux-next_common
Add /cpus entry in DT
Add comment to initialize TSC only in secure mode.
Hiroshi Doyu (6):
ARM: tegra: Use DT /cpu node to detect number of CPU core
ARM: tegra: fuse: Add chip ID Tegra114 0x35
ARM: dt: tegra114: Add new SoC base, Tegra114 SoC
ARM: dt: tegra114: Add new board, Dalmore
ARM: dt: tegra114: Add new board, Pluto
ARM: tegra: Add initial support for Tegra114 SoC.
arch/arm/boot/dts/Makefile | 4 +-
arch/arm/boot/dts/tegra114-dalmore.dts | 21 ++++++
arch/arm/boot/dts/tegra114-pluto.dts | 21 ++++++
arch/arm/boot/dts/tegra114.dtsi | 114 +++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Kconfig | 10 +++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/board-dt-tegra114.c | 48 +++++++++++++
arch/arm/mach-tegra/common.c | 1 +
arch/arm/mach-tegra/fuse.h | 1 +
arch/arm/mach-tegra/platsmp.c | 15 ----
10 files changed, 220 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra114-dalmore.dts
create mode 100644 arch/arm/boot/dts/tegra114-pluto.dts
create mode 100644 arch/arm/boot/dts/tegra114.dtsi
create mode 100644 arch/arm/mach-tegra/board-dt-tegra114.c
^ permalink raw reply
* [V5 PATCH 25/26] usb: otg: mv_otg: add device tree support
From: Mark Rutland @ 2013-01-24 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359009530-28182-26-git-send-email-chao.xie@marvell.com>
On Thu, Jan 24, 2013 at 06:38:49AM +0000, Chao Xie wrote:
> All blocks are removed. Add the device tree support for otg.
As with mv_udc, this binding should be documented. Please Cc
devicetree-discuss when you have one.
>
> Signed-off-by: Chao Xie <chao.xie@marvell.com>
> ---
> drivers/usb/otg/mv_otg.c | 128 +++++++++++++++++++++++++++++++++++++--------
> drivers/usb/otg/mv_otg.h | 6 +-
> 2 files changed, 108 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/usb/otg/mv_otg.c b/drivers/usb/otg/mv_otg.c
> index 379df92..3aa7fdc 100644
> --- a/drivers/usb/otg/mv_otg.c
> +++ b/drivers/usb/otg/mv_otg.c
> @@ -17,6 +17,7 @@
> #include <linux/device.h>
> #include <linux/proc_fs.h>
> #include <linux/clk.h>
> +#include <linux/of.h>
> #include <linux/workqueue.h>
> #include <linux/platform_device.h>
>
> @@ -333,7 +334,7 @@ static void mv_otg_update_inputs(struct mv_otg *mvotg)
> else
> otg_ctrl->id = !!(otgsc & OTGSC_STS_USB_ID);
>
> - if (mvotg->pdata->otg_force_a_bus_req && !otg_ctrl->id)
> + if (mvotg->otg_force_a_bus_req && !otg_ctrl->id)
> otg_ctrl->a_bus_req = 1;
>
> otg_ctrl->a_sess_vld = !!(otgsc & OTGSC_STS_A_SESSION_VALID);
> @@ -690,21 +691,69 @@ int mv_otg_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int mv_otg_parse_dt(struct platform_device *pdev,
> + struct mv_otg *mvotg)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + unsigned int clks_num;
> + unsigned int val;
> + int i, ret;
> + const char *clk_name;
> +
> + if (!np)
> + return 1;
> +
> + clks_num = of_property_count_strings(np, "clocks");
> + if (clks_num < 0)
> + return clks_num;
> +
> + mvotg->clk = devm_kzalloc(&pdev->dev,
> + sizeof(struct clk *) * clks_num, GFP_KERNEL);
> + if (mvotg->clk == NULL)
> + return -ENOMEM;
> +
> + for (i = 0; i < clks_num; i++) {
> + ret = of_property_read_string_index(np, "clocks", i,
> + &clk_name);
> + if (ret)
> + return ret;
> + mvotg->clk[i] = devm_clk_get(&pdev->dev, clk_name);
> + if (IS_ERR(mvotg->clk[i]))
> + return PTR_ERR(mvotg->clk[i]);
> + }
Again, it seems a shame there's no devm_of_clk_get.
> +
> + mvotg->clknum = clks_num;
> +
> + ret = of_property_read_u32(np, "extern_attr", &mvotg->extern_attr);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "mode", &mvotg->mode);
> + if (ret)
> + return ret;
I *really* don't like this, for the same reasons I stated in reply to the
mv_udc patch.
> +
> + ret = of_property_read_u32(np, "force_a_bus_req", &val);
> + if (ret)
> + return ret;
> + mvotg->otg_force_a_bus_req = !!val;
In devicetree, the typical way to handle a boolean case like this would be to
have a valueless property. If present, the property is true, if not present
it's considered to default to false:
device at 4000 {
compatible = "manufacturer,some-device";
reg = <0x4000, 0x1000>;
manufacturer,boolean-property; /* no value, true if present */
};
Properties which may only have a meaning on one manufacturer's devices are also
typically prefixed with the manufacturer similarly to compatible strings, e.g.
"mrvl,force-a-bus-req".
There may also be a better name for this property.
> +
> + ret = of_property_read_u32(np, "disable_clock_gating", &val);
> + if (ret)
> + return ret;
> + mvotg->clock_gating = !val;
You can do the same here, but with the logic inverted.
> +
> + return 0;
> +}
> +
> static int mv_otg_probe(struct platform_device *pdev)
> {
> - struct mv_usb_platform_data *pdata = pdev->dev.platform_data;
> struct mv_otg *mvotg;
> struct usb_otg *otg;
> struct resource *r;
> - int retval = 0, clk_i, i;
> + int retval = 0, i;
> size_t size;
>
> - if (pdata == NULL) {
> - dev_err(&pdev->dev, "failed to get platform data\n");
> - return -ENODEV;
> - }
> -
> - size = sizeof(*mvotg) + sizeof(struct clk *) * pdata->clknum;
> + size = sizeof(*mvotg);
> mvotg = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> if (!mvotg) {
> dev_err(&pdev->dev, "failed to allocate memory!\n");
> @@ -718,17 +767,45 @@ static int mv_otg_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, mvotg);
>
> mvotg->pdev = pdev;
> - mvotg->extern_attr = pdata->extern_attr;
> - mvotg->pdata = pdata;
>
> - mvotg->clknum = pdata->clknum;
> - for (clk_i = 0; clk_i < mvotg->clknum; clk_i++) {
> - mvotg->clk[clk_i] = devm_clk_get(&pdev->dev,
> + retval = mv_otg_parse_dt(pdev, mvotg);
> + if (retval > 0) {
> + struct mv_usb_platform_data *pdata = pdev->dev.platform_data;
> + /* no CONFIG_OF */
> + int clk_i = 0;
> +
> + if (pdata == NULL) {
> + dev_err(&pdev->dev, "missing platform_data\n");
> + return -ENODEV;
> + }
> + mvotg->extern_attr = pdata->extern_attr;
> + mvotg->mode = pdata->mode;
> + mvotg->clknum = pdata->clknum;
> + mvotg->otg_force_a_bus_req = pdata->otg_force_a_bus_req;
> + if (pdata->disable_otg_clock_gating)
> + mvotg->clock_gating = 0;
> +
> + size = sizeof(struct clk *) * mvotg->clknum;
> + mvotg->clk = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> + if (mvotg->clk == NULL) {
> + dev_err(&pdev->dev,
> + "failed to allocate memory for clk\n");
> + return -ENOMEM;
> + }
> +
> + for (clk_i = 0; clk_i < mvotg->clknum; clk_i++) {
> + mvotg->clk[clk_i] = devm_clk_get(&pdev->dev,
> pdata->clkname[clk_i]);
> - if (IS_ERR(mvotg->clk[clk_i])) {
> - retval = PTR_ERR(mvotg->clk[clk_i]);
> - return retval;
> + if (IS_ERR(mvotg->clk[clk_i])) {
> + dev_err(&pdev->dev, "failed to get clk %s\n",
> + pdata->clkname[clk_i]);
> + retval = PTR_ERR(mvotg->clk[clk_i]);
> + return retval;
You don't need to go via retval here.
[...]
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: EXYNOS: Add clocks for EXYNOS I2S and PCM I/F
From: Sangsu Park @ 2013-01-24 11:00 UTC (permalink / raw)
To: linux-arm-kernel
Audio Subsystem has own clocks for I2S0 and PCM0 in all EXYNOS series.
This patch add clocks for I2S0 and PCM0 I/F.
Signed-off-by: Sangsu Park <sangsu4u.park@samsung.com>
---
arch/arm/mach-exynos/Makefile | 1 +
arch/arm/mach-exynos/clock-audss.c | 64 ++++++++++++++++++++++++++++++++++++
2 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos/clock-audss.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 7e53a3a..5b6c7c0 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -13,6 +13,7 @@ obj- :=
# Core
obj-$(CONFIG_ARCH_EXYNOS) += common.o
+obj-$(CONFIG_ARCH_EXYNOS) += clock-audss.o
obj-$(CONFIG_ARCH_EXYNOS4) += clock-exynos4.o
obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
diff --git a/arch/arm/mach-exynos/clock-audss.c
b/arch/arm/mach-exynos/clock-audss.c
new file mode 100644
index 0000000..8260185
--- /dev/null
+++ b/arch/arm/mach-exynos/clock-audss.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Clock support for EXYNOS Audio Subsystem
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/err.h>
+#include <linux/io.h>
+
+#include <plat/clock.h>
+#include <plat/s5p-clock.h>
+
+#define EXYNOS_PA_AUDSS (0x03810000)
+
+/* IP Clock Gate 0 Registers */
+#define EXYNOS_AUDSS_CLKGATE_I2SBUS (1<<2)
+#define EXYNOS_AUDSS_CLKGATE_I2SSPECIAL (1<<3)
+#define EXYNOS_AUDSS_CLKGATE_PCMBUS (1<<4)
+#define EXYNOS_AUDSS_CLKGATE_PCMSPECIAL (1<<5)
+#define EXYNOS_AUDSS_CLKGATE_GPIO (1<<6)
+
+static void __iomem *clk_audss_base = 0;
+
+static int exynos_clk_audss_ctrl(struct clk *clk, int enable)
+{
+ if (!clk_audss_base)
+ return ENOMEM;
+
+ return s5p_gatectrl(clk_audss_base, clk, enable);
+}
+
+static struct clk exynos_init_audss_clocks[] = {
+ {
+ .name = "iis",
+ .devname = "samsung-i2s.0",
+ .enable = exynos_clk_audss_ctrl,
+ .ctrlbit = EXYNOS_AUDSS_CLKGATE_I2SSPECIAL |
EXYNOS_AUDSS_CLKGATE_I2SBUS
+ | EXYNOS_AUDSS_CLKGATE_GPIO,
+ }, {
+ .name = "pcm",
+ .devname = "samsung-pcm.0",
+ .enable = exynos_clk_audss_ctrl,
+ .ctrlbit = EXYNOS_AUDSS_CLKGATE_PCMSPECIAL |
EXYNOS_AUDSS_CLKGATE_PCMBUS
+ | EXYNOS_AUDSS_CLKGATE_GPIO,
+ },
+};
+
+void __init exynos_register_audss_clocks(void)
+{
+ clk_audss_base = ioremap(EXYNOS_PA_AUDSS, SZ_4K);
+ if (clk_audss_base == NULL) {
+ pr_err("unable to ioremap for gpio_base1\n");
+ return;
+ }
+
+ s3c_register_clocks(exynos_init_audss_clocks,
ARRAY_SIZE(exynos_init_audss_clocks));
+ s3c_disable_clocks(exynos_init_audss_clocks,
ARRAY_SIZE(exynos_init_audss_clocks));
+}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 6/6] ARM: davinci: da850: add tps6507x regulator DT data
From: Vishwanathrao Badarkhe, Manish @ 2013-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359024920-32190-1-git-send-email-manishv.b@ti.com>
Add tps6507x regulator device tree data to da850-evm by
adding regulator consumers with tightened constraints
and regulator-name.TPS6507x regulator handle can be obtained
by using this regulator name.
Regulator constraints are added as per da850 board file.
Regulator names are given as per maximum output voltage the
regulator is capable to provide.
for e.g. regulator name for dcdc1 is "VDCDC1_3.3V".
Also, add tps6507x PMIC I2C slave device under I2C0 node.
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
arch/arm/boot/dts/da850-evm.dts | 64 +++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 3d8290a..605a13e 100755
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -29,8 +29,72 @@
};
i2c0 at 1c22000 {
status = "okay";
+
+ tps: tps at 48 {
+ reg = <0x48>;
+ };
};
};
+
+ vbat: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ };
+};
+
+/include/ "tps6507x.dtsi"
+
+&tps {
+ vdcdc1_2-supply = <&vbat>;
+ vdcdc3-supply = <&vbat>;
+ vldo1_2-supply = <&vbat>;
+
+ regulators {
+ vdcdc1_reg: regulator at 0 {
+ regulator-name = "VDCDC1_3.3V";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdcdc2_reg: regulator at 1 {
+ regulator-name = "VDCDC2_3.3V";
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,defdcdc_default = <1>;
+ };
+
+ vdcdc3_reg: regulator at 2 {
+ regulator-name = "VDCDC3_1.2V";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,defdcdc_default = <1>;
+ };
+
+ ldo1_reg: regulator at 3 {
+ regulator-name = "LDO1_1.8V";
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <1890000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: regulator at 4 {
+ regulator-name = "LDO2_1.2V";
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
};
&pmx_core {
pinctrl-names = "default";
--
1.7.4.1
^ permalink raw reply related
* [PATCH 5/6] ARM: regulator: add tps6507x device tree data
From: Vishwanathrao Badarkhe, Manish @ 2013-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359024920-32190-1-git-send-email-manishv.b@ti.com>
Add device tree data for tps6507x regulator by adding
all tps6507x regulator nodes. Regulators are initialized
based on compatible name provided in tps6507x DT file.
All tps6507x PMIC regulator device tree nodes are placed
in a separate device tree include file (tps6507x.dtsi).
tps6507x.dtsi file is created using datasheet
http://www.ti.com/lit/ds/symlink/tps65070.pdf
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
arch/arm/boot/dts/tps6507x.dtsi | 47 +++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/tps6507x.dtsi
diff --git a/arch/arm/boot/dts/tps6507x.dtsi b/arch/arm/boot/dts/tps6507x.dtsi
new file mode 100644
index 0000000..4ae483e
--- /dev/null
+++ b/arch/arm/boot/dts/tps6507x.dtsi
@@ -0,0 +1,47 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65070.pdf
+ */
+
+&tps {
+ compatible = "ti,tps6507x";
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vdcdc1_reg: regulator at 0 {
+ reg = <0>;
+ regulator-compatible = "VDCDC1";
+ };
+
+ vdcdc2_reg: regulator at 1 {
+ reg = <1>;
+ regulator-compatible = "VDCDC2";
+ };
+
+ vdcdc3_reg: regulator at 2 {
+ reg = <2>;
+ regulator-compatible = "VDCDC3";
+ };
+
+ ldo1_reg: regulator at 3 {
+ reg = <3>;
+ regulator-compatible = "LDO1";
+ };
+
+ ldo2_reg: regulator at 4 {
+ reg = <4>;
+ regulator-compatible = "LDO2";
+ };
+
+ };
+};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/6] davinci: regulator: tps6507x: add device tree support.
From: Vishwanathrao Badarkhe, Manish @ 2013-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359024920-32190-1-git-send-email-manishv.b@ti.com>
Add device tree based initialization support for
TI's tps6507x regulators.
Add device tree binding document for TI's tps6507x
using datasheet:
http://www.ti.com/lit/ds/symlink/tps65070.pdf
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
Documentation/devicetree/bindings/mfd/tps6507x.txt | 91 +++++++++++++++++++
drivers/regulator/tps6507x-regulator.c | 92 ++++++++++++++++++++
2 files changed, 183 insertions(+), 0 deletions(-)
create mode 100755 Documentation/devicetree/bindings/mfd/tps6507x.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/Documentation/devicetree/bindings/mfd/tps6507x.txt
new file mode 100755
index 0000000..8fffa3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
@@ -0,0 +1,91 @@
+TPS6507x Power Management Integrated Circuit
+
+Required properties:
+- compatible: "ti,tps6507x"
+- reg: I2C slave address
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Not all regulators for the
+ given device need to be present. The definition for each of these nodes
+ is defined using the standard binding for regulators found at
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+ The regulator is matched with the regulator-compatible.
+
+ The valid regulator-compatible values are:
+ tps6507x: vdcdc1, vdcdc2, vdcdc3, vldo1, vldo2
+- xxx-supply: Input voltage supply regulator.
+ These entries are required if regulators are enabled for a device.
+ Missing of these properties can cause the regulator registration
+ fails.
+ If some of input supply is powered through battery or always-on
+ supply then also it is require to have these parameters with proper
+ node handle of always on power supply.
+ tps6507x:
+ vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
+ vindcdc3-supply : VDCDC3 input.
+ vldo1_2-supply : VLDO1 and VLDO2 input.
+
+Regulator Optional properties:
+- defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
+ 0: If defdcdc pin of DCDC2/DCDC3 is pulled to GND.
+ 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
+ If this property is not defined, it defaults to 0 (not enabled).
+
+Example:
+
+ pmu: tps6507x at 48 {
+ compatible = "ti,tps6507x";
+ reg = <0x48>;
+
+ vindcdc1_2-supply = <&vbat>;
+ vindcdc3-supply = <...>;
+ vinldo1_2-supply = <...>;
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vdcdc1_reg: regulator at 0 {
+ regulator-compatible = "VDCDC1";
+ reg = <0>;
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ vdcdc2_reg: regulator at 1 {
+ regulator-compatible = "VDCDC2";
+ reg = <1>;
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <3450000>;
+ regulator-always-on;
+ regulator-boot-on;
+ defdcdc_default = <1>;
+ };
+ vdcdc3_reg: regulator at 2 {
+ regulator-compatible = "VDCDC3";
+ reg = <2>;
+ regulator-min-microvolt = <950000>
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+ defdcdc_default = <1>;
+ };
+ ldo1_reg: regulator at 3 {
+ regulator-compatible = "LDO1";
+ reg = <3>;
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <1890000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ ldo2_reg: regulator at 4 {
+ regulator-compatible = "LDO2";
+ reg = <4>;
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+
+ };
diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c
index 0233cfb..afdeb65 100644
--- a/drivers/regulator/tps6507x-regulator.c
+++ b/drivers/regulator/tps6507x-regulator.c
@@ -23,8 +23,10 @@
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/tps6507x.h>
+#include <linux/of.h>
#include <linux/slab.h>
#include <linux/mfd/tps6507x.h>
+#include <linux/regulator/of_regulator.h>
/* DCDC's */
#define TPS6507X_DCDC_1 0
@@ -356,6 +358,80 @@ static struct regulator_ops tps6507x_pmic_ops = {
.list_voltage = regulator_list_voltage_table,
};
+#ifdef CONFIG_OF
+static struct of_regulator_match tps6507x_matches[] = {
+ { .name = "VDCDC1"},
+ { .name = "VDCDC2"},
+ { .name = "VDCDC3"},
+ { .name = "LDO1"},
+ { .name = "LDO2"},
+};
+
+static struct tps6507x_board *tps6507x_parse_dt_reg_data(
+ struct platform_device *pdev,
+ struct of_regulator_match **tps6507x_reg_matches)
+{
+ struct tps6507x_board *tps_board;
+ struct device_node *np = pdev->dev.parent->of_node;
+ struct device_node *regulators;
+ struct of_regulator_match *matches;
+ static struct regulator_init_data *reg_data;
+ int idx = 0, count, ret;
+
+ tps_board = devm_kzalloc(&pdev->dev, sizeof(*tps_board),
+ GFP_KERNEL);
+ if (!tps_board) {
+ dev_err(&pdev->dev, "Failure to alloc pdata for regulators.\n");
+ return NULL;
+ }
+
+ regulators = of_find_node_by_name(np, "regulators");
+ if (!regulators) {
+ dev_err(&pdev->dev, "regulator node not found\n");
+ return NULL;
+ }
+
+ count = ARRAY_SIZE(tps6507x_matches);
+ matches = tps6507x_matches;
+
+ ret = of_regulator_match(pdev->dev.parent, regulators, matches, count);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Error parsing regulator init data: %d\n",
+ ret);
+ return NULL;
+ }
+
+ *tps6507x_reg_matches = matches;
+
+ reg_data = devm_kzalloc(&pdev->dev, (sizeof(struct regulator_init_data)
+ * TPS6507X_NUM_REGULATOR), GFP_KERNEL);
+ if (!reg_data) {
+ dev_err(&pdev->dev, "Failure to alloc init data for regulators.\n");
+ return NULL;
+ }
+
+ tps_board->tps6507x_pmic_init_data = reg_data;
+
+ for (idx = 0; idx < count; idx++) {
+ if (!matches[idx].init_data || !matches[idx].of_node)
+ continue;
+
+ memcpy(®_data[idx], matches[idx].init_data,
+ sizeof(struct regulator_init_data));
+
+ }
+
+ return tps_board;
+}
+#else
+static inline struct tps6507x_board *tps6507x_parse_dt_reg_data(
+ struct platform_device *pdev,
+ struct of_regulator_match **tps6507x_reg_matches)
+{
+ *tps6507x_reg_matches = NULL;
+ return NULL;
+}
+#endif
static int tps6507x_pmic_probe(struct platform_device *pdev)
{
struct tps6507x_dev *tps6507x_dev = dev_get_drvdata(pdev->dev.parent);
@@ -365,8 +441,10 @@ static int tps6507x_pmic_probe(struct platform_device *pdev)
struct regulator_dev *rdev;
struct tps6507x_pmic *tps;
struct tps6507x_board *tps_board;
+ struct of_regulator_match *tps6507x_reg_matches = NULL;
int i;
int error;
+ unsigned int prop;
/**
* tps_board points to pmic related constants
@@ -374,6 +452,9 @@ static int tps6507x_pmic_probe(struct platform_device *pdev)
*/
tps_board = dev_get_platdata(tps6507x_dev->dev);
+ if (!tps_board && tps6507x_dev->dev->of_node)
+ tps_board = tps6507x_parse_dt_reg_data(pdev,
+ &tps6507x_reg_matches);
if (!tps_board)
return -EINVAL;
@@ -415,6 +496,17 @@ static int tps6507x_pmic_probe(struct platform_device *pdev)
config.init_data = init_data;
config.driver_data = tps;
+ if (tps6507x_reg_matches) {
+ error = of_property_read_u32(
+ tps6507x_reg_matches[i].of_node,
+ "ti,defdcdc_default", &prop);
+
+ if (!error)
+ tps->info[i]->defdcdc_default = prop;
+
+ config.of_node = tps6507x_reg_matches[i].of_node;
+ }
+
rdev = regulator_register(&tps->desc[i], &config);
if (IS_ERR(rdev)) {
dev_err(tps6507x_dev->dev,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/6] davinci: mfd: tps6507x: add device-tree support.
From: Vishwanathrao Badarkhe, Manish @ 2013-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359024920-32190-1-git-send-email-manishv.b@ti.com>
Add device tree based initialization support for TI's
tps6507x mfd device.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
drivers/mfd/tps6507x.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
index 409afa2..5ad4b77 100644
--- a/drivers/mfd/tps6507x.c
+++ b/drivers/mfd/tps6507x.c
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/i2c.h>
+#include <linux/of_device.h>
#include <linux/mfd/core.h>
#include <linux/mfd/tps6507x.h>
@@ -116,11 +117,19 @@ static const struct i2c_device_id tps6507x_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, tps6507x_i2c_id);
+#ifdef CONFIG_OF
+static struct of_device_id tps6507x_of_match[] = {
+ {.compatible = "ti,tps6507x", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tps6507x_of_match);
+#endif
static struct i2c_driver tps6507x_i2c_driver = {
.driver = {
.name = "tps6507x",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(tps6507x_of_match),
},
.probe = tps6507x_i2c_probe,
.remove = tps6507x_i2c_remove,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/6] ARM: davinci: da850: add OF_DEV_AUXDATA entry for I2C0
From: Vishwanathrao Badarkhe, Manish @ 2013-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359024920-32190-1-git-send-email-manishv.b@ti.com>
Add OF_DEV_AUXDATA for I2C0 controller driver in da850 board
dt file to use I2C0 clock.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..100d644 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_evm_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da850_evm_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/6] davinci: support for i2c0 and tps6507x
From: Vishwanathrao Badarkhe, Manish @ 2013-01-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
This patch series enables device tree support for I2C0 and
for regulator via tps6507x mfd device on da850-evm.
Applies on top of v3.8-rc4 of linus tree.
Tested on da850-evm device.
Test procedure followed as below:
Once device boots up, issue command as:
$for reg in /sys/class/regulator/*; do echo $reg `cat $reg/name`
`cat $reg/state` `cat $reg/microvolts`; done
This command will print all available regulators with its name,
status (enabled/disabled) and voltages(in microvolts) like as below:
/sys/class/regulator/regulator.1 VDCDC1_3.3V enabled 3300000
/sys/class/regulator/regulator.2 VDCDC2_3.3V enabled 3300000
/sys/class/regulator/regulator.3 VDCDC3_1.2V enabled 1200000
/sys/class/regulator/regulator.4 LDO1_1.8V enabled 1800000
/sys/class/regulator/regulator.5 LDO2_1.2V enabled 1200000
Vishwanathrao Badarkhe, Manish (6):
ARM: davinci: da850: add OF_DEV_AUXDATA entry for I2C0
ARM: davinci: da850: add DT node for I2C0
davinci: mfd: tps6507x: add device-tree support.
davinci: regulator: tps6507x: add device tree support.
ARM: regulator: add tps6507x device tree data
ARM: davinci: da850: add tps6507x regulator DT data
Documentation/devicetree/bindings/mfd/tps6507x.txt | 91 +++++++++++++++++++
arch/arm/boot/dts/da850-evm.dts | 79 +++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 10 ++
arch/arm/boot/dts/tps6507x.dtsi | 47 ++++++++++
arch/arm/mach-davinci/da8xx-dt.c | 8 ++-
drivers/mfd/tps6507x.c | 9 ++
drivers/regulator/tps6507x-regulator.c | 92 ++++++++++++++++++++
7 files changed, 335 insertions(+), 1 deletions(-)
create mode 100755 Documentation/devicetree/bindings/mfd/tps6507x.txt
create mode 100644 arch/arm/boot/dts/tps6507x.dtsi
--
1.7.4.1
^ permalink raw reply
* [V5 PATCH 24/26] usb: gadget: mv_udc: add device tree support
From: Mark Rutland @ 2013-01-24 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359009530-28182-25-git-send-email-chao.xie@marvell.com>
Hello,
On Thu, Jan 24, 2013 at 06:38:48AM +0000, Chao Xie wrote:
> In original driver, we have callbacks in platform data, and some
> dynamically allocations variables in platform data.
> Now, these blocks are removed, the device tree support is easier
> now.
Please could you also add a binding document? See
Documentation/devicetree/bindings/usb for examples of existing bindings.
Also, please Cc devicetree-discuss when introducing a new binding as you are
doing here.
>
> Signed-off-by: Chao Xie <chao.xie@marvell.com>
> ---
> drivers/usb/gadget/mv_udc.h | 5 +-
> drivers/usb/gadget/mv_udc_core.c | 106 ++++++++++++++++++++++++++++++--------
> 2 files changed, 86 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
> index 50ae7c7..de84722 100644
> --- a/drivers/usb/gadget/mv_udc.h
> +++ b/drivers/usb/gadget/mv_udc.h
> @@ -179,6 +179,7 @@ struct mv_udc {
> int irq;
>
> unsigned int extern_attr;
> + unsigned int mode;
> struct notifier_block notifier;
>
> struct mv_cap_regs __iomem *cap_regs;
> @@ -222,11 +223,9 @@ struct mv_udc {
> struct mv_usb2_phy *phy;
> struct usb_phy *transceiver;
>
> - struct mv_usb_platform_data *pdata;
> -
> /* some SOC has mutiple clock sources for USB*/
> unsigned int clknum;
> - struct clk *clk[0];
> + struct clk **clk;
> };
>
> /* endpoint data structure */
> diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
> index 2e5907f..a4ee9a1 100644
> --- a/drivers/usb/gadget/mv_udc_core.c
> +++ b/drivers/usb/gadget/mv_udc_core.c
> @@ -34,6 +34,7 @@
> #include <linux/irq.h>
> #include <linux/platform_device.h>
> #include <linux/clk.h>
> +#include <linux/of.h>
> #include <linux/platform_data/mv_usb.h>
> #include <linux/usb/mv_usb2.h>
> #include <asm/unaligned.h>
> @@ -2153,21 +2154,57 @@ static int mv_udc_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int mv_udc_parse_dt(struct platform_device *pdev,
> + struct mv_udc *udc)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + unsigned int clks_num;
> + int i, ret;
> + const char *clk_name;
> +
> + if (!np)
> + return 1;
> +
> + clks_num = of_property_count_strings(np, "clocks");
> + if (clks_num < 0)
> + return clks_num;
> +
> + udc->clk = devm_kzalloc(&pdev->dev,
> + sizeof(struct clk *) * clks_num, GFP_KERNEL);
> + if (udc->clk == NULL)
> + return -ENOMEM;
> +
> + for (i = 0; i < clks_num; i++) {
> + ret = of_property_read_string_index(np, "clocks", i,
> + &clk_name);
> + if (ret)
> + return ret;
> + udc->clk[i] = devm_clk_get(&pdev->dev, clk_name);
> + if (IS_ERR(udc->clk[i]))
> + return PTR_ERR(udc->clk[i]);
I was going to ask if you couldn't use of_clk_get, but I see you want to use
the devm_* functions to handle cleanup. It seems a shame there's not a standard
devm_of_clk_get.
> + }
> +
> + udc->clknum = clks_num;
> +
> + ret = of_property_read_u32(np, "extern_attr", &udc->extern_attr);
> + if (ret)
> + return ret;
This looks like a *very* bad idea. The udc::extern_attr field seems to be a set
of flags, which this could reads in directly (without any sanity checking),
effectively making it an undocumented ABI. This might be better as a set of
valueless properties.
Will unsigned int be the same as u32 on all platforms this could be used on?
If not, you're passing the wrong type into of_property_read_u32.
Additionally, in devicetree, '-' is used in preference of '_' in compatible
and property names.
> +
> + ret = of_property_read_u32(np, "mode", &udc->mode);
> + if (ret)
> + return ret;
If I've understood correctly, this property will either be MV_USB_MODE_OTG (0)
or MV_USB_MODE_OTG (1). Again, I don't think this is good to be exported as an
ABI, especially as nothing in the enum definition points out that this affects
anything outside the kernel.
If this isn't something that wants to be changed at runtime, this should
probably be a string property, with "host" and "otg" as valid values. Looking
in Documentation/devicetree, the nvidia,tegra20-ehci binding uses similar
strings in its dr_mode property. There may be other (undocumented) precedents.
> +
> + return 0;
> +}
> +
> static int mv_udc_probe(struct platform_device *pdev)
> {
> - struct mv_usb_platform_data *pdata = pdev->dev.platform_data;
> struct mv_udc *udc;
> int retval = 0;
> - int clk_i = 0;
> struct resource *r;
> size_t size;
>
> - if (pdata == NULL) {
> - dev_err(&pdev->dev, "missing platform_data\n");
> - return -ENODEV;
> - }
> -
> - size = sizeof(*udc) + sizeof(struct clk *) * pdata->clknum;
> + size = sizeof(*udc);
> udc = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> if (udc == NULL) {
> dev_err(&pdev->dev, "failed to allocate memory for udc\n");
> @@ -2175,14 +2212,43 @@ static int mv_udc_probe(struct platform_device *pdev)
> }
>
> udc->done = &release_done;
> - udc->extern_attr = pdata->extern_attr;
> - udc->pdata = pdev->dev.platform_data;
> spin_lock_init(&udc->lock);
>
> udc->dev = pdev;
>
> + retval = mv_udc_parse_dt(pdev, udc);
> + if (retval > 0) {
> + /* no CONFIG_OF */
> + struct mv_usb_platform_data *pdata = pdev->dev.platform_data;
> + int clk_i = 0;
> +
> + if (pdata == NULL) {
> + dev_err(&pdev->dev, "missing platform_data\n");
> + return -ENODEV;
> + }
> + udc->extern_attr = pdata->extern_attr;
> + udc->mode = pdata->mode;
> + udc->clknum = pdata->clknum;
> +
> + size = sizeof(struct clk *) * udc->clknum;
> + udc->clk = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> + if (udc->clk == NULL)
> + return -ENOMEM;
> + for (clk_i = 0; clk_i < udc->clknum; clk_i++) {
> + udc->clk[clk_i] = devm_clk_get(&pdev->dev,
> + pdata->clkname[clk_i]);
> + if (IS_ERR(udc->clk[clk_i])) {
> + retval = PTR_ERR(udc->clk[clk_i]);
> + return retval;
Why not just return PTR_ERR(udc->clk[clk_i]); ?
> + }
> + }
> + } else if (retval < 0) {
> + dev_err(&pdev->dev, "error parse dt\n");
> + return retval;
> + }
> +
> #ifdef CONFIG_USB_OTG_UTILS
> - if (pdata->mode == MV_USB_MODE_OTG) {
> + if (udc->mode == MV_USB_MODE_OTG) {
> udc->transceiver = devm_usb_get_phy(&pdev->dev,
> USB_PHY_TYPE_USB2);
> if (IS_ERR_OR_NULL(udc->transceiver)) {
> @@ -2191,17 +2257,6 @@ static int mv_udc_probe(struct platform_device *pdev)
> }
> }
> #endif
> -
> - udc->clknum = pdata->clknum;
> - for (clk_i = 0; clk_i < udc->clknum; clk_i++) {
> - udc->clk[clk_i] = devm_clk_get(&pdev->dev,
> - pdata->clkname[clk_i]);
> - if (IS_ERR(udc->clk[clk_i])) {
> - retval = PTR_ERR(udc->clk[clk_i]);
> - return retval;
> - }
> - }
> -
> r = platform_get_resource(udc->dev, IORESOURCE_MEM, 0);
> if (r == NULL) {
> dev_err(&pdev->dev, "no I/O memory resource defined\n");
> @@ -2466,6 +2521,12 @@ static void mv_udc_shutdown(struct platform_device *pdev)
> mv_udc_disable(udc);
> }
>
> +static struct of_device_id mv_udc_dt_ids[] = {
> + { .compatible = "mrvl,mv-udc" },
This compatible string should be listed in the binding document you generate to
accompany this.
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mv_udc_dt_ids);
> +
> static struct platform_driver udc_driver = {
> .probe = mv_udc_probe,
> .remove = mv_udc_remove,
> @@ -2476,6 +2537,7 @@ static struct platform_driver udc_driver = {
> #ifdef CONFIG_PM
> .pm = &mv_udc_pm_ops,
> #endif
> + .of_match_table = mv_udc_dt_ids,
> },
> };
>
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Thanks,
Mark.
^ permalink raw reply
* [PATCH 7/9] ARM: at91/at91_dt_defconfig: remove memory specification to cmdline
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-01-24 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5100F4ED.9000004@atmel.com>
On 09:46 Thu 24 Jan , Nicolas Ferre wrote:
> On 01/23/2013 11:20 AM, Jean-Christophe PLAGNIOL-VILLARD :
> > On 10:48 Wed 23 Jan , Nicolas Ferre wrote:
> >> No need for this cmdline option as we are using DT.
> >> Moreover this defconfig is targeted to multiple SoC/boards: this option
> >> was nonsense.
> > just keep the console the rest is a nonsense too
> >
> > as on 9g45 the initrd will be at 0x7xxxxxxx
>
> Understood, but I prefer to keep a "root" option at least, so I keep it
> like this.
>
> > the console too but as the patch serie to support via DT is not yet mainline
> > we can keep it
>
> Ok for this.
I check and the default commande line in the defconfig is a nonsense now
as we will provide a default one via dt anyway
and the root option will not work on 9g45
so it's better to simply drop it
Best Regards,
J.
>
> >
> > Best Regards,
> > J.
> >>
> >> Reported-by: Josh Wu <josh.wu@atmel.com>
> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >> ---
> >> arch/arm/configs/at91_dt_defconfig | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig
> >> index b175577..a353ff6 100644
> >> --- a/arch/arm/configs/at91_dt_defconfig
> >> +++ b/arch/arm/configs/at91_dt_defconfig
> >> @@ -31,7 +31,7 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
> >> CONFIG_ZBOOT_ROM_BSS=0x0
> >> CONFIG_ARM_APPENDED_DTB=y
> >> CONFIG_ARM_ATAG_DTB_COMPAT=y
> >> -CONFIG_CMDLINE="mem=128M console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
> >> +CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
> >> CONFIG_KEXEC=y
> >> CONFIG_AUTO_ZRELADDR=y
> >> # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> >> --
> >> 1.8.0
> >>
> >
> >
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* [PATCH] i2c: at91: add of_device_id entry for at91rm9200
From: ludovic.desroches @ 2013-01-24 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124101356.GA12933@pengutronix.de>
On 01/24/2013 11:13 AM, Wolfram Sang wrote:
> Hi,
>
>> I didn't add this when I did the rework because there was no DT tree
>> support for RM9200. The configuration for RM9200 IP is already in
>> the driver and used for non DT platform so I think it makes sense to
>> add this.
>
> I agree. If it is usable for non-dt, it should be usable for dt. If it
> makes sense is left to the user.
>
> Interpreted Ludovic's comment as ack and applied to -next, thanks!
>
Yes it is, thanks.
Regards
Ludovic
^ permalink raw reply
* [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
From: Hebbar, Gururaja @ 2013-01-24 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124101301.GG4955@opensource.wolfsonmicro.com>
On Thu, Jan 24, 2013 at 15:43:03, Mark Brown wrote:
> On Thu, Jan 24, 2013 at 10:06:42AM +0000, Hebbar, Gururaja wrote:
>
> > What I meant was that by using this macro (SND_SOC_DAPM_POST_PMU &
> > SND_SOC_DAPM_PRE_PMD) I can just save and restore existing voltage values inside
> > the event. They will not be user configurable (available to user through some widget).
>
> Well, you *could* add separate register control for that
That?s what I am doing using a different register control
+static const char *mic_bias_level_txt[] = { "off", "2V", "2.5V", "AVDD" };
+
+static const struct soc_enum mic_bias_level =
+SOC_ENUM_SINGLE(MICBIAS_CTRL, 6, 4, mic_bias_level_txt);
+
static const struct snd_kcontrol_new aic3x_snd_controls[] = {
/* Output */
SOC_DOUBLE_R_TLV("PCM Playback Volume",
@@ -391,6 +396,9 @@ static const struct snd_kcontrol_new aic3x_snd_controls[] = {
SOC_DOUBLE_R("PGA Capture Switch", LADC_VOL, RADC_VOL, 7, 0x01, 1),
SOC_ENUM("ADC HPF Cut-off", aic3x_enum[ADC_HPF_ENUM]),
+
+ /* Mic Bias Level */
+ SOC_ENUM("Mic Bias Level", mic_bias_level),
> but it's not
> really something that should obviously be exposed to users; usually
> that'd be something that is fixed by the platform via platform data.
Will look into this angle.
>
Going by the way of using extra register control, will my method (code change
attached in prev mail) be sufficient?
Regards,
Gururaja
^ permalink raw reply
* [PATCH v3 0/8] ARM: shmobile: pinctrl and DT extensions
From: Laurent Pinchart @ 2013-01-24 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358959071-2873-1-git-send-email-g.liakhovetski@gmx.de>
Hi Guennadi,
Thanks for the patches.
For the whole set,
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
On Wednesday 23 January 2013 17:37:43 Guennadi Liakhovetski wrote:
> This is v3 of the patch series [1], addressing minor issues in 3 out of 8
> patches.
>
> [1] http://thread.gmane.org/gmane.linux.ports.sh.devel/18729
>
> Guennadi Liakhovetski (8):
> pinctrl: add SDHI and MMCIF pin groups to r8a7740
> pinctrl: add SDHI and MMCIF pin groups to sh7372
> ARM: shmobile: simplify armadillo800eva and kzm9g Kconfig
> dependencies
> ARM: shmobile: add MMCIF and SDHI DT clock aliases to sh73a0 and
> r8a7740
> ARM: shmobile: add a GPIO controller DT node for sh7372
> ARM: shmobile: use GPIO SD-card detection on armadillo800eva
> ARM: shmobile: completely switch MMC interfaces on mackerel-reference
> to DT
> ARM: shmobile: completely switch MMC interfaces on
> armadillo800eva-reference to DT
>
> .../boot/dts/r8a7740-armadillo800eva-reference.dts | 107 +++++++++
> arch/arm/boot/dts/sh7372-mackerel-reference.dts | 42 +++-
> arch/arm/boot/dts/sh7372.dtsi | 8 +
> arch/arm/mach-shmobile/Kconfig | 12 +-
> .../board-armadillo800eva-reference.c | 5 +-
> arch/arm/mach-shmobile/board-armadillo800eva.c | 10 +-
> arch/arm/mach-shmobile/board-mackerel-reference.c | 46 ----
> arch/arm/mach-shmobile/clock-r8a7740.c | 4 +
> arch/arm/mach-shmobile/clock-sh73a0.c | 3 +
> drivers/pinctrl/sh-pfc/pfc-r8a7740.c | 248 +++++++++++++++++
> drivers/pinctrl/sh-pfc/pfc-sh7372.c | 205 ++++++++++++++++
> 11 files changed, 626 insertions(+), 64 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] i2c: at91: add of_device_id entry for at91rm9200
From: Wolfram Sang @ 2013-01-24 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5100E9A4.9020804@atmel.com>
Hi,
> I didn't add this when I did the rework because there was no DT tree
> support for RM9200. The configuration for RM9200 IP is already in
> the driver and used for non DT platform so I think it makes sense to
> add this.
I agree. If it is usable for non-dt, it should be usable for dt. If it
makes sense is left to the user.
Interpreted Ludovic's comment as ack and applied to -next, thanks!
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130124/d5e790cb/attachment.sig>
^ permalink raw reply
* [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
From: Mark Brown @ 2013-01-24 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EB530BB@DBDE01.ent.ti.com>
On Thu, Jan 24, 2013 at 10:06:42AM +0000, Hebbar, Gururaja wrote:
> What I meant was that by using this macro (SND_SOC_DAPM_POST_PMU &
> SND_SOC_DAPM_PRE_PMD) I can just save and restore existing voltage values inside
> the event. They will not be user configurable (available to user through some widget).
Well, you *could* add separate register control for that but it's not
really something that should obviously be exposed to users; usually
that'd be something that is fixed by the platform via platform data.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130124/a36077fa/attachment.sig>
^ permalink raw reply
* [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
From: Hebbar, Gururaja @ 2013-01-24 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124100252.GE4955@opensource.wolfsonmicro.com>
On Thu, Jan 24, 2013 at 15:32:55, Mark Brown wrote:
> On Thu, Jan 24, 2013 at 09:33:34AM +0000, Hebbar, Gururaja wrote:
>
> > So, by just using the SND_SOC_DAPM_POST_PMU & SND_SOC_DAPM_PRE_PMD I can mask
> > & handle one particular voltage.
>
> What makes you say that? That is just not true.
What I meant was that by using this macro (SND_SOC_DAPM_POST_PMU &
SND_SOC_DAPM_PRE_PMD) I can just save and restore existing voltage values inside
the event. They will not be user configurable (available to user through some widget).
>
Regards,
Gururaja
^ permalink raw reply
* [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
From: Mark Brown @ 2013-01-24 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EB52FD9@DBDE01.ent.ti.com>
On Thu, Jan 24, 2013 at 09:33:34AM +0000, Hebbar, Gururaja wrote:
> So, by just using the SND_SOC_DAPM_POST_PMU & SND_SOC_DAPM_PRE_PMD I can mask
> & handle one particular voltage.
What makes you say that? That is just not true.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130124/2a0abc28/attachment.sig>
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Rajendra Nayak @ 2013-01-24 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122183942.GO15361@atomide.com>
On Wednesday 23 January 2013 12:09 AM, Tony Lindgren wrote:
> It seems that we should have the iospace available in the driver
> at that point. And it should be also available to the runtime PM
> code in hwmod in the device somewhere?
I couldn't find anything as part of the device. Definitely not the
ioremaped address. There's a device_private->driver_data which the
drivers can use to populate the ioremaped address but I am sure thats
not whats its meant for.
^ permalink raw reply
* [PATCH v4 0/6] support other fsl SoCs with usbmisc + small fixes
From: Alexander Shishkin @ 2013-01-24 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121128025217.GC18593@nchen-desktop>
Peter Chen <peter.chen@freescale.com> writes:
> On Tue, Nov 27, 2012 at 05:16:55PM +0100, Michael Grzeschik wrote:
>> Nearly every SoC from Freescale has this non-core usb registers. This series
>> adds support for more users of this driver.
>>
>> This series is based on Peter Chen's work. Its needed to merge his master branch
>> before applying this series:
>>
>> https://github.com/hzpeterchen/linux-usb.git
>
> I have tested it at i.mx6q sabrelite board, it works good.
>
> I have pushed your commit to my git, please cc me
> your coming chipidea patches, thanks.
>
> Alex, please add:
>
> Reviewed-by: Peter Chen <peter.chen@freescale.com>
> Tested-by: Peter Chen <peter.chen@freescale.com>
Looks good, queueing this one for submission.
Regards,
--
Alex
^ permalink raw reply
* [PATCH] ARM: shmobile: ipmmu: Add basic PMB support
From: Damian Hobson-Garcia @ 2013-01-24 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1906988.fAZIpjYMPs@avalon>
Hi Laurent,
On 2013/01/23 9:04, Laurent Pinchart wrote:
> Hi Damian,
>
> On Tuesday 22 January 2013 11:31:51 Damian Hobson-Garcia wrote:
>> On 2013/01/21 22:12, Laurent Pinchart wrote:
>>> On Friday 18 January 2013 15:35:10 Damian Hobson-Garcia wrote:
>>>> The PMB can be used to remap 16, 64, 128 or 512 MiB pages from
>>>> the 0x80000000-0xffffffff address range to anywhere in the
>>>> 0x00000000-0x7fffffff range.
>>>
>>> Isn't it 0x80000000 - 0xbfffffff to 0x00000000 - 0xffffffff ?
>>
>> Yes, looking again at the spec, your values are the correct ones.
>>
>>>> It also has the ability to perform tiled-linear address translation,
>>>> which can be used to access a memory buffer as a series of n x m tiles,
>>>> useful for image encoding/decoding.
>>>> Currently only the userspace API via character device is supported.
>>>
>>> If I understand this correctly, you're allowing userspace to remap a
>>> virtual address block to a physical address block without performing any
>>> sanity check. Isn't that a major security issue ?
>>
>> No, not really. The PMB will only remap physical addresses, not virtual
>> addresses. Moreover, the remapped address is only accessible from the
>> IP blocks which are on the ICB bus, not the CPU. I will update the
>> comment to mention this. These IP blocks already have access to the
>> entire physical memory address space, so I don't think that adding the
>> the PMB into mix introduces any new security issues.
>
> The IP block will be programmed through a driver that will control where it
> writes to/reads from. Adding the PMB will remap those read/write operations
> without notifying the driver, opening the door to potential issues.
Actually this cannot happen. The driver must use the PMB driver to
request a mapping, and that mapping cannot be modified by user-space or
any other drivers.
Since the PMB only remaps address starting from 0x80000000 (which is
outside of the DRAM address space supported by the PMB enabled shmobile
devices), only drivers that intentionally use addresses within the PMB
range will have their data remapped.
By requesting a mapping by specifying the size and mapping destination
to the PMB driver, a driver will effectively lock a region of the PMB
address space for its own use. Since the specific region that is locked
is decided by the PMB driver, no other device can make changes to the
mappings in that region.
For example:
1. Driver A requests a PMB remap to address addr1 with a size of 16M
2. The PMB driver will allocate a region in the PMB address area to hold
the mapping (eg. 0x80000000 - 0x80000000 + 16M - 1)
3. Driver A accesses addr1 by specifying a DMA address of 0x80000000 to
the hardware
If another client (driver instance, user space, etc) tries to create
another mapping, the PMB driver allocates that request to an unused
memory region (perhaps 0x80000000 + 64M). If there are no available
regions left, the request will fail.
>
> What are the use cases for controlling the PMB from userspace ?
user-space drivers.
Thanks,
Damian
>
>> ...
>>
>>>> +
>>>> +#define PMB_DEVICE_NAME "pmb"
>>>> +
>>>> +#define PMB_NR 16
>>>> +/* the smallest size that can be reserverd in the pmb */
>>>> +#define PMB_GRANULARITY (16 << 20)
>>>> +#define PMB_START_ADDR 0x80000000
>>>> +#define PMB_SIZE 0x40000000
>>>> +#define NUM_BITS(x) ((x) / PMB_GRANULARITY)
>>>> +#define NR_BITMAPS ((NUM_BITS(PMB_SIZE) + BITS_PER_LONG - 1) \
>>>> + >> ilog2(BITS_PER_LONG))
>>>
>>> Does ilog2(BITS_PER_LONG) resolve to a compile-time constant ?
>>
>> Yes it does.
>>
>> Thanks for your other comments too. I'll look into making those changes.
>
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ 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