Re: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
On Thu, Apr 04, 2013 at 03:30:01PM -0600, Stephen Warren wrote: On 04/04/2013 03:28 PM, Stephen Warren wrote: On 04/03/2013 08:45 AM, Thierry Reding wrote: Move the PCIe driver from arch/arm/mach-tegra into the drivers/pci/host directory. The motivation is to collect various host controller drivers in the same location in order to facilitate refactoring. The Tegra PCIe driver has been largely rewritten, both in order to turn it into a proper platform driver and to add MSI (based on code by Krishna Kishore kth...@nvidia.com) as well as device tree support. arch/arm/boot/dts/tegra20.dtsi | 53 + I guess this has to touch both the driver and the dtsi file so that bisectabilty isn't broken? I guess that's OK. Actually, can't you move all the *.dts/*.dtsi changes to the start of the series, then put the driver conversion patch last, to avoid any bisectability issues and still keep code and DT changes separate? I'm not sure if that'll work. There's this oddity in the Harmony DTS where the regulator@3 is disabled with a comment that this is a hack required until board-harmony-pcie.c is removed. If we change the DTS before the driver rewrite I think that would break requesting the GPIO in the board file. A possible workaround I can think of is accessing the regulator from board-harmony-pcie.c instead of the GPIO directly. But perhaps such an attempt already failed (deferred probing getting in the way?). Since it looks like this series will not make it into 3.10, maybe we should try and at least get these things ironed out so that the merge can be done more easily in 3.11. One big step in that direction would obviously be if we could get the DTS changes merged already which, as you point out, should be independent of the driver rewrite itself. Thierry pgp6TonxF_Uas.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] clk: exynos: register audio subsystem clocks using common clock framework
Audio subsystem is introduced in exynos platforms. This has seperate
clock controller which can control i2s0 and pcm0 clocks. This patch
registers the audio subsystem clocks with the common clock framework.
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos-audss.c | 139
2 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index b7c232e..1876810 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
+obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
new file mode 100644
index 000..d7f9aa8
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Padmavathi Venna padm...@samsung.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.
+ *
+ * Common Clock Framework support for Audio clks.
+*/
+
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk-provider.h
+#include linux/of_address.h
+#include linux/syscore_ops.h
+
+static DEFINE_SPINLOCK(lock);
+static struct clk **clk_table;
+static void __iomem *reg_base;
+#ifdef CONFIG_OF
+static struct clk_onecell_data clk_data;
+#endif
+
+#define ASS_CLK_SRC 0x0
+#define ASS_CLK_DIV 0x4
+#define ASS_CLK_GATE 0x8
+
+static unsigned long reg_save[][2] = {
+ {ASS_CLK_SRC, 0x0},
+ {ASS_CLK_DIV, 0x0},
+ {ASS_CLK_GATE, 0x0},
+};
+
+/*
+ * Let each supported clock get a unique id. This id is used to lookup the
clock
+ * for device tree based platforms.
+ *
+ * When adding a new clock to this list, it is advised to add it to the end.
+ * That is because the device tree source file is referring to these ids and
+ * any change in the sequence number of existing clocks will require
+ * corresponding change in the device tree files. This limitation would go away
+ * when pre-processor support for dtc would be available.
+ */
+enum exynos_audss_clks {
+ /* audss clocks */
+ mout_audss, mout_i2s,
+ dout_srp, dout_bus, dout_i2s,
+ srp_clk, i2s_bus, sclk_i2s0,
+
+ nr_clks,
+};
+
+/* list of all parent clock list */
+static const char *mout_audss_p[] = { fin_pll, fout_epll };
+static const char *mout_i2s_p[] = { mout_audss, cdclk0, sclk_audio0 };
+
+#ifdef CONFIG_PM_SLEEP
+static int exynos_audss_clk_suspend(void)
+{
+ int i;
+
+ for (i = 0; i 3; i++)
+ reg_save[i][1] = __raw_readl(reg_base + reg_save[i][0]);
+
+ return 0;
+}
+
+static void exynos_audss_clk_resume(void)
+{
+ int i;
+
+ for (i = 0; i 3; i++)
+ __raw_writel(reg_save[i][1], reg_base + reg_save[i][0]);
+}
+
+static struct syscore_ops exynos_audss_clk_syscore_ops = {
+ .suspend= exynos_audss_clk_suspend,
+ .resume = exynos_audss_clk_resume,
+};
+#endif /* CONFIG_PM_SLEEP */
+
+/* register exynos_audss clocks */
+void __init exynos_audss_clk_init(struct device_node *np)
+{
+ if (np) {
+ reg_base = of_iomap(np, 0);
+ if (!reg_base)
+ panic(%s: failed to map registers\n, __func__);
+ } else
+ panic(%s: unable to determine soc\n, __func__);
+
+ clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
+ if (!clk_table)
+ panic(could not allocate clock lookup table\n);
+
+ clk_data.clks = clk_table;
+ clk_data.clk_num = nr_clks;
+ of_clk_add_provider(np, of_clk_src_onecell_get, clk_data);
+
+ clk_table[mout_audss] = clk_register_mux(NULL, mout_audss,
+ mout_audss_p, ARRAY_SIZE(mout_audss_p), 0,
+ reg_base + ASS_CLK_SRC, 0, 1, 0, lock);
+ clk_register_clkdev(clk_table[mout_audss], mout_audss, NULL);
+
+ clk_table[mout_i2s] = clk_register_mux(NULL, mout_i2s, mout_i2s_p,
+ ARRAY_SIZE(mout_i2s_p), 0,
+ reg_base + ASS_CLK_SRC, 2, 2, 0, lock);
+ clk_register_clkdev(clk_table[mout_i2s], mout_i2s, NULL);
+
+ clk_table[dout_srp] = clk_register_divider(NULL, dout_srp,
+ mout_audss, 0, reg_base + ASS_CLK_DIV, 0, 4,
+ 0, lock);
+
+ clk_table[dout_bus] = clk_register_divider(NULL, dout_bus,
+ dout_srp, 0, reg_base
[PATCH 2/3] ARM: dts: add Exynos audio subsystem clock controller node
Audio subsystem introduced in exynos platforms which has a
internal clock controller. This patch adds a node for the same.
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 7751e69..14d454c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -67,6 +67,12 @@
#clock-cells = 1;
};
+ clock_audss: audss-clock-controller@0x0381 {
+ compatible = samsung,exynos-audss-clock;
+ reg = 0x0381 0x100;
+ #clock-cells = 1;
+ };
+
gic:interrupt-controller@10481000 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
--
1.7.4.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] ARM: dts: add clock provider information for i2s0 controller in Exynos5250
Add clock lookup information for i2s0 controller on exynos5250 SoC. Signed-off-by: Padmavathi Venna padm...@samsung.com --- arch/arm/boot/dts/exynos5250.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 14d454c..08e3b3f 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -387,6 +387,8 @@ pdma0 9 pdma0 8; dma-names = tx, rx, tx-sec; + clocks = clock_audss 6, clock_audss 6, clock_audss 7; + clock-names = iis, i2s_opclk0, i2s_opclk1; samsung,supports-6ch; samsung,supports-rstclr; samsung,supports-secdai; -- 1.7.4.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10
On Friday 05 April 2013 01:46 AM, Jon Hunter wrote: Main change is ensuring that the state of a gpio bank is restored when booting with device-tree. The rest of the patches are clean-ups and one optimisation. The patch modifying the *.dtsi files should go via Benoit Cousson's for_3.10/dts branch [1] as it is dependent on changes in his branch but I have included here for completeness. Testing includes: - Boot testing on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP and AM335x EVM. - Verified that GPIO interrupts are working on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP and OMAP4430 SDP by making sure networking was working correctly as these boards use a GPIO with the ethernet chips. Also checked /proc/interrupts to ensure GPIO interrupt counts are incrementing as expected. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git Jon Hunter (4): gpio/omap: free irq domain in probe() failure paths gpio/omap: optimise interrupt service routine gpio/omap: force restore if context loss is not detectable ARM: dts: OMAP2+: Identify GPIO banks that are always powered Tarun Kanti DebBarma (1): gpio/omap: remove extra context restores in *_runtime_resume() Thanks Jon for pulling the fixes. I suggest you to split the series so that 'gpio/omap:*' can be pulled by Grant and 'ARM: dts:*' by Benoit. All the 'gpio/omap:*' patches in the series looks fine to me. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
On Thu, Apr 04, 2013 at 03:28:54PM -0600, Stephen Warren wrote:
[...]
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+Required properties:
+- interrupts: the interrupt outputs of the controller
+- interrupt-names: list of names to identify interrupts
The specification part of this file should define which interrupt
outputs must be included in this list, and the order they must appear in
the list.
Okay, I can add such a description similar to what you propose below for
the clocks and clock-names properties. Something like this:
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
- interrupt-names: Must include the following entries:
intr: The Tegra interrupt that is asserted for controller interrupts
msi: The Tegra interrupt that is asserted when an MSI is received
Would that be acceptable?
I should probably update the reg properties in a similar way. Maybe like
so:
- reg: A list of physical base address and length for each set of controller
registers. Must contain an entry for each entry in the reg-names property.
- reg-names: Must include the following entries:
pads: PADS registers
afi: AFI registers
cs: configuration space region
I believe that the entries in the interrupts property must
have a defined order, so I'm not sure whether interrupt-names is useful
here?
Actually the interrupt-names property is there specifically so that the
order doesn't matter. The driver uses platform_get_irq_byname(), using
intr and msi respectively so that they don't have to appear in a
specific order. I did this so that it is more in line with properties
such as clocks and reg.
+- ranges: describes the translation of addresses for root ports
Shouldn't there be some discussion re: how the range are expected to be
set up so that everything works? We shouldn't expect people to just
blindly copy the example without any way of understanding it.
Possibly. I wouldn't like to go too much into the details, though, since
the ranges property is not only rather complex but also well documented
in other places. But I could add some explanation about which entries
are expected and how they work together. In this case even order is
important. The port register entries need to be listed before the
non-prefetchable memory window entry, otherwise the ranges parser gets
confused. How does the following sound?
- ranges: Describes the translation of addresses for root ports and standard
PCI regions. The entries must be 6 cells each, where the first three cells
correspond to the address as described for the #address-cells property
above, the fourth cell is the physical CPU address to translate to and the
fifth and six cells are as described for the #size-cells property above.
- The first two entries are expected to translate the addresses for the root
port registers, which are referenced by the assigned-addresses property of
the root port nodes (see below).
- The remaining entries setup the mapping for the standard I/O, memory and
prefetchable PCI regions. The first cell determines the type of region
that is setup:
- 0x8100: I/O memory region
- 0x8200: non-prefetchable memory region
- 0xc200: prefetchable memory region
Please refer to the standard PCI bus binding document for a more detailed
explanation.
+- clocks: the clock inputs of the controller
+- clock-names: list of names to identify clocks
The specification part of this file should define which clocks are
required, and not rely on the example below to do this. I would suggest
re-writing this as:
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
pex (The Tegra clock of that name)
afi (The Tegra clock of that name)
pcie_xclk (The Tegra clock of that name)
pll_e (The Tegra clock of that name)
Okay, sounds good. Although the Tegra clocks are named somewhat
differently. pex is named pcie and pcie_xclk is unassigned (!)
according to the nvidia,tegra20-car.txt binding document. Perhaps I
should update the binding document to replace unassigned with pcie_xclk
for clock 74. And maybe rename pex in the PCIe binding to pcie to match
the CAR binding?
+Root ports are defined as subnodes of the PCIe controller node.
+
+Required properties:
...
+- ranges: sub-ranges distributed from the PCIe controller node
Here, I think it's worth mentioning that an empty ranges is all that's
required.
Yes, that's a good idea.
+Board DTS:
+
+ pcie-controller {
+ status = okay;
+
+ vdd-supply = pci_vdd_reg;
+ pex-clk-supply = pci_clk_reg;
+
+ /* root port 00:01.0 */
+ pci@1,0 {
+ status = okay;
Is it worth putting a comment here stating
[PATCH -next] spi: tegra: slink: make symbol static
From: Wei Yongjun yongjun_...@trendmicro.com.cn
symbol '' was not declared. It should be static.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/spi/spi-tegra20-slink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 4e58b53..b224a82 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1087,11 +1087,11 @@ static struct tegra_spi_platform_data
*tegra_slink_parse_dt(
return pdata;
}
-const struct tegra_slink_chip_data tegra30_spi_cdata = {
+static const struct tegra_slink_chip_data tegra30_spi_cdata = {
.cs_hold_time = true,
};
-const struct tegra_slink_chip_data tegra20_spi_cdata = {
+static const struct tegra_slink_chip_data tegra20_spi_cdata = {
.cs_hold_time = false,
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
According to
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
the #interrupt-cells property of an interrupt-controller is used
to define the number of cells needed to specify a single interrupt.
A commonly used variant is two cell on which #interrupt-cells = 2
and the first cell defines the index of the interrupt in the controller
and the second cell is used to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
An example of an interrupt controller which use the two cell format is
the OMAP GPIO controller that allows GPIO lines to be used as IRQ
(Documentation/devicetree/bindings/gpio/gpio-omap.txt)
But setting #interrupt-cells = 2 on the OMAP GPIO device node and
specifying the GPIO-IRQ type and level flags on the second cell does not
store this value on the populated IORESOURCE_IRQ struct resource.
This is because when using an IRQ from an interrupt controller and
setting both cells (e.g:)
interrupt-parent = gpio6;
interrupts = 16 8;
A call to of_irq_to_resource() is made and this function calls to
irq_of_parse_and_map_type() to get the virtual IRQ mapped to the real
index for this interrupt controller. This IRQ number is populated on
the struct resource:
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
int irq = irq_of_parse_and_map(dev, index);
..
r-start = r-end = irq;
}
irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
the correct xlate function handler according to #interrupt-cells
(irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
irq_set_irq_type() to set the IRQ type.
But the type is never returned so it can't be saved on the IRQ struct
resource flags member.
This means that drivers that need the IRQ type/level flags defined in
the DT won't be able to get it.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/of/irq.c | 30 --
include/linux/of_irq.h |4
kernel/irq/irqdomain.c | 14 --
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a3c1c5a..6f6aa75 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -27,22 +27,39 @@
#include linux/slab.h
/**
- * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * irq_of_parse_and_map_type - Parse and map an interrupt into linux virq space
* @device: Device node of the device whose interrupt is to be mapped
* @index: Index of the interrupt to map
+ * @type: Interrupt trigger type and level flags filled by this function
*
* This function is a wrapper that chains of_irq_map_one() and
* irq_create_of_mapping() to make things easier to callers
*/
-unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+static unsigned int irq_of_parse_and_map_type(struct device_node *dev,
+ int index, unsigned int *type)
{
struct of_irq oirq;
+ unsigned int virq;
if (of_irq_map_one(dev, index, oirq))
return 0;
- return irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
+ virq = irq_create_of_mapping_type(oirq.controller, oirq.specifier,
+ oirq.size, type);
+ return virq;
+}
+
+/**
+ * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * @device: Device node of the device whose interrupt is to be mapped
+ * @index: Index of the interrupt to map
+ *
+ * This function is a wrapper of irq_of_parse_and_map_type() when the IRQ
+ * type and level flags are not needed
+ */
+unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+{
+ return irq_of_parse_and_map_type(dev, index, NULL);
}
EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
@@ -338,7 +355,8 @@ EXPORT_SYMBOL_GPL(of_irq_map_one);
*/
int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
{
- int irq = irq_of_parse_and_map(dev, index);
+ int type = IRQ_TYPE_NONE;
+ int irq = irq_of_parse_and_map_type(dev, index, type);
/* Only dereference the resource if both the
* resource and the irq are valid. */
@@ -353,7 +371,7 @@ int of_irq_to_resource(struct device_node *dev, int index,
struct resource *r)
name);
r-start = r-end = irq;
- r-flags = IORESOURCE_IRQ;
+ r-flags = (IORESOURCE_IRQ | type);
r-name = name ? name : dev-full_name;
}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 535cecf..98aec57 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -66,6 +66,10 @@
Re: [PATCH v3 07/12] PCI: tegra: Move PCIe driver to drivers/pci/host
For reference, here's the new binding document with all your comments
addressed (I think).
Thierry
NVIDIA Tegra PCIe controller
Required properties:
- compatible: nvidia,tegra20-pcie
- device_type: Must be pci
- reg: A list of physical base address and length for each set of controller
registers. Must contain an entry for each entry in the reg-names property.
- reg-names: Must include the following entries:
pads: PADS registers
afi: AFI registers
cs: configuration space region
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
- interrupt-names: Must include the following entries:
intr: The Tegra interrupt that is asserted for controller interrupts
msi: The Tegra interrupt that is asserted when an MSI is received
- pex-clk-supply: Supply voltage for internal reference clock
- vdd-supply: Power supply for controller (1.05V)
- bus-range: Range of bus numbers associated with this controller
- #address-cells: Address representation for root ports (must be 3)
- cell 0 specifies the bus and device numbers of the root port:
[23:16]: bus number
[15:11]: device number
- cell 1 denotes the upper 32 address bits and should be 0
- cell 2 contains the lower 32 address bits and is used to translate to the
CPU address space
- #size-cells: Size representation for root ports (must be 2)
- ranges: Describes the translation of addresses for root ports and standard
PCI regions. The entries must be 6 cells each, where the first three cells
correspond to the address as described for the #address-cells property
above, the fourth cell is the physical CPU address to translate to and the
fifth and six cells are as described for the #size-cells property above.
- The first two entries are expected to translate the addresses for the root
port registers, which are referenced by the assigned-addresses property of
the root port nodes (see below).
- The remaining entries setup the mapping for the standard I/O, memory and
prefetchable PCI regions. The first cell determines the type of region
that is setup:
- 0x8100: I/O memory region
- 0x8200: non-prefetchable memory region
- 0xc200: prefetchable memory region
Please refer to the standard PCI bus binding document for a more detailed
explanation.
- clocks: List of clock inputs of the controller. Must contain an entry for
each entry in the clock-names property.
- clock-names: Must include the following entries:
pex: The Tegra clock of that name
afi: The Tegra clock of that name
pcie_xclk: The Tegra clock of that name
pll_e: The Tegra clock of that name
Root ports are defined as subnodes of the PCIe controller node.
Required properties:
- device_type: Must be pci
- assigned-addresses: Address and size of the port configuration registers
- reg: PCI bus address of the root port
- #address-cells: Must be 3
- #size-cells: Must be 2
- ranges: Sub-ranges distributed from the PCIe controller node. An empty
property is sufficient.
- nvidia,num-lanes: Number of lanes to use for this port. Valid combinations
are:
- Root port 0 uses 4 lanes, root port 1 is unused.
- Both root ports use 2 lanes.
Example:
SoC DTSI:
pcie-controller {
compatible = nvidia,tegra20-pcie;
device_type = pci;
reg = 0x80003000 0x0800 /* PADS registers */
0x80003800 0x0200 /* AFI registers */
0x9000 0x1000; /* configuration space */
reg-names = pads, afi, cs;
interrupts = 0 98 0x04 /* controller interrupt */
0 99 0x04; /* MSI interrupt */
interrupt-names = intr, msi;
bus-range = 0x00 0xff;
#address-cells = 3;
#size-cells = 2;
ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /*
port 0 registers */
0x8200 0 0x80001000 0x80001000 0 0x1000 /*
port 1 registers */
0x8100 0 0 0x8200 0 0x0001 /*
downstream I/O */
0x8200 0 0xa000 0xa000 0 0x1000 /*
non-prefetchable memory */
0xc200 0 0xb000 0xb000 0 0x1000; /*
prefetchable memory */
clocks = tegra_car 70, tegra_car 72, tegra_car 74,
tegra_car 118;
clock-names = pex, afi, pcie_xclk, pll_e;
status = disabled;
pci@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x8000 0 0x1000;
reg = 0x000800 0 0 0 0;
status = disabled;
#address-cells = 3;
#size-cells = 2;
ranges;
Re: [PATCH -next] spi: tegra: slink: make symbol static
On Fri, Apr 05, 2013 at 03:45:12PM +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn symbol '' was not declared. It should be static. This description doesn't make any sense. The patch looks good, though. Maybe something like: ---snip--- Neither tegra20_spi_cdata nor tegra30_spi_cdata are used outside this file so they can, and should, be static. ---snip--- Is more accurate? Thierry pgpy2zlGESTAa.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] ARM: OMAP: DMTIMER updates for v3.10
On 04/04/2013 08:38 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130319 10:42]: Includes: - A couple fixes for DMTIMER context loss handling. - Populating DMTIMER errata when booting with device-tree. - A new function for requesting a DMTIMER by device-tree node. Based upon v3.9-rc3. Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 Blaze and AM335x EVM. Testing includes ... 1. Booting kernel on above boards 2. Testing of various DMTIMER request APIs 3. Testing the timer overflow and match interrupts. 4. Using different clock sources to operate the timer with. Jon Hunter (4): ARM: OMAP: Force dmtimer restore if context loss is not detectable ARM: OMAP: Add function to request timer by node ARM: dts: OMAP2+: Update DMTIMER compatibility property ARM: OMAP2+: Populate DMTIMER errata when using device-tree NeilBrown (1): ARM: OMAP: Simplify dmtimer context-loss handling .../devicetree/bindings/arm/omap/timer.txt | 17 +- arch/arm/boot/dts/am33xx.dtsi | 14 +- arch/arm/boot/dts/omap2.dtsi | 22 +- arch/arm/boot/dts/omap2420.dtsi|2 +- arch/arm/boot/dts/omap2430.dtsi|2 +- arch/arm/boot/dts/omap3.dtsi | 24 +- arch/arm/boot/dts/omap4.dtsi | 22 +- arch/arm/boot/dts/omap5.dtsi | 22 +- arch/arm/mach-omap2/timer.c|7 +- arch/arm/plat-omap/dmtimer.c | 241 arch/arm/plat-omap/include/plat/dmtimer.h |1 + 11 files changed, 220 insertions(+), 154 deletions(-) For all these it sounds like it's best that Benoit queues them with the .dts changes: Acked-by: Tony Lindgren t...@atomide.com Great. Jon, I've just applied the whole series and will push it soon. Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
On 04/05/2013 08:26 AM, Santosh Shilimkar wrote: On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote: The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting with some of the timer interrupts causing the allocation of timer interrupts to fail. The problem is caused by adding 32 to the interrupt number for the L3 interrupts to account for per processor interrupts (PPI) and software generated interrupts (SGI) which typically are mapped to the first 32 interrupts in the ARM GIC. This is not necessary because the first parameter of the ARM GIC interrupt property specifies the GIC interrupt type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3 interrupts by substracting 32. Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- Please note that this problem is observed in Benoit's for_3.10/dts branch [1]. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git Thats correct. I overlooked the 32 addition part. This patch should also be pulled into Benoit's 3.10 tree. Done. I've just applied it. But I will probably merge it with the original patch, because having a broken patch and the fix in the same pull request does not look right. For the patch, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
Santosh and Jon,
On 04/05/2013 10:08 AM, Benoit Cousson wrote:
On 04/05/2013 08:26 AM, Santosh Shilimkar wrote:
On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote:
The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting
with some of the timer interrupts causing the allocation of timer
interrupts to fail.
The problem is caused by adding 32 to the interrupt number for the L3
interrupts to account for per processor interrupts (PPI) and software
generated interrupts (SGI) which typically are mapped to the first 32
interrupts in the ARM GIC. This is not necessary because the first
parameter of the ARM GIC interrupt property specifies the GIC interrupt
type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3
interrupts by substracting 32.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Please note that this problem is observed in Benoit's for_3.10/dts branch
[1].
[1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
Thats correct. I overlooked the 32 addition part. This patch should
also be pulled into Benoit's 3.10 tree.
Done. I've just applied it. But I will probably merge it with the
original patch, because having a broken patch and the fix in the same
pull request does not look right.
Please find below the fixed version.
Regards,
Benoit
From 90c2d172ef86d6c3283df43358d4425f9016be48 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 26 Feb 2013 17:36:14 +0530
Subject: [PATCH] ARM: dts: OMAP4/5: Update l3-noc DT nodes
Add l3-noc node for OMAP4 and OMAP5 devices.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[jon-hun...@ti.com: Fix the problem caused by adding 32 to the interrupt
number for the L3 interrupts to account for per processor interrupts (PPI)
and software generated interrupts (SGI) which typically are mapped to the
first 32 interrupts in the ARM GIC. This is not necessary because the first
parameter of the ARM GIC interrupt property specifies the GIC interrupt
type (ie. SGI, PPI, etc). Hence, fix the interrupt number for the L3
interrupts by substracting 32]
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Benoit Cousson benoit.cous...@linaro.org
---
arch/arm/boot/dts/omap4.dtsi |5 +
arch/arm/boot/dts/omap5.dtsi |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index ddfc54a..3ae6a3f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -94,6 +94,11 @@
#size-cells = 1;
ranges;
ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+ reg = 0x4400 0x1000,
+ 0x4480 0x2000,
+ 0x4500 0x1000;
+ interrupts = 0 9 0x4,
+0 10 0x4;
counter32k: counter@4a304000 {
compatible = ti,omap-counter32k;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e539258..94b5ec9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -87,6 +87,11 @@
#size-cells = 1;
ranges;
ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+ reg = 0x4400 0x2000,
+ 0x4480 0x3000,
+ 0x4500 0x4000;
+ interrupts = 0 9 0x4,
+0 10 0x4;
counter32k: counter@4ae04000 {
compatible = ti,omap-counter32k;
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: OMAP4+: Correct L3 interrupts
On Friday 05 April 2013 01:52 PM, Benoit Cousson wrote: Santosh and Jon, On 04/05/2013 10:08 AM, Benoit Cousson wrote: On 04/05/2013 08:26 AM, Santosh Shilimkar wrote: On Thursday 04 April 2013 11:36 PM, Jon Hunter wrote: The L3 interrupt numbers are incorrect for OMAP4+ and are conflicting with some of the timer interrupts causing the allocation of timer interrupts to fail. The problem is caused by adding 32 to the interrupt number for the L3 interrupts to account for per processor interrupts (PPI) and software generated interrupts (SGI) which typically are mapped to the first 32 interrupts in the ARM GIC. This is not necessary because the first parameter of the ARM GIC interrupt property specifies the GIC interrupt type (ie. SGI, PPI, etc). Hence, fix the interrupt number fo the L3 interrupts by substracting 32. Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- Please note that this problem is observed in Benoit's for_3.10/dts branch [1]. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git Thats correct. I overlooked the 32 addition part. This patch should also be pulled into Benoit's 3.10 tree. Done. I've just applied it. But I will probably merge it with the original patch, because having a broken patch and the fix in the same pull request does not look right. Please find below the fixed version. Thanks Benoit. Patch looks fine to me. Regards, Santosh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/02/2013 11:23 AM, Roger Quadros wrote: + Paul On 03/26/2013 12:23 PM, Roger Quadros wrote: Register a device tree clock provider for the clocks on the OMAP4 SoC. Also provide the binding information. For now we only provide AUXCLKs. NOTE: this patch depends on https://patchwork.kernel.org/patch/2312211/ Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/clock/omap4-clock.txt | 33 arch/arm/boot/dts/omap4.dtsi |5 ++ arch/arm/mach-omap2/cclock44xx_data.c | 41 3 files changed, 79 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 11:47-20130405, Roger Quadros wrote: On 04/02/2013 11:23 AM, Roger Quadros wrote: + Paul On 03/26/2013 12:23 PM, Roger Quadros wrote: Register a device tree clock provider for the clocks on the OMAP4 SoC. Also provide the binding information. For now we only provide AUXCLKs. NOTE: this patch depends on https://patchwork.kernel.org/patch/2312211/ Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/clock/omap4-clock.txt | 33 arch/arm/boot/dts/omap4.dtsi |5 ++ arch/arm/mach-omap2/cclock44xx_data.c | 41 3 files changed, 79 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt If we are doing this, we might as well do for all platforms(OMAP3-5, AM..) in an series, no? -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/05/2013 11:48 AM, Nishanth Menon wrote: On 11:47-20130405, Roger Quadros wrote: On 04/02/2013 11:23 AM, Roger Quadros wrote: + Paul On 03/26/2013 12:23 PM, Roger Quadros wrote: Register a device tree clock provider for the clocks on the OMAP4 SoC. Also provide the binding information. For now we only provide AUXCLKs. NOTE: this patch depends on https://patchwork.kernel.org/patch/2312211/ Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/clock/omap4-clock.txt | 33 arch/arm/boot/dts/omap4.dtsi |5 ++ arch/arm/mach-omap2/cclock44xx_data.c | 41 3 files changed, 79 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt If we are doing this, we might as well do for all platforms(OMAP3-5, AM..) in an series, no? Yes, once we agree on the approach, I can write it for all OMAPs. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7] [media] Add common video interfaces OF bindings documentation
On 04/04/2013 10:45 PM, Stephen Warren wrote: On 03/26/2013 09:58 AM, Sylwester Nawrocki wrote: From: Guennadi Liakhovetski g.liakhovet...@gmx.de This patch adds a document describing common OF bindings for video capture, output and video processing devices. It is curently mainly focused on video capture devices, with data busses defined by standards such as ITU-R BT.656 or MIPI-CSI2. It also documents a method of describing data links between devices. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Stephen Warren swar...@nvidia.com Thanks Stephen, this patch is already queued for 3.10 in the media tree. Hence unfortunately I cannot add more tags to it. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5] gpio/omap: optimise interrupt service routine
On Thu, Apr 04, 2013 at 03:16:14PM -0500, Jon Hunter wrote:
The OMAP GPIO interrupt service routine is checking each bit in the
GPIO interrupt status register to see which bits are set. It is not
efficient to check every bit especially if only a few bits are set.
Therefore, instead of checking every bit use the __ffs() function,
which returns the location of the first set bit, to find all the set
bits.
This optimisation was suggested-by and developed in collaboration
with Felipe Balbi.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
looks alright:
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 5af7acd..685e850 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -689,7 +689,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
{
void __iomem *isr_reg = NULL;
u32 isr;
- unsigned int i;
+ unsigned int bit;
struct gpio_bank *bank;
int unmasked = 0;
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -730,9 +730,9 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
if (!isr)
break;
- for (i = 0; isr != 0; isr = 1, i++) {
- if (!(isr 1))
- continue;
+ while (isr) {
+ bit = __ffs(isr);
+ isr = ~(1 bit);
/*
* Some chips can't respond to both rising and falling
@@ -741,10 +741,10 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
* to respond to the IRQ for the opposite direction.
* This will be indicated in the bank toggle_mask.
*/
- if (bank-toggle_mask (1 i))
- _toggle_gpio_edge_triggering(bank, i);
+ if (bank-toggle_mask (1 bit))
+ _toggle_gpio_edge_triggering(bank, bit);
- generic_handle_irq(irq_find_mapping(bank-domain, i));
+ generic_handle_irq(irq_find_mapping(bank-domain, bit));
}
}
/* if bank has any level sensitive GPIO pin interrupt
--
1.7.10.4
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/5 v2] ARM: kirkwood: add device node entries for the gigabit interfaces
Le 04/04/13 23:35, Simon Baatz a écrit : Hi Florian, On Thu, Apr 04, 2013 at 12:27:13PM +0200, Florian Fainelli wrote: This patch modifies kirkwood.dtsi to specify the various gigabit interfaces nodes available on kirkwood devices. They are disabled by default and should be enabled on a per-board basis. egiga0 and egiga1 aliases are defined for convenience. The mdio node is also present and should be enabled on a per-board basis as well. Signed-off-by: Florian Fainelli flor...@openwrt.org --- Changes since v1: - dropped change to arch/arm/mach-kirkwood/common.c to avoid merge conflicts I think we should remove the clock aliases in kirkwood_legacy_clk_init() in mach-kirkwood/dt-board.c (once we have proper clock support, see my other mail). [snip] Don't we need to add: interrupts = 46; here? Right this is missing, in fact it still works ok because the orion-mdio driver can do busy waiting instead of interrupt signaling. Will fix that in the next round, thanks! -- Florian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
Most Renesas irqpin controllers have 4-bit sense fields, however, some
have different widths. This patch adds a DT binding to optionally
specify such non-standard values.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
v2: is no longer based on an earlier ARM: shmobile: irqpin: fix handling
of spurious interrupts in DT case patch, which needs more work.
.../interrupt-controller/renesas,intc-irqpin.txt | 13 +
drivers/irqchip/irq-renesas-intc-irqpin.c |5 +
2 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
new file mode 100644
index 000..c6f09b7
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -0,0 +1,13 @@
+DT bindings for the R-/SH-Mobile irqpin controller
+
+Required properties:
+
+- compatible: has to be renesas,intc-irqpin
+- #interrupt-cells: has to be 2
+
+Optional properties:
+
+- any properties, listed in interrupts.txt in this directory, and any standard
+ resource allocation properties
+- sense-bitfield-width: width of a single sense bitfield in the SENSE register,
+ if different from the default 4 bits
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c
b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 5a68e5a..7a02dfe 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -18,6 +18,7 @@
*/
#include linux/init.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/spinlock.h
#include linux/interrupt.h
@@ -429,6 +430,10 @@ static int intc_irqpin_probe(struct platform_device *pdev)
}
}
+ if (!pdata)
+ of_property_read_u32(pdev-dev.of_node, sense-bitfield-width,
+p-config.sense_bitfield_width);
+
/* use more severe masking method if requested */
if (p-config.control_parent) {
enable_fn = intc_irqpin_irq_enable_force;
--
1.7.2.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
Hello Simon,
First of all, thanks for getting these patches a try!
Le 04/04/13 23:29, Simon Baatz a écrit :
Hi Florian
[snip]
if (!mv643xx_eth_version_printed++)
pr_notice(MV-643xx 10/100/1000 ethernet driver version %s\n,
This is not related to your change, but there is a problem in this
function that has already been discussed in the past if I remember
correctly: The respective clock needs to be enabled here (at least
on Kirkwood), since accesses to the hardware are done below.
Enabling the clock only in mv643xx_eth_probe() is too late.
As said, this is not a problem introduced by your changes (and which
is currently circumvented by enabling the respective clocks in
kirkwood_legacy_clk_init() and kirkwood_ge0x_init()), but we might
want to fix this now to get rid of unconditionally enabling the GE
clocks in the DT case.
I think there may have been some confusion between the ethernet-group
clock and the actual Ethernet port inside the ethernet-group. The
mv643xx_eth driver assumes we have a per-port clock gating scheme, while
I think we have a per ethernet-group clock gating scheme instead. Like
you said, I think this should be addressed separately.
[snip]
You don't change the clk initialization here:
#if defined(CONFIG_HAVE_CLK)
mp-clk = clk_get(pdev-dev, (pdev-id ? 1 : 0));
if (!IS_ERR(mp-clk)) {
clk_prepare_enable(mp-clk);
mp-t_clk = clk_get_rate(mp-clk);
}
#endif
Which, if I understand correctly, works in the DT case because you
assign clock-names to the clocks in the DTS. However, I wonder
whether this works for any but the first Ethernet device.
In the old platform device setup, the pdev-id was set when
initialiazing the platform_device structure in common.c. Where is
this done in the DT case?
Looks like you are right, in the DT case, I assume that we should lookup
the clock using NULL instead of 1 or 0 so we match any clock instead
of a specific one.
[snip]
In phy_scan(), the phy is searched like this:
snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
orion-mdio-mii, addr);
phydev = phy_connect(mp-dev, phy_id, mv643xx_eth_adjust_link,
PHY_INTERFACE_MODE_GMII);
But orion-mdio-mii:xx is the name of the PHY if MDIO is setup via a
platform_device. I could not get this to work if the MDIO device is
setup via DT. Am I doing something wrong?
I just missed updating this part of the code to probe for PHYs. The
board I tested with uses a PHY_NONE configuration. I will add the
missing bits for of_phy_connect() to be called here.
Additionally, in phy_scan() there is this:
if (phy_addr == MV643XX_ETH_PHY_ADDR_DEFAULT) {
start = phy_addr_get(mp) 0x1f;
num = 32;
} else {
...
MV643XX_ETH_PHY_ADDR_DEFAULT is defined as 0. However, many Kirkwood
devices use MV643XX_ETH_PHY_ADDR(0). If the module probe is
deferred in mv643xx_eth because the MDIO driver is not yet loaded,
all 32 PHY addresses are scanned without success. This is not needed
and clutters the log.
Ok, I am not sure how we can circumvent the log cluttering that happens,
what would be your suggestion?
--
Florian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v11 0/3] Add DRM FIMD DT support for Exynos4 DT Machines
This patch series adds support for DRM FIMD DT for Exynos4 DT Machines, specifically for Exynos4412 SoC. changes since v10: - addressed comments from Sylwester Nawrocki sylvester.nawro...@gmail.com changes since v9: - dropped the patch ARM: dts: Add lcd pinctrl node entries for EXYNOS4412 SoC as the gpios in the newly added nodes lcd_en and lcd_sync in this patch were already PULLed high by existing lcd_clk node. - addressed comments from Sylwester Nawrocki sylvester.nawro...@gmail.com and Thomas Abraham thomas.abra...@linaro.org changes since v8: - addressed comments to add missing documentation for clock and clock-names properties as pointed out by Sachin Kamat sachin.ka...@linaro.org changes since v7: - rebased to kgene's for-next - Migrated to Common Clock Framework - removed the patch ARM: dts: Add FIMD AUXDATA node entry for exynos4 DT, as migration to Common Clock Framework will NOT need this. - addressed the comments raised by Sachin Kamat sachin.ka...@linaro.org changes since v6: - addressed comments and added interrupt-names = fifo, vsync, lcd_sys in exynos4.dtsi and re-ordered the interrupt numbering to match the order in interrupt combiner IP as suggested by Sylwester Nawrocki sylvester.nawro...@gmail.com. changes since v5: - renamed the fimd binding documentation file name as samsung-fimd.txt, since it not only talks about exynos display controller but also about previous samsung display controllers. - rephrased an abmigious statement about the interrupt combiner in the fimd binding documentation as pointed out by Sachin Kamat sachin.ka...@linaro.org changes since v4: - moved the fimd binding documentation to Documentation/devicetree/bindings/video/ as suggested by Sylwester Nawrocki sylvester.nawro...@gmail.com - added more fimd compatiblity strings in fimd documentation as discussed at https://patchwork.kernel.org/patch/2144861/ with Sylwester Nawrocki sylvester.nawro...@gmail.com and Tomasz Figa tomasz.f...@gmail.com - modified compatible string for exynos4 fimd as exynos4210-fimd exynos5 fimd as exynos5250-fimd to stick to the rule that compatible value should be named after first specific SoC model in which this particular IP version was included as discussed at https://patchwork.kernel.org/patch/2144861/ - documented more about the interrupt combiner and their order as suggested by Sylwester Nawrocki sylvester.nawro...@gmail.com changes since v3: - rebased on http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=shortlog;h=refs/heads/for-next-next changes since v2: - added alias to 'fimd@11c0' node (reported by: Rahul Sharma r.sh.o...@gmail.com) - removed 'lcd0_data' node as there was already a similar node lcd_data24 (reported by: Jingoo Han jg1@samsung.com - replaced spaces with tabs in display-timing node changes since v1: - added new patch to add FIMD DT binding Documentation - removed patch enabling SAMSUNG_DEV_BACKLIGHT and SAMSUNG_DEV_PMW for mach-exynos4 DT - added 'status' property to fimd DT node Is based on branch kgene's for-next https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next Vikas Sajjan (3): ARM: dts: Add FIMD node to exynos4 ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts ARM: dts: Add FIMD DT binding Documentation .../devicetree/bindings/video/samsung-fimd.txt | 65 arch/arm/boot/dts/exynos4.dtsi | 12 arch/arm/boot/dts/exynos4412-origen.dts| 21 +++ 3 files changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v11 1/3] ARM: dts: Add FIMD node to exynos4
This patch adds a common FIMD device node for all Exynos4 SoCs.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 800ff11..b8771c5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -371,4 +371,16 @@
#dma-requests = 1;
};
};
+
+ fimd: fimd@11c0 {
+ compatible = samsung,exynos4210-fimd;
+ interrupt-parent = combiner;
+ reg = 0x11c0 0x2;
+ interrupt-names = fifo, vsync, lcd_sys;
+ interrupts = 11 0, 11 1, 11 2;
+ clocks = clock 140, clock 283;
+ clock-names = sclk_fimd, fimd;
+ samsung,power-domain = pd_lcd0;
+ status = disabled;
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v11 2/3] ARM: dts: Add FIMD node and display timing node to exynos4412-origen.dts
This patch adds FIMD related nodes for the Origen Quad board.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
arch/arm/boot/dts/exynos4412-origen.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index a5478bd..b39bffc 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -70,6 +70,27 @@
status = okay;
};
+ fimd@11c0 {
+ pinctrl-0 = lcd_clk lcd_data24 pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
+
+ display-timings {
+ native-mode = timing0;
+ timing0: timing {
+ clock-frequency = 5;
+ hactive = 1024;
+ vactive = 600;
+ hfront-porch = 64;
+ hback-porch = 16;
+ hsync-len = 48;
+ vback-porch = 64;
+ vfront-porch = 16;
+ vsync-len = 3;
+ };
+ };
+
serial@1380 {
status = okay;
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] regulator: max8952: Add Device Tree support
On Thu, Apr 04, 2013 at 06:17:20PM +0200, Tomasz Figa wrote: + if (of_property_read_u32(np, max8952,ramp-speed, pd-ramp_speed)) + dev_warn(dev, max8952,ramp-speed property not specified, defaulting to 32mV/us\n); Applied both, though the above warning seems a bit harsh - it seems like assuming a worst case ramp rate ought to be totally safe and just a minor performance issue so silently accepted. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/2] video: imxfb DT support
Hi, This series adds DT support for imxfb. Changes in v3 are described in the notes of patch 2. Regards, Markus ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/2] video: imxfb: Add DT support
Add devicetree support for imx framebuffer driver. It uses the generic
display bindings and helper functions.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Cc: Fabio Estevam feste...@gmail.com
Cc: Mark Rutland mark.rutl...@arm.com
---
.../devicetree/bindings/video/fsl,imx-fb.txt | 49 ++
drivers/video/imxfb.c | 192 +
2 files changed, 207 insertions(+), 34 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 000..bde9c77
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,49 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : fsl,chip-fb, chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+ Documentation/devicetree/bindings/video/display-timing.txt
+ Additional, the display node has to define properties:
+ - fsl,bpp: Bits per pixel
+ - fsl,pcr: LCDC PCR value
+
+Optional properties:
+- dmacr-eukrea: Should be set for eukrea boards.
+
+Example:
+
+ imxfb: fb@10021000 {
+ compatible = fsl,imx27-fb, fsl,imx21-fb;
+ interrupts = 61;
+ reg = 0x10021000 0x1000;
+ display = display0;
+ };
+
+ ...
+
+ display0: display0 {
+ model = Primeview-PD050VL1;
+ native-mode = timing_disp0;
+ fsl,bpp = 16; /* non-standard but required */
+ fsl,pcr = 0xf0c88080; /* non-standard but required */
+ display-timings {
+ timing_disp0: 640x480 {
+ hactive = 640;
+ vactive = 480;
+ hback-porch = 112;
+ hfront-porch = 36;
+ hsync-len = 32;
+ vback-porch = 33;
+ vfront-porch = 33;
+ vsync-len = 2;
+ clock-frequency = 2500;
+ };
+ };
+ };
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index ef2b587..5a9bc598 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -32,6 +32,12 @@
#include linux/io.h
#include linux/math64.h
#include linux/uaccess.h
+#include linux/of.h
+#include linux/of_device.h
+
+#include video/of_display_timing.h
+#include video/of_videomode.h
+#include video/videomode.h
#include linux/platform_data/video-imxfb.h
@@ -117,10 +123,13 @@
#define LGWCR_GWAV(alpha) (((alpha) 0xff) 24)
#define LGWCR_GWE (1 22)
+#define IMXFB_LSCR1_DEFAULT 0x00120300
+#define IMXFB_DMACR_DEFAULT 0x00020010
+#define IMXFB_DMACR_EUKREA_DEFAULT 0x00040060
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
-
/*
* These are the bitfields for each
* display depth that we support.
@@ -192,6 +201,19 @@ static struct platform_device_id imxfb_devtype[] = {
};
MODULE_DEVICE_TABLE(platform, imxfb_devtype);
+static struct of_device_id imxfb_of_dev_id[] = {
+ {
+ .compatible = fsl,imx1-fb,
+ .data = imxfb_devtype[IMX1_FB],
+ }, {
+ .compatible = fsl,imx21-fb,
+ .data = imxfb_devtype[IMX21_FB],
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
+
static inline int is_imx1_fb(struct imxfb_info *fbi)
{
return fbi-devtype == IMX1_FB;
@@ -324,6 +346,9 @@ static const struct imx_fb_videomode
*imxfb_find_mode(struct imxfb_info *fbi)
struct imx_fb_videomode *m;
int i;
+ if (!fb_mode)
+ return fbi-mode[0];
+
for (i = 0, m = fbi-mode[0]; i fbi-num_modes; i++, m++) {
if (!strcmp(m-mode.name, fb_mode))
return m;
@@ -479,6 +504,9 @@ static int imxfb_bl_update_status(struct backlight_device
*bl)
struct imxfb_info *fbi = bl_get_data(bl);
int brightness = bl-props.brightness;
+ if (!fbi-pwmr)
+ return 0;
+
if (bl-props.power != FB_BLANK_UNBLANK)
brightness = 0;
if (bl-props.fb_blank != FB_BLANK_UNBLANK)
@@ -719,7 +747,8 @@ static int imxfb_activate_var(struct fb_var_screeninfo
*var, struct fb_info *inf
writel(fbi-pcr, fbi-regs + LCDC_PCR);
#ifndef PWMR_BACKLIGHT_AVAILABLE
- writel(fbi-pwmr, fbi-regs + LCDC_PWMR);
+ if (fbi-pwmr)
+ writel(fbi-pwmr, fbi-regs + LCDC_PWMR);
#endif
[PATCH v3 1/2] imxfb: Set alpha value of the framebuffer
From: Christian Hemp c.h...@phytec.de
Based on Sascha Hauer's patch i.MX27 clock: Do not disable lcd clocks during
startup.
This patch gives a interface to chance the alphavalue of the framebuffer.
Signed-off-by: Christian Hemp c.h...@phytec.de
rebased to 3.7
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/video/imxfb.c | 35 +++
include/linux/platform_data/video-imxfb.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..ef2b587 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -31,6 +31,7 @@
#include linux/dma-mapping.h
#include linux/io.h
#include linux/math64.h
+#include linux/uaccess.h
#include linux/platform_data/video-imxfb.h
@@ -112,6 +113,10 @@
#define LCDISR_EOF (11)
#define LCDISR_BOF (10)
+#define LCDC_LGWCR 0x64
+#define LGWCR_GWAV(alpha) (((alpha) 0xff) 24)
+#define LGWCR_GWE (1 22)
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
@@ -610,6 +615,35 @@ static int imxfb_blank(int blank, struct fb_info *info)
return 0;
}
+static int imxfb_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ struct imxfb_info *fbi = info-par;
+ int alpha, ret = 0;
+ unsigned int tmp;
+
+ switch (cmd) {
+ case IMXFB_ALPHA:
+ if (get_user(alpha, (int __user *)arg)) {
+ ret = -EFAULT;
+ } else {
+ tmp = readl(fbi-regs + LCDC_LGWCR);
+ tmp = ~LGWCR_GWAV(0xff);
+ tmp |= LGWCR_GWAV(alpha);
+ if (!alpha)
+ tmp = ~LGWCR_GWE;
+ else
+ tmp |= LGWCR_GWE;
+ writel(tmp , fbi-regs + LCDC_LGWCR);
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
static struct fb_ops imxfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = imxfb_check_var,
@@ -619,6 +653,7 @@ static struct fb_ops imxfb_ops = {
.fb_copyarea= cfb_copyarea,
.fb_imageblit = cfb_imageblit,
.fb_blank = imxfb_blank,
+ .fb_ioctl = imxfb_ioctl,
};
/*
diff --git a/include/linux/platform_data/video-imxfb.h
b/include/linux/platform_data/video-imxfb.h
index 9de8f06..ce3875f 100644
--- a/include/linux/platform_data/video-imxfb.h
+++ b/include/linux/platform_data/video-imxfb.h
@@ -51,6 +51,9 @@
#define DMACR_HM(x)(((x) 0xf) 16)
#define DMACR_TM(x)((x) 0xf)
+#define IMXFB_IOW(num, dtype) _IOW('I', num, dtype)
+#define IMXFB_ALPHAIMXFB_IOW(31, int)
+
struct imx_fb_videomode {
struct fb_videomode mode;
u32 pcr;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform support
Hi Heiko, On Friday 05 of April 2013 01:15:02 Heiko Stübner wrote: Am Donnerstag, 4. April 2013, 18:36:57 schrieb Tomasz Figa: This series is an attempt to make the samsung-time clocksource driver ready for multiplatform kernels. It moves the driver to drivers/clocksource, cleans it up from uses of static platform-specific definitions, simplifies timer interrupt handling and adds Device Tree support. Only samsung-time driver is reworked to use the master driver at this time, since the PWM driver can be already considered broken at the moment and needs separate series of several patches to fix and clean it up, which I am already working on. Tested on Universal C210 board with Device Tree. Not tested without Device Tree, since it has been already broken before this series. Compile tested for other related SoCs. Looks nice. On a non-DT S3C2416 board: Tested-by: Heiko Stuebner he...@sntech.de Thanks for testing. And just so I don't search myself silly, am I right in thinking that the driver does not use the generic clocksource registration yet and dt machines must still use samsung_timer_init at this point? Yes. Because of the build failures it caused recently I have decided not to use it yet. It can be added with a small patch later, though. Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Kernel and System Framework ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/04/2013 07:41 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130404 00:39]:
On 04/04/2013 02:42 AM, Tony Lindgren wrote:
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
+static struct clk *scrm_clks[] = {
+ auxclk0_ck,
+ auxclk1_ck,
+ auxclk2_ck,
+ auxclk3_ck,
+ auxclk4_ck,
+ auxclk5_ck,
+};
Hmm I don't like the idea of specifying the auxclk both in the
cclock44xx_data.c and in DT..
Right, but till we have all clocks moved to DT we only need this
approach for general purpose clocks that are not mapped to devices
by hwmod.
For v3.10, let's just make sure that USB works with DT as then
after v3.10 we can make omap4 DT only and get rid of estimated
7K lines of code and data. I guess this is the last piece missing
for that, or are we also missing something else?
For panda we just need a way to map the auxclk to the USB PHY device
and the relevant dts data to get USB host working with DT.
Beagle USB host should work already with DT without any changes.
Can't you set up a clock alias for your device so it can find the
auxclk when requesting it with the dev entry?
which clock is mapped to which PHY device depends on board design
and that cannot be per-determined at one place. This information
needs to come from the board.dts file.
There was an earlier attempt to provide a way of building clock aliases
at runtime from device tree [1], but the current approach is way better
[1]
https://lkml.org/lkml/2013/3/12/241
For the DT clock driver if needed for v3.10, how about just do a
minimal drivers/clock/omap/ that uses the standard binding?
Then that driver can just do clk_get() from cclock44xx_data.c
I don't understand how to do it and why it is better than the current
approach.
How can that driver do clk_get() from cclock44xx_data.c?
from where does it get the clk_id to pass into clk_get()?
for now? And then later on we'll just move all the clocks to a
combination of DT + /lib/firmware.
What is the benefit of moving clock data to /lib/firmware? We could
as well just move it to DT only, no?
e.g. auxclk are required to be specified in DT nodes for USB PHY.
Without this we can't get USB host working on Panda.
OK. So if the USB PHY has a dev entry, can't you just set up a
clock alias in struct omap_clk omap44xx_clks[] for it?
I've explained why this can't be done above.
As Rajendra points out, it seems moving entire clock data to DT is not
going to happen soon. So this is the simplistic way things can work.
Right but seems like we can get started there without moving
them all at once.
What if we provide a complete clock list instead of only auxclks in
dt_clks[]?
This approach is similar to arch/arm/mach-imx/clk-imx35.c
Device drivers can then use them as they migrate to DT. Then later
we could migrate clock data to DT, without impacting device drivers.
cheers,
-roger
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] gpio/omap: 2nd batch of updates for v3.10
On 04/05/2013 01:35 AM, Santosh Shilimkar wrote: On Friday 05 April 2013 01:46 AM, Jon Hunter wrote: Main change is ensuring that the state of a gpio bank is restored when booting with device-tree. The rest of the patches are clean-ups and one optimisation. The patch modifying the *.dtsi files should go via Benoit Cousson's for_3.10/dts branch [1] as it is dependent on changes in his branch but I have included here for completeness. Testing includes: - Boot testing on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP, OMAP4430 SDP and AM335x EVM. - Verified that GPIO interrupts are working on OMAP5912 OSK, OMAP2420 H4, OMAP3430 SDP and OMAP4430 SDP by making sure networking was working correctly as these boards use a GPIO with the ethernet chips. Also checked /proc/interrupts to ensure GPIO interrupt counts are incrementing as expected. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git Jon Hunter (4): gpio/omap: free irq domain in probe() failure paths gpio/omap: optimise interrupt service routine gpio/omap: force restore if context loss is not detectable ARM: dts: OMAP2+: Identify GPIO banks that are always powered Tarun Kanti DebBarma (1): gpio/omap: remove extra context restores in *_runtime_resume() Thanks Jon for pulling the fixes. I suggest you to split the series so that 'gpio/omap:*' can be pulled by Grant and 'ARM: dts:*' by Benoit. Agreed. I had kept them altogether here for completeness as it would have been odd to add a new property but not use it. If everyone is ok with the changes, then I can either resend or Grant/Linus just pick up 1-4. All the 'gpio/omap:*' patches in the series looks fine to me. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] clk: Exynos: Register audio subsytem clocks using common clk framework
Hi Padmavathi,
On 04/05/2013 08:40 AM, Padmavathi Venna wrote:
Samsung Exynos SoC has a separate subsystem for audio. This subsystem
has a internal clock controller which controls i2s0 and pcm0 clocks.
This patch series adds the Samsung Exynos SoC audio subsytem clock code
to the common clock framework and provides the I2S0 clock information in
the dtsi file.
Padmavathi Venna (3):
clk: exynos: register audio subsystem clocks using common clock
framework
ARM: dts: add Exynos audio subsystem clock controller node
ARM: dts: add clock provider information for i2s0 controller in
Exynos5250
arch/arm/boot/dts/exynos5250.dtsi |8 ++
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos-audss.c | 139
3 files changed, 148 insertions(+), 0 deletions(-)
create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
It looks good, it's very similar what we have written recently for Exynos4.
It seems the binding documentation is missing in this patch set. I've included
below content of our .../bindings/clock/exynos4-audss-clock.txt file. Feel free
to reuse any parts of it.
From a brief look Exynos4 and Exynos5 Audio Subsystem CLKCON very similar.
I've just found bit 2 of 0x0381_0008 register is not used on Exynos5250.
Additionally the Audio Subsystem Clock controller is present on S5PV210
SoCs and IMO compatible property you used is too generic. I would propose
to use at least:
samsung,s5pv210-audss-clock- for S5PV210
samsung,exynos4210-audss-clock - for Exynos4
samsung,exynos5250-audss-clock - for Exynos5
8---
* Samsung Exynos4 Audio Subsystem Clock Controller
The Exynos4 Audio Subsystem clock controller generates and supplies clocks
to Audio Subsystem block available in the Exynos4 SoCs. The clock binding
described here is applicable to all SoC's in the Exynos4 family.
Required Properties:
- compatible: should be one of the following:
- samsung,exynos4210-audss-clock - controller compatible with all Exynos4
SoCs.
- reg: physical base address and length of the controller's register set.
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume. Some of the clocks are available only on a particular
Exynos4 SoC and this is specified where applicable.
Provided clocks:
Clock ID SoC (if specific)
---
mout_audss 0
dout_rp 1
dout_aud_bus2
mout_i2s3
dout_i2sclk04
clk_i2s05
clk_pcm06
Example 1: An example of a clock controller node is listed below.
clock_audss: clock-controller@0381 {
compatible = samsung,exynos4-audss-clock;
reg = 0x0381 0x0C;
#clock-cells = 1;
};
Example 2: I2S controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
i2s0: i2s@0383 {
compatible = samsung,i2s-v5;
reg = 0x0383 0x100;
clocks = clock_audss 0, clock_audss 3, clock_audss 1,
clock_audss 2, clock_audss 4, clock_audss 2;
clock-names = mout_audss, mout_i2s, dout_srp,
dout_bus, dout_i2s, i2s_opclk0;
};
8---
Thanks,
Sylwester
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/2] omap_hsmmc DT DMA Client support
On Wednesday 06 March 2013 07:42 PM, Matt Porter wrote: Changes since v2: - dropped skip platform_get_resource_byname() patch Changes since v1: - rebase to 3.9-rc1, previous dependencies upstream This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers and the dma_request_slave_channel_compat() wrapper to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. Matt Porter (2): mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: add generic DMA request support to the DT binding Looks good to me Acked-by: Balaji T K balaj...@ti.com .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +++- drivers/mmc/host/omap_hsmmc.c | 10 ++-- 2 files changed, 33 insertions(+), 3 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next v2] spi: tegra: slink: make local symbols static
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Neither tegra20_spi_cdata nor tegra30_spi_cdata are used outside this
file so they can, and should, be static.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/spi/spi-tegra20-slink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 4e58b53..b224a82 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1087,11 +1087,11 @@ static struct tegra_spi_platform_data
*tegra_slink_parse_dt(
return pdata;
}
-const struct tegra_slink_chip_data tegra30_spi_cdata = {
+static const struct tegra_slink_chip_data tegra30_spi_cdata = {
.cs_hold_time = true,
};
-const struct tegra_slink_chip_data tegra20_spi_cdata = {
+static const struct tegra_slink_chip_data tegra20_spi_cdata = {
.cs_hold_time = false,
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] clk: exynos: register audio subsystem clocks using common clock framework
On 04/05/2013 08:23 AM, Padmavathi Venna wrote:
Audio subsystem is introduced in exynos platforms. This has seperate
clock controller which can control i2s0 and pcm0 clocks. This patch
registers the audio subsystem clocks with the common clock framework.
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos-audss.c | 139
2 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index b7c232e..1876810 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
+obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
new file mode 100644
index 000..d7f9aa8
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Padmavathi Venna padm...@samsung.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.
+ *
+ * Common Clock Framework support for Audio clks.
s/clks/Subsystem Clock Controller ?
+*/
+
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk-provider.h
+#include linux/of_address.h
+#include linux/syscore_ops.h
+
+static DEFINE_SPINLOCK(lock);
+static struct clk **clk_table;
+static void __iomem *reg_base;
+#ifdef CONFIG_OF
Is this really required ? This driver is for ARCH_EXYNOS which is
going to be DT only anyway - presumably it would depend on OF.
+static struct clk_onecell_data clk_data;
+#endif
+
+#define ASS_CLK_SRC 0x0
+#define ASS_CLK_DIV 0x4
+#define ASS_CLK_GATE 0x8
+
+static unsigned long reg_save[][2] = {
+ {ASS_CLK_SRC, 0x0},
nit: '0x' could be probably omitted.
+ {ASS_CLK_DIV, 0x0},
+ {ASS_CLK_GATE, 0x0},
+};
+
+/*
+ * Let each supported clock get a unique id. This id is used to lookup the
clock
+ * for device tree based platforms.
+ *
+ * When adding a new clock to this list, it is advised to add it to the end.
+ * That is because the device tree source file is referring to these ids and
+ * any change in the sequence number of existing clocks will require
+ * corresponding change in the device tree files. This limitation would go
away
+ * when pre-processor support for dtc would be available.
It's already available. Also please see [1]. IMO the best would be to
create a header file including #defines for all the clocks indexes as
per enum exynos_audss_clks. This header would be put in a common location
so it can be included by the driver and the dts files.
+ */
+enum exynos_audss_clks {
+ /* audss clocks */
+ mout_audss, mout_i2s,
+ dout_srp, dout_bus, dout_i2s,
+ srp_clk, i2s_bus, sclk_i2s0,
+
+ nr_clks,
+};
+
+/* list of all parent clock list */
+static const char *mout_audss_p[] = { fin_pll, fout_epll };
+static const char *mout_i2s_p[] = { mout_audss, cdclk0, sclk_audio0 };
+
+#ifdef CONFIG_PM_SLEEP
+static int exynos_audss_clk_suspend(void)
+{
+ int i;
+
+ for (i = 0; i 3; i++)
+ reg_save[i][1] = __raw_readl(reg_base + reg_save[i][0]);
Why using the __raw_* accessors ? I think it should be readl().
+
+ return 0;
+}
+
+static void exynos_audss_clk_resume(void)
+{
+ int i;
+
+ for (i = 0; i 3; i++)
+ __raw_writel(reg_save[i][1], reg_base + reg_save[i][0]);
Same here, writel().
+}
+
+static struct syscore_ops exynos_audss_clk_syscore_ops = {
+ .suspend= exynos_audss_clk_suspend,
+ .resume = exynos_audss_clk_resume,
+};
+#endif /* CONFIG_PM_SLEEP */
+
+/* register exynos_audss clocks */
+void __init exynos_audss_clk_init(struct device_node *np)
+{
Isn't it better to just do
if (np == NULL)
return;
i.e. just skip the initialization altogether ? panic() seems
unreasonable here.
+ if (np) {
+ reg_base = of_iomap(np, 0);
+ if (!reg_base)
+ panic(%s: failed to map registers\n, __func__);
+ } else
+ panic(%s: unable to determine soc\n, __func__);
+
+ clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
+ if (!clk_table)
+ panic(could not allocate clock lookup table\n);
+
+ clk_data.clks = clk_table;
+ clk_data.clk_num = nr_clks;
+ of_clk_add_provider(np, of_clk_src_onecell_get, clk_data);
+
+
Re: [PATCH -next v2] spi: tegra: slink: make local symbols static
On Fri, Apr 05, 2013 at 09:45:36PM +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Neither tegra20_spi_cdata nor tegra30_spi_cdata are used outside this
file so they can, and should, be static.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/spi/spi-tegra20-slink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 4e58b53..b224a82 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1087,11 +1087,11 @@ static struct tegra_spi_platform_data
*tegra_slink_parse_dt(
return pdata;
}
-const struct tegra_slink_chip_data tegra30_spi_cdata = {
+static const struct tegra_slink_chip_data tegra30_spi_cdata = {
.cs_hold_time = true,
};
-const struct tegra_slink_chip_data tegra20_spi_cdata = {
+static const struct tegra_slink_chip_data tegra20_spi_cdata = {
.cs_hold_time = false,
};
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
pgpxZhFC0uB3u.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
On Fri, Apr 5, 2013 at 11:56 AM, Florian Fainelli flor...@openwrt.org wrote:
[snip]
Florian,
took me a while to try you patches out on Dove but now I fixed all
issues. I will
comment on all related patches but first I want to comment here.
One general note for Dove related patches: You didn't remove the registration of
ge platform_device from mach-dove/board-dt.c. That will lead to double
registration
of mdio and mv643xx_eth/shared, so you'll never be sure if DT or non-DT code is
executed. I haven't checked mach-kirkwood/board-dt.c or orion5x code.
if (!mv643xx_eth_version_printed++)
pr_notice(MV-643xx 10/100/1000 ethernet driver version
%s\n,
This is not related to your change, but there is a problem in this
function that has already been discussed in the past if I remember
correctly: The respective clock needs to be enabled here (at least
on Kirkwood), since accesses to the hardware are done below.
Enabling the clock only in mv643xx_eth_probe() is too late.
As said, this is not a problem introduced by your changes (and which
is currently circumvented by enabling the respective clocks in
kirkwood_legacy_clk_init() and kirkwood_ge0x_init()), but we might
want to fix this now to get rid of unconditionally enabling the GE
clocks in the DT case.
I think there may have been some confusion between the ethernet-group
clock and the actual Ethernet port inside the ethernet-group. The
mv643xx_eth driver assumes we have a per-port clock gating scheme, while I
think we have a per ethernet-group clock gating scheme instead. Like you
said, I think this should be addressed separately.
IMHO, there should be a clocks property where ever you try to access registers,
i.e. in all three parts mv643xx_eth_shared (group), mv643xx_eth
(port) and mdio.
Since port depends on shared it would be ok to have it per group but that may
collide with other SoCs than Dove/Kirkwood that have per port clocks.
Is that separation (group/port) really required for any SoC?
[snip]
You don't change the clk initialization here:
#if defined(CONFIG_HAVE_CLK)
mp-clk = clk_get(pdev-dev, (pdev-id ? 1 : 0));
if (!IS_ERR(mp-clk)) {
clk_prepare_enable(mp-clk);
mp-t_clk = clk_get_rate(mp-clk);
}
#endif
Which, if I understand correctly, works in the DT case because you
assign clock-names to the clocks in the DTS. However, I wonder
whether this works for any but the first Ethernet device.
Yes, it does. Assigned clocks from clocks property get a clock alias for
that device name (node name). Using anything else than NULL here is
IMHO just wrong. We should rather provide proper clock aliases for non-DT case.
In the old platform device setup, the pdev-id was set when
initialiazing the platform_device structure in common.c. Where is
this done in the DT case?
Looks like you are right, in the DT case, I assume that we should lookup the
clock using NULL instead of 1 or 0 so we match any clock instead of a
specific one.
Yes.
[snip]
In phy_scan(), the phy is searched like this:
snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
orion-mdio-mii, addr);
phydev = phy_connect(mp-dev, phy_id,
mv643xx_eth_adjust_link,
PHY_INTERFACE_MODE_GMII);
But orion-mdio-mii:xx is the name of the PHY if MDIO is setup via a
platform_device. I could not get this to work if the MDIO device is
setup via DT. Am I doing something wrong?
I just missed updating this part of the code to probe for PHYs. The board I
tested with uses a PHY_NONE configuration. I will add the missing bits for
of_phy_connect() to be called here.
I don't think that the ethernet controller should probe the PHY's on mdio-bus
at all. At least not for DT enabled platforms. I had a look at DT and non-DT
mdio-bus sources, and realized that there is a bus scan for non-DT only.
of_mdiobus_register requires you to set (and know) the PHY address.
I prepared a patch for of_mdio_register that will allow you to probe mdio and
assign phy addresses to each node found. Currently, the heuristic for probing
is: assign each phy node the next probed phy_addr starting with 0. But that
will not allow to e.g. set some PHY addresses and probe the rest.
We had a similar discussion whether to probe or not for DT nodes, and I guess
there also will be some discussion about the above patch. OTOH we could just
(again) ask users of every kirkwood/orion5x/dove board to tell their
phy addresses
and fail to probe the phy for new boards...
I will prepare a proper patch soon and post it on the corresponding lists.
Additionally, in phy_scan() there is this:
if (phy_addr == MV643XX_ETH_PHY_ADDR_DEFAULT) {
start = phy_addr_get(mp) 0x1f;
num = 32;
} else {
...
MV643XX_ETH_PHY_ADDR_DEFAULT is defined as 0. However, many Kirkwood
devices use
Re: [PATCHv7 06/17] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
Mike,
Could we have your opinion on this patch, and possibly a Acked-by to
pass it through arm-soc?
Thanks!
Thomas
On Wed, 27 Mar 2013 15:40:23 +0100, Thomas Petazzoni wrote:
The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..b35785a 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst
armada_370_gating_descr[] = {
{ pex1_en, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 9 },
+ { pex0, pex0_en, 5 },
+ { pex1, pex1_en, 9 },
{ sata0, NULL, 15 },
{ sdio, NULL, 17 },
{ tdm, NULL, 25 },
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
Hello Sebastian,
Le 04/05/13 15:58, Sebastian Hesselbarth a écrit :
On Fri, Apr 5, 2013 at 11:56 AM, Florian Fainelli flor...@openwrt.org wrote:
[snip]
Florian,
took me a while to try you patches out on Dove but now I fixed all
issues. I will
comment on all related patches but first I want to comment here.
One general note for Dove related patches: You didn't remove the registration of
ge platform_device from mach-dove/board-dt.c. That will lead to double
registration
of mdio and mv643xx_eth/shared, so you'll never be sure if DT or non-DT code is
executed. I haven't checked mach-kirkwood/board-dt.c or orion5x code.
This was intentional, this patchset is just preparatory in the sense
that it does no conversion of the existing users of the mv643xx_eth
platform driver over DT (have some patches to that though). I wanted to
resume the discussion on these bindings first, then proceed with the
conversion.
if (!mv643xx_eth_version_printed++)
pr_notice(MV-643xx 10/100/1000 ethernet driver version
%s\n,
This is not related to your change, but there is a problem in this
function that has already been discussed in the past if I remember
correctly: The respective clock needs to be enabled here (at least
on Kirkwood), since accesses to the hardware are done below.
Enabling the clock only in mv643xx_eth_probe() is too late.
As said, this is not a problem introduced by your changes (and which
is currently circumvented by enabling the respective clocks in
kirkwood_legacy_clk_init() and kirkwood_ge0x_init()), but we might
want to fix this now to get rid of unconditionally enabling the GE
clocks in the DT case.
I think there may have been some confusion between the ethernet-group
clock and the actual Ethernet port inside the ethernet-group. The
mv643xx_eth driver assumes we have a per-port clock gating scheme, while I
think we have a per ethernet-group clock gating scheme instead. Like you
said, I think this should be addressed separately.
IMHO, there should be a clocks property where ever you try to access registers,
i.e. in all three parts mv643xx_eth_shared (group), mv643xx_eth
(port) and mdio.
Since port depends on shared it would be ok to have it per group but that may
collide with other SoCs than Dove/Kirkwood that have per port clocks.
Ok, which means that we should also teach mv643xx_eth_shared_probe()
about it, as well as the orion-mdio driver. I don't have any particular
objections since it should just make things safer with respect to clocking.
Is that separation (group/port) really required for any SoC?
Probably not, it was not clear when I looked at mv78xx0 if it uses two
ports per group or 4 groups and 1 port. Anyway, since we are re-using
the existing Device Tree binding definition and that the hardware
present itself as ethernet groups and ports, I don't see any problem
with keeping that difference since it allows for fine-grained
representation of the hardware.
[snip]
You don't change the clk initialization here:
#if defined(CONFIG_HAVE_CLK)
mp-clk = clk_get(pdev-dev, (pdev-id ? 1 : 0));
if (!IS_ERR(mp-clk)) {
clk_prepare_enable(mp-clk);
mp-t_clk = clk_get_rate(mp-clk);
}
#endif
Which, if I understand correctly, works in the DT case because you
assign clock-names to the clocks in the DTS. However, I wonder
whether this works for any but the first Ethernet device.
Yes, it does. Assigned clocks from clocks property get a clock alias for
that device name (node name). Using anything else than NULL here is
IMHO just wrong. We should rather provide proper clock aliases for non-DT case.
In the old platform device setup, the pdev-id was set when
initialiazing the platform_device structure in common.c. Where is
this done in the DT case?
Looks like you are right, in the DT case, I assume that we should lookup the
clock using NULL instead of 1 or 0 so we match any clock instead of a
specific one.
Yes.
[snip]
In phy_scan(), the phy is searched like this:
snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
orion-mdio-mii, addr);
phydev = phy_connect(mp-dev, phy_id,
mv643xx_eth_adjust_link,
PHY_INTERFACE_MODE_GMII);
But orion-mdio-mii:xx is the name of the PHY if MDIO is setup via a
platform_device. I could not get this to work if the MDIO device is
setup via DT. Am I doing something wrong?
I just missed updating this part of the code to probe for PHYs. The board I
tested with uses a PHY_NONE configuration. I will add the missing bits for
of_phy_connect() to be called here.
I don't think that the ethernet controller should probe the PHY's on mdio-bus
at all. At least not for DT enabled platforms. I had a look at DT and non-DT
mdio-bus sources, and realized that there is a bus scan for non-DT only.
of_mdiobus_register requires you to set (and know) the PHY address.
One
Re: [PATCHv7 07/17] clk: mvebu: add more PCIe clocks for Armada XP
Mike,
Could we have your opinion on the below patch, and possibly an Acked-by
to carry it through the arm-soc tree?
Thanks,
Thomas
On Wed, 27 Mar 2013 15:40:24 +0100, Thomas Petazzoni wrote:
The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.
It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index b35785a..2f03723 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ ge2, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 6 },
- { pex2, NULL, 7 },
- { pex3, NULL, 8 },
+ { pex00, NULL, 5 },
+ { pex01, NULL, 6 },
+ { pex02, NULL, 7 },
+ { pex03, NULL, 8 },
+ { pex10, NULL, 9 },
+ { pex11, NULL, 10 },
+ { pex12, NULL, 11 },
+ { pex13, NULL, 12 },
{ bp, NULL, 13 },
{ sata0lnk, NULL, 14 },
{ sata0, sata0lnk, 15 },
@@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ xor0, NULL, 22 },
{ crypto, NULL, 23 },
{ tdm, NULL, 25 },
+ { pex20, NULL, 26 },
+ { pex30, NULL, 27 },
{ xor1, NULL, 28 },
{ sata1lnk, NULL, 29 },
{ sata1, sata1lnk, 30 },
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] mfd: stmpe: DT: Enable no-irq mode configuration
Hi Linus, On Fri, Mar 01, 2013 at 01:07:16PM +0100, Linus Walleij wrote: From: Gabriel Fernandez gabriel.fernan...@stericsson.com If there is no interrupt property into stmpe node then activate the no-irq mode by setting the irq value to -1. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Gabriel Fernandez gabriel.fernan...@stericsson.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/mfd/stmpe.c | 3 +++ 1 file changed, 3 insertions(+) Applied to mfd-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/7] kbuild: create an include chroot for DT bindings
On 04/04/2013 08:01 PM, Stephen Warren wrote: On 04/04/2013 05:17 PM, Rob Herring wrote: On 04/03/2013 06:34 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com The recent dtc+cpp support allows header files and C pre-processor defines/macros to be used when compiling device tree files. These headers will typically define various constants that are part of the device tree bindings. The original patch which set up the dtc+cpp include path only considered using those headers from device tree files. However, most are also useful for kernel code which needs to interpret the device tree. In both the DT files and the kernel, I'd like to include the DT-related headers in the same way, for example, dt-bindings/gpio/tegra-gpio.h. That will simplify any text which discusses the DT header locations. Creating a dt-bindings/ for kernel source to use is as simple as placing files into include/dt-bindings/. However, when compiling DT files, the include path should be restricted so that only the dt-bindings path is available; arbitrary kernel headers shouldn't be exposed. For this reason, create a specific include directory for use by dtc+cpp, and symlink dt-bindings from there to the actual location of include/dt-bindings/. For want of a better location, place this include chroot into the existing dts/ directory. arch/*/boot/dts/include/dt-bindings - ../../../../../include/dt-bindings Some headers used by device tree files may not be useful to the kernel; they may be used simply to aid in constructing the DT file (e.g. macros to create a node), but not define any information that the kernel needs to share. These may be placed directly into arch/*/boot/dts/ along with the DT files themselves. Cc: Shawn Guo shawn@linaro.org Cc: Hiroshi Doyu hd...@nvidia.com Acked-by: Michal Marek mma...@suse.cz Acked-by: Shawn Guo shawn@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: Stephen Warren swar...@nvidia.com --- Grant, Rob, Michal, I'm hoping for acks or comments from you so this series can be placed into a topic branch in the arm-soc repo, for others to build on during the 3.10 kernel cycle. Thanks. Well, you have mine here and the rest looks fine, so add it to the others. Rob, I had originally hoped for this to go into an arm-soc branch so that a number of SoCs could convert to use the feature in the same release, hence I was looking for acks to let that happen. However, it's too late in the 3.10 cycle now for that to happen. Can the series be applied to the DT tree instead; people can convert during the 3.11 cycle. That is fine. Can you send me a pull request. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] mfd: stmpe: DT: Add stmpe-i2c dt alias to get id device
Hi Linus, On Fri, Mar 01, 2013 at 01:07:26PM +0100, Linus Walleij wrote: From: Gabriel Fernandez gabriel.fernan...@stericsson.com This patch augments the STMP driver to read the device id from the stmpe-i2c dt alias if present. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Gabriel Fernandez gabriel.fernan...@stericsson.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/mfd/stmpe.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Applied to mfd-next as well. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10 0/12] Palmas updates
Hi Ian, On Fri, Mar 22, 2013 at 02:55:10PM +, Ian Lartey wrote: This patchset adds to the support for the Palmas series of PMIC chips. Some of the patches have previously been submitted individually. The DT bindings doc has been added first due to comments that it was missing. Patches based on linux-next-20130319 Are you expecting all those patches to go through the MFD tree ? Also, you stil have a few comments from Milo and Stephen to adress. Are you planning to send a v11 ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10 03/12] mfd: palmas add variant and OTP detection
Hi Ian,
On Fri, Mar 22, 2013 at 02:55:13PM +, Ian Lartey wrote:
@@ -278,20 +329,20 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
int ret;
u32 prop;
- ret = of_property_read_u32(node, ti,mux_pad1, prop);
+ ret = of_property_read_u32(node, ti,mux-pad1, prop);
if (!ret) {
pdata-mux_from_pdata = 1;
pdata-pad1 = prop;
}
- ret = of_property_read_u32(node, ti,mux_pad2, prop);
+ ret = of_property_read_u32(node, ti,mux-pad2, prop);
if (!ret) {
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
/* The default for this register is all masked */
- ret = of_property_read_u32(node, ti,power_ctrl, prop);
+ ret = of_property_read_u32(node, ti,power-ctrl, prop);
if (!ret)
pdata-power_ctrl = prop;
else
@@ -309,7 +360,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg;
int slave;
struct mfd_cell *children;
The '-' to '_' fix has been sent by J Keerthy and is on my mfd-next tree
aready. Would you mind removing it from this patch ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
Hi Tomasz, On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: This patch adds master driver for PWM/timer block available on many Samsung SoCs providing clocksource and PWM output capabilities. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/pwm/pwm-samsung.txt| 37 ++ drivers/clocksource/Kconfig| 1 + drivers/mfd/Kconfig| 3 + drivers/mfd/Makefile | 1 + drivers/mfd/samsung-pwm.c | 439 + drivers/pwm/Kconfig| 1 + include/linux/mfd/samsung-pwm.h| 49 +++ include/linux/platform_data/samsung-pwm.h | 28 ++ 8 files changed, 559 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt create mode 100644 drivers/mfd/samsung-pwm.c create mode 100644 include/linux/mfd/samsung-pwm.h create mode 100644 include/linux/platform_data/samsung-pwm.h Why is that an MFD driver, and why aren't you using the PWM APIs for it ? Also, you probably want to look at using the regmap APIs for your IO. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
On 04/04/2013 11:50 AM, Will Deacon wrote:
This patch adds a description of the device tree binding for the ARM
System MMU architecture.
Cc: Rob Herring robherri...@gmail.com
Cc: Andreas Herrmann andreas.herrm...@calxeda.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
Hello,
The driver for this is still a WIP. Both Andreas and myself have prototype
code, but we're planning to merge that together to get something more
general. Deciding on the binding is a good first step.
Thanks for getting this out.
All comments welcome,
Will
.../devicetree/bindings/iommu/arm,smmu.txt | 61
++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 000..938325f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,61 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2
+ depending on the version of the architecture
+ implemented.
We can keep these, but we should have specific models like arm,smmu-400,
etc. as well.
+
+- reg : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+ device.
+
+- interrupts: Interrupt list, with the first #global-irqs entries
+ corresponding to the global interrupts and any
+ following entries corresponding to context interrupts,
+ specified in order of their indexing by the SMMU.
+
+- mmu-masters : A list of phandles to device nodes representing bus
+ masters for which the SMMU can provide a translation.
+
+- stream-ids: A list of 16-bit values corresponding to the StreamIDs
+ for the devices listed in the mmu-masters property.
+ This list must be same length as mmu-masters, so
+ masters with multiple stream-ids will have multiple
+ entries in mmu-masters.
Your example below is actually 32-bit values in the DTB. You can
annotate them to actually be 16-bit if you want. But I would just leave
them as 32-bit.
+
+** System MMU optional properties:
+
+- smmu-parent : When multiple SMMUs are chained together, this
+ property can be used to provide a phandle to the
+ parent SMMU (that is the next SMMU on the path going
+ from the mmu-masters towards memory) node for this
+ SMMU.
Does the SMMU need to know if it is coherent or not?
Rob
+
+Example:
+
+smmu {
+compatible = arm,smmu-v1;
+reg = 0xba5e 0x1;
+#global-interrupts = 2;
+interrupts = 0 32 4,
+ 0 33 4,
+ 0 34 4, /* This is the first context
interrupt */
+ 0 35 4,
+ 0 36 4,
+ 0 37 4;
+mmu-masters = dma0,
+ dma0,
+ dma1;
+stream-ids = 0xd01d,
+ 0xd01e,
+ 0xd11c;
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
Hi Samuel, On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote: Hi Tomasz, On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: This patch adds master driver for PWM/timer block available on many Samsung SoCs providing clocksource and PWM output capabilities. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/pwm/pwm-samsung.txt| 37 ++ drivers/clocksource/Kconfig| 1 + drivers/mfd/Kconfig| 3 + drivers/mfd/Makefile | 1 + drivers/mfd/samsung-pwm.c | 439 + drivers/pwm/Kconfig | 1 + include/linux/mfd/samsung-pwm.h| 49 +++ include/linux/platform_data/samsung-pwm.h | 28 ++ 8 files changed, 559 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt create mode 100644 drivers/mfd/samsung-pwm.c create mode 100644 include/linux/mfd/samsung-pwm.h create mode 100644 include/linux/platform_data/samsung-pwm.h Why is that an MFD driver, and why aren't you using the PWM APIs for it ? Also, you probably want to look at using the regmap APIs for your IO. The case of Samsung PWM timers is rather complicated. It is a hardware block that can be used at the same time to generate PWM signal and as a system clocksource. There was a discussion on how to solve the problem of sharing the hardware: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500 (see the linked post and replies to it). Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Kernel and System Framework ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
Hi Rob, On Fri, Apr 05, 2013 at 05:43:06PM +0100, Rob Herring wrote: On 04/04/2013 11:50 AM, Will Deacon wrote: This patch adds a description of the device tree binding for the ARM System MMU architecture. Cc: Rob Herring robherri...@gmail.com Cc: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Will Deacon will.dea...@arm.com --- Hello, The driver for this is still a WIP. Both Andreas and myself have prototype code, but we're planning to merge that together to get something more general. Deciding on the binding is a good first step. Thanks for getting this out. No problem. All comments welcome, Will .../devicetree/bindings/iommu/arm,smmu.txt | 61 ++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt new file mode 100644 index 000..938325f --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -0,0 +1,61 @@ +* ARM System MMU Architecture Implementation + +ARM SoCs may contain an implementation of the ARM System Memory +Management Unit Architecture, which can be used to provide 1 or 2 stages +of address translation to bus masters external to the CPU. + +The SMMU may also raise interrupts in response to various fault +conditions. + +** System MMU required properties: + +- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2 + depending on the version of the architecture + implemented. We can keep these, but we should have specific models like arm,smmu-400, etc. as well. Ok, if distinctions need to be between MMU-400 and a v1 implementation, then we can add those strings later. + +- reg : Base address and size of the SMMU. + +- #global-interrupts : The number of global interrupts exposed by the + device. + +- interrupts: Interrupt list, with the first #global-irqs entries + corresponding to the global interrupts and any + following entries corresponding to context interrupts, + specified in order of their indexing by the SMMU. + +- mmu-masters : A list of phandles to device nodes representing bus + masters for which the SMMU can provide a translation. + +- stream-ids: A list of 16-bit values corresponding to the StreamIDs + for the devices listed in the mmu-masters property. + This list must be same length as mmu-masters, so + masters with multiple stream-ids will have multiple + entries in mmu-masters. Your example below is actually 32-bit values in the DTB. You can annotate them to actually be 16-bit if you want. But I would just leave them as 32-bit. I'm also parsing them as u32 in my driver, so yes, u32 it is! + +** System MMU optional properties: + +- smmu-parent : When multiple SMMUs are chained together, this + property can be used to provide a phandle to the + parent SMMU (that is the next SMMU on the path going + from the mmu-masters towards memory) node for this + SMMU. Does the SMMU need to know if it is coherent or not? You mean with respect to table walks? That's actually probable from the device (along with a whole bunch of other parameters) using SMMU_IDR0. I'll fix up the other comments and send out a v2 next week. Cheers for the review, Will ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 April 2013, Tomasz Figa wrote: On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote: Hi Tomasz, On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: This patch adds master driver for PWM/timer block available on many Samsung SoCs providing clocksource and PWM output capabilities. Why is that an MFD driver, and why aren't you using the PWM APIs for it ? Also, you probably want to look at using the regmap APIs for your IO. The case of Samsung PWM timers is rather complicated. It is a hardware block that can be used at the same time to generate PWM signal and as a system clocksource. There was a discussion on how to solve the problem of sharing the hardware: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500 (see the linked post and replies to it). I don't think anyone ever suggested using a private API though. I think it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere else easily, but you should really register it to the pwm subsystem to expose that functionality, not export functions that can be used by a pwm shim driver, which even seems to be missing from the series. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] ARM: bcm281xx: Add DT support for SMC handler
On Thu, Mar 14, 2013 at 3:14 PM, Christian Daudt c...@broadcom.com wrote: - Adds devicetree binding and documentation for the smc handler Updates from V1: - Created this separate patch for the DT portion - Added SoC compatible to smc binding ... any willing reviewers ? Thanks, csd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 of April 2013 19:05:24 Arnd Bergmann wrote: On Friday 05 April 2013, Tomasz Figa wrote: On Friday 05 of April 2013 18:39:58 Samuel Ortiz wrote: Hi Tomasz, On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: This patch adds master driver for PWM/timer block available on many Samsung SoCs providing clocksource and PWM output capabilities. Why is that an MFD driver, and why aren't you using the PWM APIs for it ? Also, you probably want to look at using the regmap APIs for your IO. The case of Samsung PWM timers is rather complicated. It is a hardware block that can be used at the same time to generate PWM signal and as a system clocksource. There was a discussion on how to solve the problem of sharing the hardware: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16480/focus=16500 (see the linked post and replies to it). I don't think anyone ever suggested using a private API though. I must have gotten the last paragraph of http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638 wrong then. For me it seemed like the timer driver would expose a private API to the PWM driver. I think it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere else easily, but you should really register it to the pwm subsystem to expose that functionality, not export functions that can be used by a pwm shim driver, which even seems to be missing from the series. Anyway, using PWM API in a clocksource driver that needs to be running very early (before any initcalls get called) seems a bit weird for me, especially when PWM API doesn't provide such fine grained control over PWM timers that is required in the clocksource drivers. Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Kernel and System Framework ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
On Fri, Apr 05, 2013 at 03:58:03PM +0200, Sebastian Hesselbarth wrote:
I don't think that the ethernet controller should probe the PHY's on mdio-bus
at all. At least not for DT enabled platforms. I had a look at DT and non-DT
mdio-bus sources, and realized that there is a bus scan for non-DT only.
of_mdiobus_register requires you to set (and know) the PHY address.
DT platforms should have the option to use the standard phy-phandle
connection:
mdio@72004 {
#address-cells = 1;
#size-cells = 0;
compatible = marvell,orion-mdio;
reg = 0x72004 0x84;
status = disabled;
+PHY1: ethernet-phy@1 {
+reg = 1;
+device_type = ethernet-phy;
+};
};
ethernet-group@72000 {
#address-cells = 1;
#size-cells = 0;
compatible = marvell,mv643xx-eth-block;
reg = 0x72000 0x4000;
tx-csum-limit = 1600;
status = disabled;
egiga0: ethernet@0 {
device_type = network;
compatible = marvell,mv643xx-eth;
reg = 0;
interrupts = 29;
clocks = gate_clk 2;
+ phy-handle = PHY1;
};
};
When phy-handle is present the ethernet driver should not probe/scan for
phys.
There is standard code to handle all of this - an important gain is
that the phy driver now has access to a DT node and can apply
phy-specific properties.
We had a similar discussion whether to probe or not for DT nodes,
and I guess there also will be some discussion about the above
patch. OTOH we could just (again) ask users of every
kirkwood/orion5x/dove board to tell their phy addresses and fail to
probe the phy for new boards...
Maybe print a warning and call the no-DT phy probe code if phy-handle
is nor present?
Not sure this should be in the common code, phy probing is sketchy, it
shouldn't be encouraged, IMHO..
Jason
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
On 04/05/2013 11:57 AM, Will Deacon wrote: Hi Rob, On Fri, Apr 05, 2013 at 05:43:06PM +0100, Rob Herring wrote: [...] +- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2 + depending on the version of the architecture + implemented. We can keep these, but we should have specific models like arm,smmu-400, etc. as well. Ok, if distinctions need to be between MMU-400 and a v1 implementation, then we can add those strings later. No, you want to have specific values in the dtb's up front. If there is something needed later in the kernel, you don't want to require a dtb update then. Adding future parts later is fine, but we already know what blocks we have. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5 v2] mv643xx_eth: add Device Tree bindings
On 04/05/2013 08:04 PM, Jason Gunthorpe wrote:
On Fri, Apr 05, 2013 at 03:58:03PM +0200, Sebastian Hesselbarth wrote:
I don't think that the ethernet controller should probe the PHY's on mdio-bus
at all. At least not for DT enabled platforms. I had a look at DT and non-DT
mdio-bus sources, and realized that there is a bus scan for non-DT only.
of_mdiobus_register requires you to set (and know) the PHY address.
DT platforms should have the option to use the standard phy-phandle
connection:
mdio@72004 {
#address-cells =1;
#size-cells =0;
compatible = marvell,orion-mdio;
reg =0x72004 0x84;
status = disabled;
+PHY1: ethernet-phy@1 {
+reg =1;
+device_type = ethernet-phy;
+};
};
ethernet-group@72000 {
#address-cells =1;
#size-cells =0;
compatible = marvell,mv643xx-eth-block;
reg =0x72000 0x4000;
tx-csum-limit =1600;
status = disabled;
egiga0: ethernet@0 {
device_type = network;
compatible = marvell,mv643xx-eth;
reg =0;
interrupts =29;
clocks =gate_clk 2;
+ phy-handle =PHY1;
};
};
When phy-handle is present the ethernet driver should not probe/scan for
phys.
There is standard code to handle all of this - an important gain is
that the phy driver now has access to a DT node and can apply
phy-specific properties.
The above is what I use as a modification of Florian's patches.
I compared of_mdiobus_register against mdiobus_register. The difference
is that DT version does not scan the bus for attached PHYs. That is ok,
if you know the phy_address of the PHY that you pass the handle of. But
in most cases there will be only one PHY on the mdiobus and especially
for new boards probing will help here.
We had a similar discussion whether to probe or not for DT nodes,
and I guess there also will be some discussion about the above
patch. OTOH we could just (again) ask users of every
kirkwood/orion5x/dove board to tell their phy addresses and fail to
probe the phy for new boards...
Maybe print a warning and call the no-DT phy probe code if phy-handle
is nor present?
I think it would be best to spam each probing result during mdiobus
scan to encourage people to edit the DT and put in the phy_addr
directly. IMHO it will be best to have bus scan on mdiobus rather than
ethernet driver.
Not sure this should be in the common code, phy probing is sketchy, it
shouldn't be encouraged, IMHO..
Actually, it is in common code (non-DT case) and I think passing the
phy_addr by DT node like above is best. But for boards you don't
know the address (yet) probing helps a lot. If all phy nodes have their
reg property set, no probing will be performed.
For testing mdio bus probe, I used
mdio {
...
ethphy: ethernet-phy {
reg = 32;
};
};
And 32 should be defined as OF_PHY_ADDR_AUTOSCAN. It is an invalid
address as max phy_addr is 31. I also thought about a bool property
but passing an invalid reg property in SoC file allows to overwrite
it in board file with the actual address easily.
And AFAIK bool properties cannot be removed later on by board specific
nodes.
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] dt: run C pre-processor on *.dts, create some standard headers
Rob, it might be worth keeping this in a separate branch in linux-next so you can pull it out if it causes any issues. I've been using these patches for quite a while now, but there's always opportunity for surprises on architectures I don't use. I did just fix a bug when building with O= a few days back, hence the V2 that I posted as patches. This branch enhances the support for running dtc on device tree files. A dedicated directory is created for header files that provide constants for device-tree bindings. The kbuild dependency script processor is enhanced to support processing the dependency outputs from multiple separate commands at once. The kbuild dtc rule is modified so that the C pre-processor is always applied when compiling any device tree. Some standard headers are created which define common constants for GPIO, IRQ, and ARM GIC device tree bindings. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda3ca3: ARM: dt: create a DT header for the GIC Stephen Warren (7): kbuild: create an include chroot for DT bindings kbuild: fixdep: support concatenated dep files kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp ARM: dt: add header to define GPIO flags ARM: dt: add header to define IRQ flags ARM: dt: create a DT header for the GIC arch/arm/boot/dts/include/dt-bindings |1 + include/dt-bindings/gpio/gpio.h | 15 +++ .../dt-bindings/interrupt-controller/arm-gic.h | 22 + include/dt-bindings/interrupt-controller/irq.h | 19 scripts/Makefile.lib| 17 ++-- scripts/basic/fixdep.c | 93 -- 6 files changed, 125 insertions(+), 42 deletions(-) create mode 12 arch/arm/boot/dts/include/dt-bindings create mode 100644 include/dt-bindings/gpio/gpio.h create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h create mode 100644 include/dt-bindings/interrupt-controller/irq.h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [GIT PULL] dt: run C pre-processor on *.dts, create some standard headers
On 04/05/2013 01:46 PM, Stephen Warren wrote: Rob, it might be worth keeping this in a separate branch in linux-next so you can pull it out if it causes any issues. I've been using these patches for quite a while now, but there's always opportunity for surprises on architectures I don't use. I did just fix a bug when building with O= a few days back, hence the V2 that I posted as patches. No, you're on the hook to fix anything. :) My next branch is pulled by Grant and is not rebased. Perhaps we should change that, but it's not going to happen right away. Rob This branch enhances the support for running dtc on device tree files. A dedicated directory is created for header files that provide constants for device-tree bindings. The kbuild dependency script processor is enhanced to support processing the dependency outputs from multiple separate commands at once. The kbuild dtc rule is modified so that the C pre-processor is always applied when compiling any device tree. Some standard headers are created which define common constants for GPIO, IRQ, and ARM GIC device tree bindings. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda3ca3: ARM: dt: create a DT header for the GIC Stephen Warren (7): kbuild: create an include chroot for DT bindings kbuild: fixdep: support concatenated dep files kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp ARM: dt: add header to define GPIO flags ARM: dt: add header to define IRQ flags ARM: dt: create a DT header for the GIC arch/arm/boot/dts/include/dt-bindings |1 + include/dt-bindings/gpio/gpio.h | 15 +++ .../dt-bindings/interrupt-controller/arm-gic.h | 22 + include/dt-bindings/interrupt-controller/irq.h | 19 scripts/Makefile.lib| 17 ++-- scripts/basic/fixdep.c | 93 -- 6 files changed, 125 insertions(+), 42 deletions(-) create mode 12 arch/arm/boot/dts/include/dt-bindings create mode 100644 include/dt-bindings/gpio/gpio.h create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h create mode 100644 include/dt-bindings/interrupt-controller/irq.h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
HI Wolfram, On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang w...@the-dreams.de wrote: Doug, Separately from a discussion of the technical merits, I'd say that this patch is needed because the Embedded Controller (EC) on the ARM Chromebook shipped expecting to communicate with this scheme. While Uhrm, with all respect, we already shipped it is not a convincing argument regarding inclusion. Benefit for the kernel is. ...but we can also talk technical merits. One person on our team spent a bit of time thinking about this and decided that traditional i2c arbitration can't actually be used in this case (aside from the The details would be extremly interesting here. I am very interested in this and will ask a few questions further on. This is to get a better undestanding for the situation regarding multi-master and what is needed, because I expect some demand for it in the near future. general experience about multimaster being buggy). Specifically, our I'm also interested in these experiences. Thanks for coming back on this. Please see my comments below. The problem here is that the EC is both a master and a slave. It's my understanding that if the AP tries to talk EC on the bus at the same time that the EC is trying to talk to the battery of PMU that we can get into trouble. If I understand correctly, the I2C Specs mention this case explicitly: If a master also incorporates a slave function and it loses arbitration during the addressing stage, it is possible that the winning master is trying to address it. The losing master must therefore switch over immediately to its slave mode. This seems pretty complicated - does the EC then need to compare the address it was sending with the remaining bits that are to be received in that address? Anyway yes we did consider this case at the time, and the STM32 datasheet had mention of it. But it adds quite a bit of complexity. I think the start sequence is intended to make this all work, at least in theory, but it seemed risky to rely on it. The practical problem here is that in my experience the I2C multi-master feature is lightly used in practice, and is quite tricky to get right. That experience was shared with other engineers in the team, and no one was willing to take the risk on getting everything running perfectly with i2c multi-master, or doing it on a tight timeline. I suspect this same problem has arisen many times before, and will arise again, so from that point of view this feature is a useful addition to the kernel. If you are interested in specific experiences then I might be able to collect some comments from people here. For myself I have found that getting a reliable I2C driver at all is a sufficient challenge and time sink with many embedded chips. My memory is a little vague now, but I know that in 2-3 projects we had to use bit-bash due to bugs or insufficient documentation in the chip's dedicated I2C peripheral. One project which had multi-master used a retry scheme with sequenced packets which seemed to work well enough (i.e. adding a layer above the I2C layer to sort out problems). The snow project was more challenging on the I2C ront, due to the critical nature of I2C buses in the device. For snow we found that the Exynos driver did not support arbitration loss, the STM32 driver we had did not support it, the STM32F I2C errata indicated problems with I2C in general which reduced our confidence, and we were unable to determine whether the slave devices on the bus (smart battery and pmic) would definitely do the right thing (both chips had I2C issues which we were tracking). I am not trying to point fingers here, and certainly anything can be solved given sufficient persistence...but keeping to common features that are well-tested and available is prudent. As it was we spent more time on I2C drivers than I would like, and you can get a feel for that in the Chromium bug tracker if you wish. Again, I don't believe this would be an unusual situation in a product development. We need to consider the risk and cost of an approach, rather than just whether it is technically possible. From the point of view of arbitration, the two critical points in the I2C transfer are claiming the bus (detecting that the start condition failed) and detecting loss of arbitration during a transfer. These points need to be tested and validated on all master devices, which can add a considerable burden. Silicon and driver bugs may make this even more onerous and in fact for some non-compliant implementations it simply might not work, or might not work reliably. Please don't take this as a negative view of I2C in general, which is an excellent bus, unmatched for what it was designed in my view. Specifically the EC needs to be switched to master mode to talk to the battery/PMU and thus has a period of time where it won't be listening for the AP's messages. When it talks to the battery, the bus is busy and the EC will not be
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 April 2013, Tomasz Figa wrote: I don't think anyone ever suggested using a private API though. I must have gotten the last paragraph of http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638 wrong then. For me it seemed like the timer driver would expose a private API to the PWM driver. Yes, sorry I wasn't clear enough. I meant a register-level interface exposed from the base driver, not a high-level interface like you did. I think it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere else easily, but you should really register it to the pwm subsystem to expose that functionality, not export functions that can be used by a pwm shim driver, which even seems to be missing from the series. Anyway, using PWM API in a clocksource driver that needs to be running very early (before any initcalls get called) seems a bit weird for me, especially when PWM API doesn't provide such fine grained control over PWM timers that is required in the clocksource drivers. Exactly, that's why you should have a regular PWM driver that gets loaded at a convenient time and just uses an interface exported by the base driver to access the common registers. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
On 04/05/2013 01:37 PM, Simon Glass wrote: HI Wolfram, On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang w...@the-dreams.de wrote: Doug, Separately from a discussion of the technical merits, I'd say that this patch is needed because the Embedded Controller (EC) on the ARM Chromebook shipped expecting to communicate with this scheme. While Uhrm, with all respect, we already shipped it is not a convincing argument regarding inclusion. Benefit for the kernel is. I'm not quite sure why that isn't a convincing argument. The hardware has shipped. I don't know whether the EC microcode can be updated in the field; it seems risky to do so even if it's possible. So, it either gets supported or not; the HW/ucode isn't going to change I suspect. Hence, it seems that the decision would be: a) Disallow the implementation of the arbitration scheme in the kernel, and hence don't support this board in the kernel. (or at least some very core features of this board) b) Allow the implementation of the arbitration scheme in the kernel, and hence make possible support this board in the kernel. From that perspective, the benefit for the kernel question comes down to: do we see a benefit for the kernel to support this board? I can't see why that wouldn't be a benefit. The only disadvantage would be having to carrying code to support that board. That same argument can be made for any board, and I think typically doesn't cause any issue. The code for this I2C mux seems pretty self-contained, so even if it was absolutely terrible (which I don't think it is), it still wouldn't cause any wide-spread issues, I think. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected
When LPAE is activated on Armada XP, all registers and IOs are still 32bit, the 40bit extension is on the CPU to DRAM path (windows) only. That means that all the DMA transfer are restricted to the low 32 bits address space. This is limitation is achieved by selecting ZONE_DMA. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- arch/arm/mach-mvebu/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 440b13e..db1bbc8 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -13,6 +13,7 @@ config ARCH_MVEBU select MVEBU_CLK_CORE select MVEBU_CLK_CPU select MVEBU_CLK_GATING + select ZONE_DMA if ARM_LPAE if ARCH_MVEBU -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs
Hello, The Armada XP SoCs have LPAE support. This is the second version patch set whixh allow to run kernel on this SoCs with LPAE support. The biggest changes are the conversion of the device tree file to 64 bits in order to be able to use more than 4GB of memory (without this the LPAE is pointless). The main change since the first version is the usage of the range property as suggested by Rob Herring. As this massive change on the dts file will have an impact on the mvebu-mbus driver binding, I also added some patches from Thomas Petazzoni. The purpose is to avoid a new big change in the devices tree files when Thomas will improve the mvebu-mbus driver to rely on the device tree. The other point is about DMA usage. LPAE allows to use 40bits address only between CPU and DRAM. All the DMA transfer are restricted to the low 32 bits address space. The first version try to use DMABOUNCE to allows DMA transfer from any place in memory. There were a consensus on the fact that was a something to avoid. The alternative was swiotlb, however it will require a large rewrite of arch/arm/mach-mvebu/coherency.c (our dma_map_ops was defined here), and we are close the opening of the merge window. So I chose, in a first phase, to use ZONE_DMA to limit the use of the DMA on the 32 bits address space. Later our dma_map_ops would be improve with swiotlb. This new patch set have been tested on a Armada XP GP board with 8GB of DRAM with LPAE selected. It have been tested on Armada XP DB board with 3GB of DRAM with and without LPAE. And also on the Armada 370 DB board (without LPAE) to check that no regression appeared. This patch set is based on 3.9-rc5 and is still 3.10 material. The git branch called lpae-v2 is available at: https://github.com/MISL-EBU-System-SW/mainline-public.git. Thanks, Changelog: v1 - v2: * The patch to convert the mvebu device tree files to 64 bits was split in 3 parts: - arm: dts: move all peripherals inside soc from Thomas - then arm: dts: Convert all the mvebu files to use the range property which will allow to keep 32 bits addresses for the internal registers whereas the memory of the system will be 64 bits - and finally arm: dts: Convert mvebu device tree files to 64 bits which was the move to 64 bits itself. * A new patch was added arm: dts: introduce internal-regs node based on the work of Thomas for the mvebu-mbus driver. It introduce a 'internal-regs' subnode, under which all devices are moved. This is not really needed for now, but will be for the mvebu-mbus driver. This generates a lot of code movement since it's indenting by one more tab all the devices. So it was a good opportunity to fix all the bad indentation. * New patch from Thomas fix cpus section indentation to finalize the fixing of the bad indentation * For DMA transfer, DMA_ZONE was selected instead of DMABOUNCE: all the DMA transfer are restricted to the low 32 bits address space. Gregory CLEMENT (4): arm: mvebu: Limit the DMA zone when LPAE is selected arm: dts: mvebu: Convert all the mvebu files to use the range property arm: dts: mvebu: introduce internal-regs node arm: dts: mvebu: Convert mvebu device tree files to 64 bits Lior Amsalem (3): arm: mvebu: Align the internal registers virtual base to support LPAE arm: mvebu: Enable pj4b on LPAE compilations arm: dts: Add a 64 bits version of the skeleton device tree Thomas Petazzoni (2): arm: dts: mvebu: move all peripherals inside soc arm: dts: mvebu: fix cpus section indentation arch/arm/boot/dts/armada-370-db.dts | 110 +- arch/arm/boot/dts/armada-370-mirabox.dts | 80 +++ arch/arm/boot/dts/armada-370-rd.dts | 18 +- arch/arm/boot/dts/armada-370-xp.dtsi | 253 +++--- arch/arm/boot/dts/armada-370.dtsi| 211 +- arch/arm/boot/dts/armada-xp-db.dts | 156 ++--- arch/arm/boot/dts/armada-xp-gp.dts | 138 ++-- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 84 +++ arch/arm/boot/dts/armada-xp-mv78260.dtsi | 110 +- arch/arm/boot/dts/armada-xp-mv78460.dtsi | 136 ++-- arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 198 - arch/arm/boot/dts/armada-xp.dtsi | 191 arch/arm/boot/dts/skeleton64.dtsi| 13 ++ arch/arm/include/debug/mvebu.S |2 +- arch/arm/mach-mvebu/Kconfig |1 + arch/arm/mach-mvebu/armada-370-xp.h |2 +- arch/arm/mm/proc-v7.S|3 +- 17 files changed, 873 insertions(+), 833 deletions(-) create mode 100644 arch/arm/boot/dts/skeleton64.dtsi -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org
[PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base to support LPAE
From: Lior Amsalem al...@marvell.com In order to be able to support he LPAE, the internal registers virtual base must be aligned to 2MB. Signed-off-by: Lior Amsalem al...@marvell.com Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- arch/arm/include/debug/mvebu.S |2 +- arch/arm/mach-mvebu/armada-370-xp.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S index 865c6d0..df191af 100644 --- a/arch/arm/include/debug/mvebu.S +++ b/arch/arm/include/debug/mvebu.S @@ -12,7 +12,7 @@ */ #define ARMADA_370_XP_REGS_PHYS_BASE 0xd000 -#define ARMADA_370_XP_REGS_VIRT_BASE 0xfeb0 +#define ARMADA_370_XP_REGS_VIRT_BASE 0xfec0 .macro addruart, rp, rv, tmp ldr \rp, =ARMADA_370_XP_REGS_PHYS_BASE diff --git a/arch/arm/mach-mvebu/armada-370-xp.h b/arch/arm/mach-mvebu/armada-370-xp.h index c6a7d74..c49c08e 100644 --- a/arch/arm/mach-mvebu/armada-370-xp.h +++ b/arch/arm/mach-mvebu/armada-370-xp.h @@ -16,7 +16,7 @@ #define __MACH_ARMADA_370_XP_H #define ARMADA_370_XP_REGS_PHYS_BASE 0xd000 -#define ARMADA_370_XP_REGS_VIRT_BASE IOMEM(0xfeb0) +#define ARMADA_370_XP_REGS_VIRT_BASE IOMEM(0xfec0) #define ARMADA_370_XP_REGS_SIZESZ_1M #ifdef CONFIG_SMP -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/9] arm: mvebu: Enable pj4b on LPAE compilations
From: Lior Amsalem al...@marvell.com pj4b cpus are LPAE capable so enable them on LPAE compilations Signed-off-by: Lior Amsalem al...@marvell.com Tested-by: Franklin f...@marvell.com Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- arch/arm/mm/proc-v7.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 3a3c015..159c747 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -402,6 +402,8 @@ __v7_ca9mp_proc_info: __v7_proc __v7_ca9mp_setup .size __v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info +#endif /* CONFIG_ARM_LPAE */ + /* * Marvell PJ4B processor. */ @@ -411,7 +413,6 @@ __v7_pj4b_proc_info: .long 0xfff0 __v7_proc __v7_pj4b_setup .size __v7_pj4b_proc_info, . - __v7_pj4b_proc_info -#endif /* CONFIG_ARM_LPAE */ /* * ARM Ltd. Cortex A7 processor. -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/9] arm: dts: Add a 64 bits version of the skeleton device tree
From: Lior Amsalem al...@marvell.com
In order to be able to use more than 4GB address-cells and size-cells
have to be set to 2
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
arch/arm/boot/dts/skeleton64.dtsi | 13 +
1 file changed, 13 insertions(+)
create mode 100644 arch/arm/boot/dts/skeleton64.dtsi
diff --git a/arch/arm/boot/dts/skeleton64.dtsi
b/arch/arm/boot/dts/skeleton64.dtsi
new file mode 100644
index 000..1599415
--- /dev/null
+++ b/arch/arm/boot/dts/skeleton64.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree in the 64 bits version; the bare minimum
+ * needed to boot; just include and add a compatible value. The
+ * bootloader will typically populate the memory node.
+ */
+
+/ {
+ #address-cells = 2;
+ #size-cells = 2;
+ chosen { };
+ aliases { };
+ memory { device_type = memory; reg = 0 0; };
+};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 6/9] arm: dts: mvebu: Convert all the mvebu files to use the range property
This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 16 ++---
arch/arm/boot/dts/armada-370-mirabox.dts | 14 ++--
arch/arm/boot/dts/armada-370-rd.dts | 14 ++--
arch/arm/boot/dts/armada-370-xp.dtsi | 83 +++---
arch/arm/boot/dts/armada-370.dtsi| 49 ++---
arch/arm/boot/dts/armada-xp-db.dts | 28
arch/arm/boot/dts/armada-xp-gp.dts | 20 +++---
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 10 +--
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 18 ++---
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 18 ++---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 22 +++---
arch/arm/boot/dts/armada-xp.dtsi | 65 -
12 files changed, 180 insertions(+), 177 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..183901c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,11 +30,11 @@
};
soc {
- serial@d0012000 {
+ serial@12000 {
clock-frequency = 2;
status = okay;
};
- sata@d00a {
+ sata@a {
nr-ports = 2;
status = okay;
};
@@ -49,18 +49,18 @@
};
};
- ethernet@d007 {
+ ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
- ethernet@d0074000 {
+ ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
- mvsdio@d00d4000 {
+ mvsdio@d4000 {
pinctrl-0 = sdio_pins1;
pinctrl-names = default;
/*
@@ -75,15 +75,15 @@
/* No CD or WP GPIOs */
};
- usb@d005 {
+ usb@5 {
status = okay;
};
- usb@d0051000 {
+ usb@51000 {
status = okay;
};
- spi0: spi@d0010600 {
+ spi0: spi@10600 {
status = okay;
spi-flash@0 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index dd0c57d..2773eee 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,11 +25,11 @@
};
soc {
- serial@d0012000 {
+ serial@12000 {
clock-frequency = 2;
status = okay;
};
- timer@d0020300 {
+ timer@20300 {
clock-frequency = 6;
status = okay;
};
@@ -42,18 +42,18 @@
reg = 1;
};
};
- ethernet@d007 {
+ ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
- ethernet@d0074000 {
+ ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
- mvsdio@d00d4000 {
+ mvsdio@d4000 {
pinctrl-0 = sdio_pins2;
pinctrl-names = default;
status = okay;
@@ -63,11 +63,11 @@
*/
};
- usb@d005 {
+ usb@5 {
status = okay;
};
- usb@d0051000 {
+ usb@51000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 070bba4..be209020 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,11 +28,11 @@
};
soc {
- serial@d0012000 {
+ serial@12000 {
clock-frequency = 2;
status = okay;
};
- sata@d00a {
+
[PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 108 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 78
arch/arm/boot/dts/armada-370-rd.dts |2 +
arch/arm/boot/dts/armada-370-xp.dtsi | 228 +++---
arch/arm/boot/dts/armada-370.dtsi| 211 ++--
arch/arm/boot/dts/armada-xp-db.dts | 154 +++
arch/arm/boot/dts/armada-xp-gp.dts | 124 ++--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 56 +++---
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 80
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 80
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 196 ++-
arch/arm/boot/dts/armada-xp.dtsi | 182 +
12 files changed, 759 insertions(+), 740 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 183901c..6c30a9f 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,68 +30,70 @@
};
soc {
- serial@12000 {
- clock-frequency = 2;
- status = okay;
- };
- sata@a {
- nr-ports = 2;
- status = okay;
- };
-
- mdio {
- phy0: ethernet-phy@0 {
- reg = 0;
+ internal-regs {
+ serial@12000 {
+ clock-frequency = 2;
+ status = okay;
+ };
+ sata@a {
+ nr-ports = 2;
+ status = okay;
};
- phy1: ethernet-phy@1 {
- reg = 1;
+ mdio {
+ phy0: ethernet-phy@0 {
+ reg = 0;
+ };
+
+ phy1: ethernet-phy@1 {
+ reg = 1;
+ };
};
- };
- ethernet@7 {
- status = okay;
- phy = phy0;
- phy-mode = rgmii-id;
- };
- ethernet@74000 {
- status = okay;
- phy = phy1;
- phy-mode = rgmii-id;
- };
+ ethernet@7 {
+ status = okay;
+ phy = phy0;
+ phy-mode = rgmii-id;
+ };
+ ethernet@74000 {
+ status = okay;
+ phy = phy1;
+ phy-mode = rgmii-id;
+ };
- mvsdio@d4000 {
- pinctrl-0 = sdio_pins1;
- pinctrl-names = default;
- /*
-* This device is disabled by default, because
-* using the SD card connector requires
-* changing the default CON40 connector
-* DB-88F6710_MPP_2xRGMII_DEVICE_Jumper to a
-* different connector
-* DB-88F6710_MPP_RGMII_SD_Jumper.
-*/
- status = disabled;
- /* No CD or WP GPIOs */
- };
+ mvsdio@d4000 {
+ pinctrl-0 = sdio_pins1;
+ pinctrl-names = default;
+ /*
+* This device is disabled by default, because
+* using the SD card connector requires
+* changing the default CON40 connector
+* DB-88F6710_MPP_2xRGMII_DEVICE_Jumper to a
+* different connector
+* DB-88F6710_MPP_RGMII_SD_Jumper.
+*/
+ status = disabled;
+ /* No CD or WP GPIOs */
+ };
- usb@5 {
- status = okay;
- };
+ usb@5 {
+ status = okay;
+ };
- usb@51000 {
- status = okay;
- };
+ usb@51000 {
+ status = okay;
+
[PATCH v2 9/9] arm: dts: mvebu: Convert mvebu device tree files to 64 bits
In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.
Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
to 64 bits even the one used for Armada 370 (which don't support LPAE)
This was heavily based on the work of Lior Amsalem.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts |2 +-
arch/arm/boot/dts/armada-370-mirabox.dts |2 +-
arch/arm/boot/dts/armada-370-rd.dts |2 +-
arch/arm/boot/dts/armada-370-xp.dtsi |4 ++--
arch/arm/boot/dts/armada-xp-db.dts |2 +-
arch/arm/boot/dts/armada-xp-gp.dts | 14 --
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 +-
7 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 6c30a9f..c996c06 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -26,7 +26,7 @@
memory {
device_type = memory;
- reg = 0x 0x4000; /* 1 GB */
+ reg = 0 0x 0 0x4000; /* 1 GB */
};
soc {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 5a06e87..29b6b64 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -21,7 +21,7 @@
memory {
device_type = memory;
- reg = 0x 0x2000; /* 512 MB */
+ reg = 0 0x 0 0x2000; /* 512 MB */
};
soc {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 437dcd2..09e75fc 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -24,7 +24,7 @@
memory {
device_type = memory;
- reg = 0x 0x2000; /* 512 MB */
+ reg = 0 0x 0 0x2000; /* 512 MB */
};
soc {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 8b9adc6..6a3b418 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,7 +16,7 @@
* 370 and Armada XP SoC.
*/
-/include/ skeleton.dtsi
+/include/ skeleton64.dtsi
/ {
model = Marvell Armada 370 and XP SoC;
@@ -33,7 +33,7 @@
#size-cells = 1;
compatible = simple-bus;
interrupt-parent = mpic;
- ranges = 0 0xd000 0x10;
+ ranges = 0 0 0xd000 0x10;
internal-regs {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index fbd0f04..a2dd24e 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -26,7 +26,7 @@
memory {
device_type = memory;
- reg = 0x 0x8000; /* 2 GB */
+ reg = 0 0x 0 0x8000; /* 2 GB */
};
soc {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index b0298d7..b022906 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -26,14 +26,16 @@
memory {
device_type = memory;
-
/*
-* 4 GB of plug-in RAM modules by default but only 3GB
-* are visible, the amount of memory available can be
-* changed by the bootloader according the size of the
-* module actually plugged
+ * 8 GB of plug-in RAM modules by default.The amount
+ * of memory available can be changed by the
+ * bootloader according the size of the module
+ * actually plugged. Only 7GB are usable because
+ * addresses from 0xC000 to 0x are used by
+ * the internal registers of the SoC.
*/
- reg = 0x 0xC000;
+ reg = 0x 0x 0x 0xC000,
+ 0x0001 0x 0x0001 0x;
};
soc {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index e2eaf4f..1f274e7 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,7 @@
memory {
device_type = memory;
- reg = 0x 0xC000; /* 3 GB */
+ reg = 0 0x 0 0xC000; /* 3 GB */
};
soc {
--
1.7.9.5
[PATCH v2 8/9] arm: dts: mvebu: fix cpus section indentation
From: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 28
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 28
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 54 +++---
3 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f0d38fb..392f118 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,22 +25,22 @@
};
cpus {
- #address-cells = 1;
- #size-cells = 0;
+ #address-cells = 1;
+ #size-cells = 0;
- cpu@0 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 0;
- clocks = cpuclk 0;
- };
+ cpu@0 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 0;
+ clocks = cpuclk 0;
+ };
- cpu@1 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 1;
- clocks = cpuclk 1;
- };
+ cpu@1 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 1;
+ clocks = cpuclk 1;
+ };
};
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2621bda..8fb7fea 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
};
cpus {
- #address-cells = 1;
- #size-cells = 0;
+ #address-cells = 1;
+ #size-cells = 0;
- cpu@0 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 0;
- clocks = cpuclk 0;
- };
+ cpu@0 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 0;
+ clocks = cpuclk 0;
+ };
- cpu@1 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 1;
- clocks = cpuclk 1;
- };
+ cpu@1 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 1;
+ clocks = cpuclk 1;
+ };
};
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index ccb95ff..fa665cb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
cpus {
- #address-cells = 1;
- #size-cells = 0;
+ #address-cells = 1;
+ #size-cells = 0;
- cpu@0 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 0;
- clocks = cpuclk 0;
- };
+ cpu@0 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 0;
+ clocks = cpuclk 0;
+ };
- cpu@1 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 1;
- clocks = cpuclk 1;
- };
+ cpu@1 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 1;
+ clocks = cpuclk 1;
+ };
- cpu@2 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 2;
- clocks = cpuclk 2;
- };
+ cpu@2 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 2;
+ clocks = cpuclk 2;
+ };
- cpu@3 {
- device_type = cpu;
- compatible = marvell,sheeva-v7;
- reg = 3;
- clocks = cpuclk 3;
- };
+ cpu@3 {
+ device_type = cpu;
+ compatible = marvell,sheeva-v7;
+ reg = 3;
+ clocks = cpuclk 3;
+ };
};
soc {
@@ -114,4 +114,4 @@
};
};
};
- };
+};
--
1.7.9.5
Re: [PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected
On Friday 05 April 2013, Gregory CLEMENT wrote: When LPAE is activated on Armada XP, all registers and IOs are still 32bit, the 40bit extension is on the CPU to DRAM path (windows) only. That means that all the DMA transfer are restricted to the low 32 bits address space. This is limitation is achieved by selecting ZONE_DMA. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com Shouldn't that be ZONE_DMA32? Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node
On Friday 05 April 2013, Gregory CLEMENT wrote: Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com The patch looks good but the description is a bit short. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 8/9] arm: dts: mvebu: fix cpus section indentation
On Friday 05 April 2013, Gregory CLEMENT wrote: From: Thomas Petazzoni thomas.petazz...@free-electrons.com Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com This should have a description, even though it's completely trivial. I would also recommend moving this patch first, as the general rule is to do cleanups first. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs
On Friday 05 April 2013, Gregory CLEMENT wrote: The Armada XP SoCs have LPAE support. This is the second version patch set whixh allow to run kernel on this SoCs with LPAE support. The biggest changes are the conversion of the device tree file to 64 bits in order to be able to use more than 4GB of memory (without this the LPAE is pointless). The series looks good overall, I've commented on trivial details. Also, please use ARM: mvebu: ... in the subject rather than the lower-case version. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node
On 04/05/2013 10:43 PM, Arnd Bergmann wrote: On Friday 05 April 2013, Gregory CLEMENT wrote: Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com The patch looks good but the description is a bit short. It cannot be more brief! :) I explained the purpose of this patch in the cover letter and forgot to add this explanation here. I will expand it for next version. Thanks. Arnd -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base to support LPAE
On Friday 05 April 2013, Gregory CLEMENT wrote: From: Lior Amsalem al...@marvell.com In order to be able to support he LPAE, the internal registers virtual base must be aligned to 2MB. Signed-off-by: Lior Amsalem al...@marvell.com Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com This is a surprising limitation. Can you extend the above text to go into more detail where that alignment requirement comes from? Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected
On 04/05/2013 10:41 PM, Arnd Bergmann wrote: On Friday 05 April 2013, Gregory CLEMENT wrote: When LPAE is activated on Armada XP, all registers and IOs are still 32bit, the 40bit extension is on the CPU to DRAM path (windows) only. That means that all the DMA transfer are restricted to the low 32 bits address space. This is limitation is achieved by selecting ZONE_DMA. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com Shouldn't that be ZONE_DMA32? Well common code for ARM don't manage the ZONE_DMA32. Whereas with ZONE_DMA, setup_dma_zone() in arch/arm/mm/init.c does exactly what I want: setting arm_dma_limit to 0x. ZONE_DMA32 is used on arm64 however. Arnd -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs
On 04/05/2013 10:46 PM, Arnd Bergmann wrote: On Friday 05 April 2013, Gregory CLEMENT wrote: The Armada XP SoCs have LPAE support. This is the second version patch set whixh allow to run kernel on this SoCs with LPAE support. The biggest changes are the conversion of the device tree file to 64 bits in order to be able to use more than 4GB of memory (without this the LPAE is pointless). The series looks good overall, I've commented on trivial details. So there is still hope to have this patch set in 3.10 :) Also, please use ARM: mvebu: ... in the subject rather than the lower-case version. OK I will, but I saw a lot of 'arm' written in lower-case int the subject of emails on the LAKML. Arnd -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base to support LPAE
On 04/05/2013 10:50 PM, Arnd Bergmann wrote: On Friday 05 April 2013, Gregory CLEMENT wrote: From: Lior Amsalem al...@marvell.com In order to be able to support he LPAE, the internal registers virtual base must be aligned to 2MB. Signed-off-by: Lior Amsalem al...@marvell.com Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com This is a surprising limitation. Can you extend the above text to go into more detail where that alignment requirement comes from? The explanation I had was that in LPAE section size is 2MB, in earlyprintk we map the internal registers and it must be section aligned. Arnd ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
On Friday 05 of April 2013 21:54:21 Arnd Bergmann wrote: On Friday 05 April 2013, Tomasz Figa wrote: I don't think anyone ever suggested using a private API though. I must have gotten the last paragraph of http://article.gmane.org/gmane.linux.kernel.samsung-soc/16638 wrong then. For me it seemed like the timer driver would expose a private API to the PWM driver. Yes, sorry I wasn't clear enough. I meant a register-level interface exposed from the base driver, not a high-level interface like you did. I'm not sure what you mean by a register-level interface. Something like samsung_pwm_update_reg(reg, mask, val), which modifies bitfields according to the mask and value with appropriate synchronization? If yes, this solves only the problem of access to shared registers. The other problems that remain: - negotiation of PWM channels to use for clock source and clock events, because each board can use different channels for PWM outputs, - code duplication caused by both of the drivers doing mostly the same things and or having to parse the same data from device tree, - both non-DT and DT platforms must be supported, - how to keep the ability to load PWM driver as a module (or not load it at all when PWM is not used on particular board), while retaining everything that is needed for the clocksource driver in kernel, - some platforms can't use PWM timers as system clocksources, while on others this is the only timekeeping hardware available. I think it's ok if the driver lives in drivers/mfd when it doesn't fit anywhere else easily, but you should really register it to the pwm subsystem to expose that functionality, not export functions that can be used by a pwm shim driver, which even seems to be missing from the series. Anyway, using PWM API in a clocksource driver that needs to be running very early (before any initcalls get called) seems a bit weird for me, especially when PWM API doesn't provide such fine grained control over PWM timers that is required in the clocksource drivers. Exactly, that's why you should have a regular PWM driver that gets loaded at a convenient time and just uses an interface exported by the base driver to access the common registers. Well, this is basically what my patches do, except that the PWM driver isn't reworked to use the base driver yet. The private API exported to the samsung-time and pwm-samsung drivers isn't maybe the most fortunate one, but it clearly has the advantage of solving all the problems I mentioned before. Same goes for calling this an MFD driver. It doesn't even use the MFD core, but there seems to be no better place to put it. Maybe drivers/platform/arm would be better, if it existed, just as currently available drivers/platform/x86? Best regards, Tomasz ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/14] ARM: samsung-time: Prepare for multiplatform support
On Thursday 04 of April 2013 18:36:57 Tomasz Figa wrote: This series is an attempt to make the samsung-time clocksource driver ready for multiplatform kernels. It moves the driver to drivers/clocksource, cleans it up from uses of static platform-specific definitions, simplifies timer interrupt handling and adds Device Tree support. Only samsung-time driver is reworked to use the master driver at this time, since the PWM driver can be already considered broken at the moment and needs separate series of several patches to fix and clean it up, which I am already working on. Tested on Universal C210 board with Device Tree. Not tested without Device Tree, since it has been already broken before this series. Compile tested for other related SoCs. Changes since v3: (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16664/) - Changed the design to use common (master) driver for operations that can be done from both clocksource and PWM drivers (as suggested by Arnd Bergmann) - needed to properly synchronize access to PWM registers - Moved handling of PWM prescaler and divider to master driver Changes since v2: (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16158) - Addressed comments from Rob Herring and Mark Rutland - Removed unused register definitions - Replaced samsung,source-timer and samsung,event-timer properties with samsung,pwm-outputs property that defines which PWM channels are reserved for PWM outputs on particular platform - Split non-DT and DT initialization into two functions - Fixed a copy paste error Changes since v1: (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/16005) - Addressed comments from Mark Rutland - Documented struct samsung_timer_variant - Dropped inactive mail addresses from CC Tomasz Figa (14): ARM: SAMSUNG: Move samsung-time to drivers/clocksource clocksource: samsung-time: Drop useless defines from public header clocksource: samsung-time: Use local register definitions mfd: Add Samsung PWM/timer master driver ARM: SAMSUNG: Unify base address definitions of timer block ARM: SAMSUNG: Add new PWM platform device ARM: SAMSUNG: Set PWM platform data clocksource: samsung-time: Use Samsung PWM/timer master driver clocksource: samsung-time: Use variant data to get SoC-specific bits clocksource: samsung-time: Use master driver to configure dividers clocksource: samsung-time: Use clk_prepare_enable clocksource: samsung-time: Use master driver to control PWM channels clocksource: samsung-time: Move IRQ mask/ack handling to the driver ARM: SAMSUNG: Remove unused PWM timer IRQ chip code On FriendlyARM's Tiny6410 board (Mini6410-compatible), both with (using my patches adding S3C64xx Device Tree and pinctrl support) and without Device Tree: Tested-by: Tomasz Figa tomasz.f...@gmail.com Best regards, Tomasz ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT.
On Thu, Apr 4, 2013 at 6:08 PM, Fabio Estevam feste...@gmail.com wrote: This could be useful for removing the imx6q_sabrelite_cko1_setup() function from arch/arm/mach-imx/mach-imx6q.c. I would like to add audio support for another board and would like to avoid to do the same as imx6q_sabrelite_cko1_setup() for setting up the CLKO, if possible. You know, we have the same problem on one of our designs here (CLKO is used on MX53 for audio codec and camera device, shared) - the current solution is hack it into platform support in a BSP kernel. If we move to device tree, we know and you know the solution already; all this clock setup HAS to be done in the bootloader. The device tree really, really is only a way to describe the configuration as it exists or to describe alternatives - for instance, a clock with 10 parents may be described as having 10 parents, and the binding (in complicated cases) or driver (if it is simple as a value from 0 to 7 and the field width is 3 bits for example) will determine how that alternative can be selected (and by consequence, what the current setting is). The device tree concept is NOT a place to dump configuration items for your board as hardcoded values to try and force something you could have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you at least have to run through the Boot ROM and supply a DCD table or plugins first. This is where you figure things like this out. In a case where you have, say, an audio codec and it has a dynamic input clock that you want to change on the fly, first of all you would not hardcode a frequency into a device tree, second of all there is nothing stopping you from doing that right now anyway. If the clock is static and fixed frequency and can only be turned on and off, there are clock bindings for this already. If it is static and can never be turned off, then there are clock bindings for this too, and in this case the proviso is that the clock is ALREADY turned on and ALREADY stable before you enter the kernel otherwise the description is by it's very definition invalid. If the clock frequency in hardware is not what you wanted when the driver comes up, and you only have an on/off switch, it is not up to the device tree binding to describe how to go about configuring the system to make sure. You cannot in good conscience put a clock frequency to be set later in the device tree along with a clock phandle, simply because that means the device tree no longer describes the hardware accurately - the clock phandle is a valid clock, the hardware will tell you a frequency from registers in the clock driver, the device tree will disagree. How do you know which one is the correct value, or if the frequency in the tree is a suggestion rather than a description? I am totally against this (sorry Sascha..). Let's put some effort into fixing the bootloaders rather than trying to use the device tree to enforce the ridiculous assumption that Linux kernel does not trust the bootloader. Once the bindings and trees are out of the kernel source, you're going to HAVE to trust what the bootloader passes, be it pregenerated compiled blob (which needs to be written to match the hardware state the bootloader finishes up at) or dynamically generated at runtime during the boot process (which can describe to the bit what the hardware is doing). If you are testing this on Beagle XM you can fix your U-Boot easily. New boards will have to be designed *with the idea of device trees and working configurations in mind* - that is a fact of life, in fact this is how it should be in reality these days anyway (most HW designers will do initial bringup of the board - at least a minimal working configuration, in a restricted environment where they can use test pads to measure clocks, voltage outputs and levels of devices to ensure both production was successful and that the design is in itself electrically sound. This code 99% of the time ends up in the bootloader... sometimes not, when the board was designed by one group and the software written by the community, but in this case the community needs to learn board bringup and proper behavior...) -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH] CLK: Allow parent clock and rate to be configured in DT.
Okay now I have finished my criticism, I will make some productive suggestions :) How about we implement a system as follows; modify the clock framework and bindings such that we not only describe all the parents possible for a clock, we also enter into the device tree the current parent? I actually didn't fully realise it until now, but that just isn't in there (it's derived from the list in the parents property and the current hardware setting!). That way, at least on clock initialization it will be able to warn that the parent in the device tree is not the one in hardware, and - with suitable options or by default - warn that it is setting the parent to the one in the device tree. That solves the which parent I want problem without involving ACTUAL configuration, and meets Sascha's requirement that it is not done by a back door of configuration items. So to summarize, the process is * Device tree describes all parents of a clock in parents property * Device tree describes which parent is the current parent * Linux parses the tree and registers the clock - checks if the parent in HW is the same as the one in DT - if it is not the same, print a horrific warning to the kernel log - if we desire to (and it should be possible to make this a debug option for clock subsystem) set the parent to the one in the DT (also printing a horrific warning that it has done so) To solve the issue of setting clocks to fixed rates, I would suggest we do it by way of a similar system to the cpu frequency drivers or regulators, and use operating points or ranges. For a good chunk of devices, actual clock gating, rate changing and power management are possible and highly useful in myriad different ways depending on the device. In this way, an audio codec may end up with a list of operating-points in a node which describes all the valid clock rates. For example the SGTL5000 can accept many input clocks, the CS42L52 audio codec can also accept many input clock rates - and the audio frequency support is determined by those clock rates. For the latter example, this huge table; http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/cs42l52.c#n690 .. is a move-to-device-tree candidate. The driver could pick a suitable operating point from a range (which it could determine by the rates the clock phandle supports), and you can even suggest one the same way we do for regulators - only supply a single value. That way, everything looks like it is being done on the basis of power management, WOULD be used as power management on a vast chunk of devices, and can be restricted to only work for specific values on systems which didn't have the dynamism of others (for instance the MC13892 PMIC has many regulators with wide ranges of voltages, but on most systems they are tied to specific, fixed voltage rails so giving a range makes no sense, and there's no real driver that can take responsibility for setting them. But some use cases may tie the same regulator output to a dynamic voltage rail, so you can't get away with just being fixed or just being totally rangey) How does that sound (audio codec pun not entirely intentional..)? Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. On Fri, Apr 5, 2013 at 8:07 PM, Matt Sealey m...@genesi-usa.com wrote: On Thu, Apr 4, 2013 at 6:08 PM, Fabio Estevam feste...@gmail.com wrote: This could be useful for removing the imx6q_sabrelite_cko1_setup() function from arch/arm/mach-imx/mach-imx6q.c. I would like to add audio support for another board and would like to avoid to do the same as imx6q_sabrelite_cko1_setup() for setting up the CLKO, if possible. You know, we have the same problem on one of our designs here (CLKO is used on MX53 for audio codec and camera device, shared) - the current solution is hack it into platform support in a BSP kernel. If we move to device tree, we know and you know the solution already; all this clock setup HAS to be done in the bootloader. The device tree really, really is only a way to describe the configuration as it exists or to describe alternatives - for instance, a clock with 10 parents may be described as having 10 parents, and the binding (in complicated cases) or driver (if it is simple as a value from 0 to 7 and the field width is 3 bits for example) will determine how that alternative can be selected (and by consequence, what the current setting is). The device tree concept is NOT a place to dump configuration items for your board as hardcoded values to try and force something you could have done elsewhere. On i.MX53 you cannot boot a kernel verbatim - you at least have to run through the Boot ROM and supply a DCD table or plugins first. This is where you figure things like this out. In a case where you have, say, an audio codec and it has a dynamic input clock that you want to change on the fly, first of all you would not hardcode a frequency into a device tree,
