Re: [PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
Dear Mike Turquette, On Wed, 15 May 2013 14:41:54 -0700, Mike Turquette wrote: Quoting Thomas Petazzoni (2013-05-15 06:25:19) 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. Ack for patches #5 and #6. Do you want me to take them? I don't know, I guess with your Ack, it would be easier to carry them through the Marvell maintainers and then the arm-soc tree, so that we can test arm-soc and have all the pieces needed in here. That said, Sebastian Hesselbarth has submitted a big rework of the mvebu clock drivers, which would conflict with this patch, and Sebastian's rework would most likely go through your tree. If that's the case, I guess it would be better to let you take #5 and #6 in this patch series. That's something to be discussed with the Marvell maintainers (Jason Cooper, Andrew Lunn, Gregory Clement). Thanks! Thomas -- 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 v3 09/20] ARM: shmobile: r8a7790: Add GPIO controller devices to device tree
Hi Laurent
On Wed, 15 May 2013, Laurent Pinchart wrote:
Add GPIO controller nodes to the r8a7790 core device tree.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
arch/arm/boot/dts/r8a7790.dtsi | 54
++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ee21061..b5fe51da 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -44,6 +44,60 @@
};
};
+ gpio0: gpio@ffc4 {
+ compatible = renesas,gpio-r8a7790, renesas,gpio-rcar;
+ reg = 0xffc4 0x2c;
+ interrupt-parent = gic;
+ interrupts = 0 4 0x4;
+ #gpio-cells = 2;
+ gpio-controller;
+ };
I'm testing your patches on Lager and GPIOs don't seem to get registered:
/ # ls /sys/class/gpio/
exportunexport
/ #
And this is easy to trace back: sh_pfc_probe() calls
sh_pfc_register_gpiochip(), where a check
if (pfc-info-data_regs == NULL)
return 0;
successfully fails GPIO initialisation :) Is this known and there are
still some pieces missing, or you weren't aware of this?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
On 05/16/2013 09:44 AM, Thomas Petazzoni wrote: Dear Mike Turquette, On Wed, 15 May 2013 14:41:54 -0700, Mike Turquette wrote: Quoting Thomas Petazzoni (2013-05-15 06:25:19) 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. Ack for patches #5 and #6. Do you want me to take them? I don't know, I guess with your Ack, it would be easier to carry them through the Marvell maintainers and then the arm-soc tree, so that we can test arm-soc and have all the pieces needed in here. That said, Sebastian Hesselbarth has submitted a big rework of the mvebu clock drivers, which would conflict with this patch, and Sebastian's rework would most likely go through your tree. If that's the case, I guess it would be better to let you take #5 and #6 in this patch series. I also requested to take the restructure patches through ARM tree. They are only touching files in drivers/clk/mvebu and by taking them through ARM, we can update PCIe clock patches easily. The dependency between Thomas' and my patches basically is that I renamed files that Thomas now commits to. (I switched clk/mvebu from per-function files to per-soc files). That's something to be discussed with the Marvell maintainers (Jason Cooper, Andrew Lunn, Gregory Clement). Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver
Hi Linus, On 15/05/13 20:07, Linus Walleij wrote: On Tue, May 14, 2013 at 2:22 PM, James Hogan james.ho...@imgtec.com wrote: I think that's the other way around, i.e. that's talking about mapping several pingroups to the same function. The next paragraph is closer to the problem: Documentation/pinctrl.txt - PINS for a certain FUNCTION using a certain PIN GROUP on a certain PIN CONTROLLER are provided on a first-come first-serve basis, so if some other device mux setting or GPIO pin request has already taken your physical pin, you will be denied the use of it. To get (activate) a new setting, the old one has to be put (deactivated) first. In my example the tft pingroup contains all the tft pins, but I might want a particular pin inside that pingroup to never be controlled by the mux (using the per-pin mux disable (SELECT) bits). So if I use pinmux I'd have something like: * tft pingroup maps to tft function * tft_green0 pingroup (containing individual pin inside tft pingroup) maps to none function to disable muxing (or the inverse, with each pin in use mapping to periph to enable muxing). in which case the pin has multiple muxes controlling it (even though they're sort of nested). The above paragraph seems to condemn this arrangement. So if this usecase is what you want to support, why don't you just exclude that one pin from the tft group and put it into another group? It's a very board specific thing (that was just one example). To generalise your suggestion would make all muxing pingroups contain no pins (which is perhaps accurate since the thing that's muxed by the group is a set of internal signals that may be muxed out to pins via the SELECT bits). Cheers James ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
On Wed, May 15, 2013 at 03:25:21PM +0200, Thomas Petazzoni wrote:
[..]
+
+static int __init mvebu_pcie_probe(struct platform_device *pdev)
+{
+ struct mvebu_pcie *pcie;
+ struct device_node *np = pdev-dev.of_node;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ struct device_node *child;
+ int i, ret;
+
+ pcie = devm_kzalloc(pdev-dev, sizeof(struct mvebu_pcie),
+ GFP_KERNEL);
+ if (!pcie)
+ return -ENOMEM;
+
+ pcie-pdev = pdev;
+
+ if (of_pci_range_parser_init(parser, np))
+ return -EINVAL;
+
+ /* Get the I/O and memory ranges from DT */
+ for_each_of_pci_range(parser, range) {
+ unsigned long restype = range.flags IORESOURCE_TYPE_BITS;
+ if (restype == IORESOURCE_IO) {
+ of_pci_range_to_resource(range, np, pcie-io);
+ of_pci_range_to_resource(range, np, pcie-realio);
+ pcie-io.name = I/O;
+ pcie-realio.start = max_t(resource_size_t,
+PCIBIOS_MIN_IO,
+range.pci_addr);
+ pcie-realio.end = min_t(resource_size_t,
+ IO_SPACE_LIMIT,
+ range.pci_addr + range.size);
+ }
+ if (restype == IORESOURCE_MEM) {
+ of_pci_range_to_resource(range, np, pcie-mem);
+ pcie-mem.name = MEM;
+ }
+ }
+
+ /* Get the bus range */
+ ret = of_pci_parse_bus_range(np, pcie-busn);
+ if (ret) {
+ dev_err(pdev-dev, failed to parse bus-range property: %d\n,
+ ret);
+ return ret;
+ }
+
+ for_each_child_of_node(pdev-dev.of_node, child) {
+ if (!of_device_is_available(child))
+ continue;
+ pcie-nports++;
+ }
+
+ pcie-ports = devm_kzalloc(pdev-dev, pcie-nports *
+sizeof(struct mvebu_pcie_port),
+GFP_KERNEL);
+ if (!pcie-ports)
+ return -ENOMEM;
+
+ i = 0;
+ for_each_child_of_node(pdev-dev.of_node, child) {
+ struct mvebu_pcie_port *port = pcie-ports[i];
+
+ if (!of_device_is_available(child))
+ continue;
+
+ port-pcie = pcie;
+
+ if (of_property_read_u32(child, marvell,pcie-port,
+ port-port)) {
+ dev_warn(pdev-dev,
+ ignoring PCIe DT node, missing pcie-port
property\n);
+ continue;
+ }
+
+ if (of_property_read_u32(child, marvell,pcie-lane,
+ port-lane))
+ port-lane = 0;
+
+ port-name = kasprintf(GFP_KERNEL, pcie%d.%d,
+port-port, port-lane);
+
+ port-devfn = of_pci_get_devfn(child);
+ if (port-devfn 0)
+ continue;
+
+ port-base = mvebu_pcie_map_registers(pdev, child, port);
+ if (!port-base) {
+ dev_err(pdev-dev, PCIe%d.%d: cannot map registers\n,
+ port-port, port-lane);
+ continue;
+ }
+
+ if (mvebu_pcie_link_up(port)) {
+ port-haslink = 1;
+ dev_info(pdev-dev, PCIe%d.%d: link up\n,
+ port-port, port-lane);
+ } else {
+ port-haslink = 0;
+ dev_info(pdev-dev, PCIe%d.%d: link down\n,
+ port-port, port-lane);
+ }
+
+ port-clk = of_clk_get_by_name(child, NULL);
+ if (!port-clk) {
+ dev_err(pdev-dev, PCIe%d.%d: cannot get clock\n,
+port-port, port-lane);
+ iounmap(port-base);
+ port-haslink = 0;
+ continue;
+ }
+
+ port-dn = child;
+
+ clk_prepare_enable(port-clk);
+ spin_lock_init(port-conf_lock);
+
+ mvebu_sw_pci_bridge_init(port);
+
+ i++;
+ }
+
+ mvebu_pcie_enable(pcie);
+
+ return 0;
+}
+
+static const struct of_device_id mvebu_pcie_of_match_table[] = {
+ { .compatible = marvell,armada-xp-pcie, },
+ { .compatible = marvell,armada-370-pcie, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
+
+static struct platform_driver mvebu_pcie_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = mvebu-pcie,
+
Re: [PATCH RFC 0/2] clk: add metag specific gate/mux clocks
On 15/05/13 23:31, Stephen Boyd wrote: On 05/10/13 08:02, James Hogan wrote: This adds a metag architecture specific clk-gate and clk-mux which extends the generic ones to use global lock2 to protect the register fields. It is common with metag to have an RTOS running on a different thread or core with access to different bits in the same register (which contain clock gate/switch bits for other clocks). Access to such registers must be serialised with a global lock such as the one provided by the metag architecture port in asm/global_lock.h RFC because despite extending the generic clocks there's still a bit of duplicated code necessary. One alternative is to add special cases to the generic clock components for when a global or callback function based lock is desired instead of a spinlock, but I wasn't sure if that sort of hack would really be appreciated in the generic drivers. Comments? Can you please Cc the devicetree mailing list when proposing new bindings? Erm, I think it was on Cc (devicetree-discuss@lists.ozlabs.org yeh?) Your patchset brings up a question I've had which is if we should be putting the bits and register width information in devicetree at all. On the one hand it's nice to not have anything in C code, just iterate over nodes and register clocks. On the other hand, it's the first time I've seen anyone put the register interface into devicetree. From what I can tell, the regulator bindings have put at most the register base and physical properties like enable-time, max voltage, etc., but not what bits are needed to enable/disable a regulator. Also I thought I read somewhere that reg properties shouldn't overlap each other, so if you ever have two clocks living in the same register we're going to violate that. Oh, I wasn't aware of that limitation. The SoC I'm working with has some registers full of clock enable bits (I guess one could have a gate array component with up to 32 clock inputs and outputs) and some registers full of clock mux switch bits (that would get really messy to define as a block since each bit switches between 2 parents, and some of the parents are other clock muxes in the same block). Some registers contain a bunch of low power related bits together, including clock enable bits in the same register as various pinconf settings which is used by a separate pinctrl driver. Cheers James ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC] media: OF: add field-active and sync-on-green endpoint properties
Hi, On 05/16/2013 06:53 AM, Prabhakar Lad wrote: diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..6bf87d0 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,10 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +-field-active: a boolean property indicating active high filed ID output + polarity is inverted. Looks like we already have field-even-active property to describe the level of the field signal. Could you please check whether it fulfills your use cases ? Sorry for not pointing you to it earlier. I had looked at it earlier it only means field signal level during the even field data transmission it only speaks of even filed. Ideally the field ID output is set to logic 1 for odd field and set to 0 for even field, what I want is to invert the FID out polarity when field-active property is set. May be we rename field-active to fid-pol ? I guess we failed to clearly describe the 'field-even-active' property then. It seems to be exactly what you need. It is not enough to say e.g. field-active = 1;, because it would not have been clear which field it refers to, odd or even ? Unlike VSYNC, HSYNC both levels of the FIELD signal are active, there is no idle state for FIELD. So field-even-active = 1; means the FIELD signal at logic high level indicates EVEN field _and_ this implies FIELD = 0 indicates ODD field, i.e. FIELD = 0 = odd field FIELD = 1 = even field For field-even-active = 0; it is the other way around: FIELD = 0 = even field FIELD = 1 = odd field It looks like only sync-on-green property is missing. BTW, is it really commonly used ? What drivers would need it ? I'm not against making it a common property, it's just first time I see it. Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC] media: OF: add field-active and sync-on-green endpoint properties
On 05/15/2013 02:52 PM, Lad Prabhakar wrote: diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..6bf87d0 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,10 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +-field-active: a boolean property indicating active high filed ID output + polarity is inverted. You can drop this property and use the existing 'field-even-active' property instead. +-sync-on-green: a boolean property indicating to sync with the green signal in + RGB. diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..b95553d 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,8 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_FIELD_ACTIVE (1 12) +#define V4L2_MBUS_SOG (1 13) How about V4L2_MBUS_SYNC_ON_GREEN ? Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC] media: OF: add field-active and sync-on-green endpoint properties
Hi Sylwester, On Thu, May 16, 2013 at 4:13 PM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: Hi, On 05/16/2013 06:53 AM, Prabhakar Lad wrote: [Snip] May be we rename field-active to fid-pol ? I guess we failed to clearly describe the 'field-even-active' property then. It seems to be exactly what you need. It is not enough to say e.g. field-active = 1;, because it would not have been clear which field it refers to, odd or even ? Unlike VSYNC, HSYNC both levels of the FIELD signal are active, there is no idle state for FIELD. So field-even-active = 1; means the FIELD signal at logic high level indicates EVEN field _and_ this implies FIELD = 0 indicates ODD field, i.e. FIELD = 0 = odd field FIELD = 1 = even field For field-even-active = 0; it is the other way around: FIELD = 0 = even field FIELD = 1 = odd field Thanks that makes it clear :) It looks like only sync-on-green property is missing. BTW, is it really commonly used ? What drivers would need it ? I'm not against making it a common property, it's just first time I see it. I have comes across a decoder tvp7002 which uses it, may be Laurent/Hans/Sakari may point much more devices. Regards, --Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC] media: OF: add field-active and sync-on-green endpoint properties
Hi Sylwester, Thanks for the review. On Thu, May 16, 2013 at 4:15 PM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 05/15/2013 02:52 PM, Lad Prabhakar wrote: diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..6bf87d0 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,10 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +-field-active: a boolean property indicating active high filed ID output + polarity is inverted. You can drop this property and use the existing 'field-even-active' property instead. OK +-sync-on-green: a boolean property indicating to sync with the green signal in + RGB. diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..b95553d 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,8 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_FIELD_ACTIVE (1 12) +#define V4L2_MBUS_SOG (1 13) How about V4L2_MBUS_SYNC_ON_GREEN ? OK makes it more readable. Regards, --Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 09/20] ARM: shmobile: r8a7790: Add GPIO controller devices to device tree
Hi Guennadi,
On Thursday 16 May 2013 09:57:20 Guennadi Liakhovetski wrote:
On Wed, 15 May 2013, Laurent Pinchart wrote:
Add GPIO controller nodes to the r8a7790 core device tree.
Signed-off-by: Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com
---
arch/arm/boot/dts/r8a7790.dtsi | 54 +
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi
b/arch/arm/boot/dts/r8a7790.dtsi index ee21061..b5fe51da 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -44,6 +44,60 @@
};
};
+ gpio0: gpio@ffc4 {
+ compatible = renesas,gpio-r8a7790, renesas,gpio-rcar;
+ reg = 0xffc4 0x2c;
+ interrupt-parent = gic;
+ interrupts = 0 4 0x4;
+ #gpio-cells = 2;
+ gpio-controller;
+ };
I'm testing your patches on Lager and GPIOs don't seem to get registered:
/ # ls /sys/class/gpio/
exportunexport
/ #
And this is easy to trace back: sh_pfc_probe() calls
sh_pfc_register_gpiochip(), where a check
if (pfc-info-data_regs == NULL)
return 0;
successfully fails GPIO initialisation :) Is this known and there are
still some pieces missing, or you weren't aware of this?
GPIOs are handled by the gpio-rcar driver on R8A7790, not by the sh-pfc
driver.
--
Regards,
Laurent Pinchart
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 01/20] sh-pfc: Add DT support
Hi Guennadi, On Wednesday 15 May 2013 16:03:10 Guennadi Liakhovetski wrote: Hi Laurent Thanks for your work on this! Sorry for jumping in so late in the game. No worries. Let's do it this way: I don't think my comments are serious enough to enforce a v4. If noone else complains, I'm fine with addressing them in an incremental patch. If you get more comments and have to do a v4, you can address mine too, otherwise I'm fine with this version going in and improving it slightly afterwards. I don't mind submitting a v4. On Wed, 15 May 2013, Laurent Pinchart wrote: Support device instantiation through the device tree. The compatible property is used to select the SoC pinmux information. Set the gpio_chip device field to the PFC device to enable automatic GPIO OF support. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- .../bindings/pinctrl/renesas,pfc-pinctrl.txt | 143 drivers/pinctrl/sh-pfc/core.c | 66 +- drivers/pinctrl/sh-pfc/pinctrl.c | 244 3 files changed, 451 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt new file mode 100644 index 000..e7aae39 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -0,0 +1,143 @@ +* Renesas Pin Function Controller (GPIO and Pin Mux/Config) + +The Pin Function Controller (PFC) is a Pin Mux/Config controller. On SH7372, +SH73A0, R8A73A4 and R8A7740 it also acts as a GPIO controller. + + +Pin Control +--- + +Required Properties: + + - compatible: should be one of the following. +- renesas,pfc-r8a73a4: for R8A73A4 (R-Mobile APE6) compatible pin-controller. +- renesas,pfc-r8a7740: for R8A7740 (R-Mobile A1) compatible pin- controller. +- renesas,pfc-r8a7778: for R8A7778 (R-Mobile M1) compatible pin- controller. +- renesas,pfc-r8a7779: for R8A7779 (R-Car H1) compatible pin- controller. +- renesas,pfc-r8a7790: for R8A7790 (R-Car H2) compatible pin- controller. +- renesas,pfc-sh7372: for SH7372 (SH-Mobile AP4) compatible pin-controller. +- renesas,pfc-sh73a0: for SH73A0 (SH-Mobile AG5) compatible pin- controller. + + - reg: Base address and length of each memory resource used by the pin +controller hardware module. + +The PFC node also acts as a container for pin configuration nodes. Please +refer to pinctrl-bindings.txt in this directory for the definition of the +term pin configuration node and for the common pinctrl bindings used by +client devices. + +Each pin configuration node represents a desired configuration for a pin, +a pin group, or a list of pins or pin groups. The configuration can +include the function to select on those pin(s) and pin configuration +parameters (such as +pull-up and pull-down). + +Pin configuration nodes contain pin configuration properties, either +directly or grouped in child subnodes. Both pin muxing and configuration +parameters can be grouped in that way and referenced as a single pin +configuration node by client devices. + +A configuration node or subnode must reference at least one pin (through +the pins or pin groups properties) and contain at least a function or one +configuration parameter. When the function is present only pin groups can +be used to reference pins. + +All pin configuration nodes and subnodes names are ignored. All of those +nodes are parsed through phandles and processed purely based on their +content. + +Pin Configuration Node Properties: + +- renesas,pins : An array of strings, each string containing the name of + a pin. +- renesas,groups : An array of strings, each string containing the name + of a pin group. + +- renesas,function: A string containing the name of the function to mux + to the pin group(s) specified by the renesas,groups property + + Valid values for pin, group and function names can be found in the + group and function arrays of the PFC data file corresponding to the SoC + (drivers/pinctrl/sh-pfc/pfc-*.c) + +- renesas,pull-up: An integer representing the pull-up strength to be + applied to all pins specified by the renesas,pins and renesas-groups + properties. 0 disables the pull-up, 1 enables it. Other values should + not be used. +- renesas,pull-down: An integer representing the pull-down strength to be + applied to all pins specified by the renesas,pins and renesas-groups + properties. 0 disables the pull-down, 1 enables it. Other values should + not be used. + + +GPIO + + +Required Properties: + + -
Re: [PATCH v3] media: i2c: tvp514x: add OF support
Hi Prabhakar,
Thank you for the patch.
On Tuesday 14 May 2013 16:30:36 Lad Prabhakar wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the tvp514x driver. Alongside this patch
removes unnecessary header file inclusion and sorts them alphabetically.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
---
Tested on da850-evm.
RFC v1: https://patchwork.kernel.org/patch/2030061/
RFC v2: https://patchwork.kernel.org/patch/2061811/
Changes for current version from RFC v2:
1: Fixed review comments pointed by Sylwester.
Changes for v2:
1: Listed all the compatible property values in the documentation text
file. 2: Removed -decoder from compatible property values.
3: Added a reference to the V4L2 DT bindings documentation to explain
what the port and endpoint nodes are for.
4: Fixed some Nits pointed by Laurent.
5: Removed unnecessary header file includes and sort them alphabetically.
Changes for v3:
1: Rebased on patch https://patchwork.kernel.org/patch/2539411/
.../devicetree/bindings/media/i2c/tvp514x.txt | 45
drivers/media/i2c/tvp514x.c| 74 +
2 files changed, 103 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp514x.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt new file mode
100644
index 000..cc09424
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
@@ -0,0 +1,45 @@
+* Texas Instruments TVP514x video decoder
+
+The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
+digital video decoder that digitizes and decodes all popular baseband
+analog video formats into digital video component. The tvp514x decoder
+supports analog-to-digital (A/D) conversion of component RGB and YPbPr
+signals as well as A/D conversion and decoding of NTSC, PAL and SECAM
+composite and S-video into component YCbCr.
+
+Required Properties :
+- compatible : value should be either one among the following
+ (a) ti,tvp5146 for tvp5146 decoder.
+ (b) ti,tvp5146m2 for tvp5146m2 decoder.
+ (c) ti,tvp5147 for tvp5147 decoder.
+ (d) ti,tvp5147m1 for tvp5147m1 decoder.
+
+- hsync-active: HSYNC Polarity configuration for endpoint.
+
+- vsync-active: VSYNC Polarity configuration for endpoint.
+
+- pclk-sample: Clock polarity of the endpoint.
+
+
+For further reading of port node refer Documentation/devicetree/bindings/
+media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ tvp514x@5c {
+ compatible = ti,tvp5146;
+ reg = 0x5c;
+
+ port {
+ tvp514x_1: endpoint {
+ hsync-active = 1;
+ vsync-active = 1;
+ pclk-sample = 0;
+ };
+ };
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 01d9757..202c8cb 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -29,21 +29,16 @@
*
*/
-#include linux/i2c.h
-#include linux/slab.h
#include linux/delay.h
-#include linux/videodev2.h
+#include linux/i2c.h
#include linux/module.h
-#include linux/v4l2-mediabus.h
+#include media/media-entity.h
+#include media/tvp514x.h
#include media/v4l2-async.h
-#include media/v4l2-device.h
-#include media/v4l2-common.h
-#include media/v4l2-mediabus.h
-#include media/v4l2-chip-ident.h
#include media/v4l2-ctrls.h
-#include media/tvp514x.h
-#include media/media-entity.h
+#include media/v4l2-device.h
+#include media/v4l2-of.h
#include tvp514x_regs.h
@@ -1056,6 +1051,40 @@ static struct tvp514x_decoder tvp514x_dev = {
};
+static struct tvp514x_platform_data *
+tvp514x_get_pdata(struct i2c_client *client)
+{
+ struct tvp514x_platform_data *pdata;
+ struct v4l2_of_endpoint bus_cfg;
+ struct device_node *endpoint;
+ unsigned int flags;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+ return client-dev.platform_data;
+
+ endpoint =
Re: [PATCH RFC V4 FINAL] media: i2c: mt9p031: add OF support
Hi Prabhakar,
Thank you for the patch.
On Monday 13 May 2013 10:47:04 Lad Prabhakar wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the mt9p031 sensor driver.
Alongside this patch sorts the header inclusion alphabetically.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Arnd Bergmann a...@arndb.de
Cc: devicetree-discuss@lists.ozlabs.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
Changes for v4:
1: Renamed gpio-reset property to reset-gpios.
2: Dropped assigning the driver data from the of node.
Changes for v3:
1: Dropped check if gpio-reset is valid.
2: Fixed some code nits.
3: Included a reference to the V4L2 DT bindings documentation.
Changes for v2:
1: Used '-' instead of '_' for device properties.
2: Specified gpio reset pin as phandle in device node.
3: Handle platform data properly even if kernel is compiled with
devicetree support.
4: Used dev_* for messages in drivers instead of pr_*.
5: Changed compatible property to aptina,mt9p031 and aptina,mt9p031m.
6: Sorted the header inclusion alphabetically and fixed some minor code
nits.
.../devicetree/bindings/media/i2c/mt9p031.txt | 40 +
drivers/media/i2c/mt9p031.c| 42 -
2 files changed, 80 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9p031.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt new file mode
100644
index 000..59d613c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
@@ -0,0 +1,40 @@
+* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
+
+The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor
with +an active array size of 2592H x 1944V. It is programmable through a
simple +two-wire serial interface.
+
+Required Properties :
+- compatible : value should be either one among the following
+ (a) aptina,mt9p031 for mt9p031 sensor
+ (b) aptina,mt9p031m for mt9p031m sensor
+
+- input-clock-frequency : Input clock frequency.
+
+- pixel-clock-frequency : Pixel clock frequency.
+
+Optional Properties :
+- reset-gpios: Chip reset GPIO
+
+For further reading of port node refer
Documentation/devicetree/bindings/media/ +video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ mt9p031@5d {
+ compatible = aptina,mt9p031;
+ reg = 0x5d;
+ reset-gpios = gpio3 30 0;
+
+ port {
+ mt9p031_1: endpoint {
+ input-clock-frequency = 600;
+ pixel-clock-frequency = 9600;
+ };
+ };
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 28cf95b..a58207c 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -16,9 +16,11 @@
#include linux/delay.h
#include linux/device.h
#include linux/gpio.h
-#include linux/module.h
#include linux/i2c.h
#include linux/log2.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/of_gpio.h
#include linux/pm.h
#include linux/regulator/consumer.h
#include linux/slab.h
@@ -28,6 +30,7 @@
#include media/v4l2-chip-ident.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
+#include media/v4l2-of.h
#include media/v4l2-subdev.h
#include aptina-pll.h
@@ -928,10 +931,35 @@ static const struct v4l2_subdev_internal_ops
mt9p031_subdev_internal_ops = { * Driver initialization and probing
*/
+static struct mt9p031_platform_data *
+mt9p031_get_pdata(struct i2c_client *client)
+{
+ struct device_node *np;
+ struct mt9p031_platform_data *pdata;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+ return client-dev.platform_data;
+
+ np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL);
+ if (!np)
+ return NULL;
+
+ pdata = devm_kzalloc(client-dev, sizeof(struct mt9p031_platform_data),
+ GFP_KERNEL);
+ if (!pdata)
As mentioned in my review of your tvp514x OF support patch, you're missing
of_node_put() calls here and at the end of
Re: [PATCH v3] media: i2c: tvp514x: add OF support
Hi Laurent, Thanks for the review. On Thu, May 16, 2013 at 5:40 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, [Snip] + + pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) I've started playing with the V4L2 OF bindings, and realized that should should call of_node_put() here. you were referring of_node_get() here rite ? of_node_get/put() got recently added I guess coz of which I missed it :) + return NULL; + + v4l2_of_parse_endpoint(endpoint, bus_cfg); + flags = bus_cfg.bus.parallel.flags; + + if (flags V4L2_MBUS_HSYNC_ACTIVE_HIGH) + pdata-hs_polarity = 1; + + if (flags V4L2_MBUS_VSYNC_ACTIVE_HIGH) + pdata-vs_polarity = 1; + + if (flags V4L2_MBUS_PCLK_SAMPLE_RISING) + pdata-clk_polarity = 1; + As well as here. Maybe a done: of_node_put(endpoint); return pdata; with a goto done in the devm_kzalloc error path would be better. OK Regards, --Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] media: i2c: tvp514x: add OF support
Hi Prabhakar, On Thursday 16 May 2013 18:13:38 Prabhakar Lad wrote: On Thu, May 16, 2013 at 5:40 PM, Laurent Pinchart wrote: Hi Prabhakar, [Snip] + + pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) I've started playing with the V4L2 OF bindings, and realized that should should call of_node_put() here. you were referring of_node_get() here rite ? No, I'm referring to of_node_put(). The v4l2_of_get_next_endpoint() function mentions * Return: An 'endpoint' node pointer with refcount incremented. Refcount * of the passed @prev node is not decremented, the caller have to use * of_node_put() on it when done. of_node_get/put() got recently added I guess coz of which I missed it :) + return NULL; + + v4l2_of_parse_endpoint(endpoint, bus_cfg); + flags = bus_cfg.bus.parallel.flags; + + if (flags V4L2_MBUS_HSYNC_ACTIVE_HIGH) + pdata-hs_polarity = 1; + + if (flags V4L2_MBUS_VSYNC_ACTIVE_HIGH) + pdata-vs_polarity = 1; + + if (flags V4L2_MBUS_PCLK_SAMPLE_RISING) + pdata-clk_polarity = 1; + As well as here. Maybe a done: of_node_put(endpoint); return pdata; with a goto done in the devm_kzalloc error path would be better. -- Regards, Laurent Pinchart ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] media: i2c: tvp514x: add OF support
Hi Laurent, On Thu, May 16, 2013 at 6:20 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, On Thursday 16 May 2013 18:13:38 Prabhakar Lad wrote: On Thu, May 16, 2013 at 5:40 PM, Laurent Pinchart wrote: Hi Prabhakar, [Snip] + + pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) I've started playing with the V4L2 OF bindings, and realized that should should call of_node_put() here. you were referring of_node_get() here rite ? No, I'm referring to of_node_put(). The v4l2_of_get_next_endpoint() function mentions * Return: An 'endpoint' node pointer with refcount incremented. Refcount * of the passed @prev node is not decremented, the caller have to use * of_node_put() on it when done. Ahh I see thanks for clarifying, I'll fix it for v3. Regards, --Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC v2] media: OF: add sync-on-green endpoint property
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds sync-on-green property as part of endpoint properties and also support to parse them in the parser. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: davinci-linux-open-sou...@linux.davincidsp.com Cc: Kyungmin Park kyungmin.p...@samsung.com --- Changes for v2: 1: Dropped field-active property as it same as existing field-even-active property. .../devicetree/bindings/media/video-interfaces.txt |2 ++ drivers/media/v4l2-core/v4l2-of.c |3 +++ include/media/v4l2-mediabus.h |1 + 3 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..f91821f 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,8 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +-sync-on-green: a boolean property indicating to sync with the green signal in + RGB. Example diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..b51d61f 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,9 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, if (!of_property_read_u32(node, data-shift, v)) bus-data_shift = v; + if (of_get_property(node, sync-on-green, v)) + flags |= V4L2_MBUS_SYNC_ON_GREEN; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..cf2c66f9 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,7 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_SYNC_ON_GREEN(1 12) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 5/9] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
Mike, Sebastian, On Thu, May 16, 2013 at 10:26:24AM +0200, Sebastian Hesselbarth wrote: On 05/16/2013 09:44 AM, Thomas Petazzoni wrote: Dear Mike Turquette, On Wed, 15 May 2013 14:41:54 -0700, Mike Turquette wrote: Quoting Thomas Petazzoni (2013-05-15 06:25:19) 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. Ack for patches #5 and #6. Do you want me to take them? Thanks for the Ack! I don't know, I guess with your Ack, it would be easier to carry them through the Marvell maintainers and then the arm-soc tree, so that we can test arm-soc and have all the pieces needed in here. That said, Sebastian Hesselbarth has submitted a big rework of the mvebu clock drivers, which would conflict with this patch, and Sebastian's rework would most likely go through your tree. If that's the case, I guess it would be better to let you take #5 and #6 in this patch series. I also requested to take the restructure patches through ARM tree. They are only touching files in drivers/clk/mvebu and by taking them through ARM, we can update PCIe clock patches easily. The dependency between Thomas' and my patches basically is that I renamed files that Thomas now commits to. (I switched clk/mvebu from per-function files to per-soc files). I agree. My heart jumped into my throat a little there :) Mike, if it's ok with you, I'd prefer to take these through arm-soc. Any merge conflicts should be minimal. And at any rate, resolving the conflicts are *much* easier to handle than having arm-soc depend on an outside tree (then Linus has to take care in the order he merges them, no rebasing for clk tree, dogs and cats living together, etc ;-) ) thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] ARM: kernel: fix __cpu_logical_map default initialization
For legacy reasons, the __cpu_logical_map array is initialized to 0.
On old pre-DT ARM platforms, smp_setup_processor_id() generates
__cpu_logical_map entries at boot before the number of possible CPUs is
set-up, with values that can be considered valid MPIDRs even if they are
not present in the system booting; this implies that the __cpu_logical_map[]
might end up containing MPIDR values that can be considered valid at logical
indexes corresponding to CPUs that are not marked as possible.
To prevent issues with the current implementation, this patch defines an
MPIDR_INVALID value, statically initializes the __cpu_logical_map[] array to it
and allows DT parsing code to overwrite values in the __cpu_logical_map array
that were erroneously set-up in smp_setup_processor_id().
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/cputype.h | 2 ++
arch/arm/include/asm/smp_plat.h | 2 +-
arch/arm/kernel/devtree.c | 10 ++
arch/arm/kernel/setup.c | 2 +-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7652712..dba62cb 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -32,6 +32,8 @@
#define MPIDR_HWID_BITMASK 0xFF
+#define MPIDR_INVALID (~MPIDR_HWID_BITMASK)
+
#define MPIDR_LEVEL_BITS 8
#define MPIDR_LEVEL_MASK ((1 MPIDR_LEVEL_BITS) - 1)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index aaa61b6..e789832 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -49,7 +49,7 @@ static inline int cache_ops_need_broadcast(void)
/*
* Logical CPU mapping.
*/
-extern int __cpu_logical_map[];
+extern u32 __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
/*
* Retrieve logical cpu index corresponding to a given MPIDR[23:0]
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index d2293c0..08f012e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -79,12 +79,12 @@ void __init arm_dt_init_cpu_maps(void)
* read as 0.
*/
static u32 tmp_map[NR_CPUS] __initdata = {
- [0 ... NR_CPUS-1] = UINT_MAX };
+ [0 ... NR_CPUS-1] = MPIDR_INVALID };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
-
bool bootcpu_valid = false;
+
cpus = of_find_node_by_path(/cpus);
if (!cpus)
@@ -160,11 +160,13 @@ void __init arm_dt_init_cpu_maps(void)
/*
* Since the boot CPU node contains proper data, and all nodes have
* a reg property, the DT CPU list can be considered valid and the
-* logical map created in smp_setup_processor_id() can be overridden
+* logical map created in smp_setup_processor_id() can be overridden,
+* inclusive of entries that must contain invalid MPIDRs
*/
+ memcpy(__cpu_logical_map, tmp_map,
+ nr_cpu_ids * sizeof(tmp_map[0]));
for (i = 0; i cpuidx; i++) {
set_cpu_possible(i, true);
- cpu_logical_map(i) = tmp_map[i];
pr_debug(cpu logical map 0x%x\n, cpu_logical_map(i));
}
}
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 6ae71b7..eeac924 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -457,7 +457,7 @@ void notrace cpu_init(void)
: r14);
}
-int __cpu_logical_map[NR_CPUS];
+u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
void __init smp_setup_processor_id(void)
{
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] ARM: DT: kernel: move temporary cpu map stack array to static data
As the number of CPUs increase, the temporary array allocated on the
stack in arm_dt_init_cpu_maps() can become too big and trigger stack
issues.
This patch moves the allocated memory to static __initdata so that stack
data is not used anymore to allocate the temporary array.
Memory is marked as __initdata since it need not be persistent after boot.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/devtree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5af04f6..3d652e4f 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -78,11 +78,12 @@ void __init arm_dt_init_cpu_maps(void)
* contain a list of MPIDR[23:0] values where MPIDR[31:24] must
* read as 0.
*/
+ static u32 tmp_map[NR_CPUS] __initdata = {
+ [0 ... NR_CPUS-1] = UINT_MAX };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
- u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = UINT_MAX };
bool bootcpu_valid = false;
cpus = of_find_node_by_path(/cpus);
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
On Thu, May 16, 2013 at 06:33:14AM -0300, Ezequiel Garcia wrote:
On Wed, May 15, 2013 at 03:25:21PM +0200, Thomas Petazzoni wrote:
[..]
+
+static int __init mvebu_pcie_probe(struct platform_device *pdev)
+{
+ struct mvebu_pcie *pcie;
+ struct device_node *np = pdev-dev.of_node;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ struct device_node *child;
+ int i, ret;
+
+ pcie = devm_kzalloc(pdev-dev, sizeof(struct mvebu_pcie),
+ GFP_KERNEL);
+ if (!pcie)
+ return -ENOMEM;
+
+ pcie-pdev = pdev;
+
+ if (of_pci_range_parser_init(parser, np))
+ return -EINVAL;
+
+ /* Get the I/O and memory ranges from DT */
+ for_each_of_pci_range(parser, range) {
+ unsigned long restype = range.flags IORESOURCE_TYPE_BITS;
+ if (restype == IORESOURCE_IO) {
+ of_pci_range_to_resource(range, np, pcie-io);
+ of_pci_range_to_resource(range, np, pcie-realio);
+ pcie-io.name = I/O;
+ pcie-realio.start = max_t(resource_size_t,
+ PCIBIOS_MIN_IO,
+ range.pci_addr);
+ pcie-realio.end = min_t(resource_size_t,
+IO_SPACE_LIMIT,
+range.pci_addr + range.size);
+ }
+ if (restype == IORESOURCE_MEM) {
+ of_pci_range_to_resource(range, np, pcie-mem);
+ pcie-mem.name = MEM;
+ }
+ }
+
+ /* Get the bus range */
+ ret = of_pci_parse_bus_range(np, pcie-busn);
+ if (ret) {
+ dev_err(pdev-dev, failed to parse bus-range property: %d\n,
+ ret);
+ return ret;
+ }
+
+ for_each_child_of_node(pdev-dev.of_node, child) {
+ if (!of_device_is_available(child))
+ continue;
+ pcie-nports++;
+ }
+
+ pcie-ports = devm_kzalloc(pdev-dev, pcie-nports *
+ sizeof(struct mvebu_pcie_port),
+ GFP_KERNEL);
+ if (!pcie-ports)
+ return -ENOMEM;
+
+ i = 0;
+ for_each_child_of_node(pdev-dev.of_node, child) {
+ struct mvebu_pcie_port *port = pcie-ports[i];
+
+ if (!of_device_is_available(child))
+ continue;
+
+ port-pcie = pcie;
+
+ if (of_property_read_u32(child, marvell,pcie-port,
+port-port)) {
+ dev_warn(pdev-dev,
+ignoring PCIe DT node, missing pcie-port
property\n);
+ continue;
+ }
+
+ if (of_property_read_u32(child, marvell,pcie-lane,
+port-lane))
+ port-lane = 0;
+
+ port-name = kasprintf(GFP_KERNEL, pcie%d.%d,
+ port-port, port-lane);
+
+ port-devfn = of_pci_get_devfn(child);
+ if (port-devfn 0)
+ continue;
+
+ port-base = mvebu_pcie_map_registers(pdev, child, port);
+ if (!port-base) {
+ dev_err(pdev-dev, PCIe%d.%d: cannot map registers\n,
+ port-port, port-lane);
+ continue;
+ }
+
+ if (mvebu_pcie_link_up(port)) {
+ port-haslink = 1;
+ dev_info(pdev-dev, PCIe%d.%d: link up\n,
+port-port, port-lane);
+ } else {
+ port-haslink = 0;
+ dev_info(pdev-dev, PCIe%d.%d: link down\n,
+port-port, port-lane);
+ }
+
+ port-clk = of_clk_get_by_name(child, NULL);
+ if (!port-clk) {
+ dev_err(pdev-dev, PCIe%d.%d: cannot get clock\n,
+ port-port, port-lane);
+ iounmap(port-base);
+ port-haslink = 0;
+ continue;
+ }
+
+ port-dn = child;
+
+ clk_prepare_enable(port-clk);
+ spin_lock_init(port-conf_lock);
+
+ mvebu_sw_pci_bridge_init(port);
+
+ i++;
+ }
+
+ mvebu_pcie_enable(pcie);
+
+ return 0;
+}
+
+static const struct of_device_id mvebu_pcie_of_match_table[] = {
+ { .compatible = marvell,armada-xp-pcie, },
+ { .compatible = marvell,armada-370-pcie, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
+
+static struct platform_driver mvebu_pcie_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = mvebu-pcie,
+
[PATCH 0/3] ARM: kernel: cpu_logical_map misc fixes
Hi Russell, Rob, this series contains simple fixes/improvements related to the DT cpu_logical_map initialization code. I would like to get these patches in in order to have a stable base on top of which I can send the DT topology bindings and cpu_logical_map bindings/parsing code updates for arm and arm64. Thank you very much, Lorenzo Lorenzo Pieralisi (3): ARM: DT: kernel: move temporary cpu map stack array to static data ARM: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes ARM: kernel: fix __cpu_logical_map default initialization arch/arm/include/asm/cputype.h | 2 ++ arch/arm/include/asm/smp_plat.h | 2 +- arch/arm/kernel/devtree.c | 14 ++ arch/arm/kernel/setup.c | 2 +- 4 files changed, 14 insertions(+), 6 deletions(-) -- 1.8.2.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Jason Cooper, On Thu, 16 May 2013 11:40:31 -0400, Jason Cooper wrote: +static int mvebu_pcie_init(void) Building this showed a warning here. It seems you forgot to mark this one as __init. Thomas, I'll fix this up when I pull this in, no need to resend. :) I'll resend, because beyond this function pointed by Ezequiel, there are two other functions that can be marked __init. The one pointed by Ezequiel is important because it causes a section mismatch when !CONFIG_MODULES, because in this case platform_driver_probe() is __init (and this explains what I wasn't seeing the warning, since I'm building CONFIG_MODULES=y). The two other functions are more cosmetic, but good to have as well. It would already been sent if git hadn't decided to do a 'git gc' right after my rebase. It's been gc-ing for quite some time now... Thomas -- 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] of_net.h: Make of_get_phy_mode() return int i.s.o. const int
On Fri, May 3, 2013 at 11:32 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
include/linux/of_net.h:16: warning: type qualifiers ignored on function
return type
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
include/linux/of_net.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index 61bf53b..34597c8 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -9,10 +9,10 @@
#ifdef CONFIG_OF_NET
#include linux/of.h
-extern const int of_get_phy_mode(struct device_node *np);
+extern int of_get_phy_mode(struct device_node *np);
extern const void *of_get_mac_address(struct device_node *np);
#else
-static inline const int of_get_phy_mode(struct device_node *np)
+static inline int of_get_phy_mode(struct device_node *np)
{
return -ENODEV;
}
drivers/of/of_net.c:41:11: error: conflicting types for 'of_get_phy_mode'
include/linux/of_net.h:12:12: note: previous declaration of
'of_get_phy_mode' was here
Doh, of course I also have to update the actual function in drivers/of/of_net.c.
Stay tuned for v2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
On Thu, May 16, 2013 at 05:49:03PM +0200, Thomas Petazzoni wrote: Dear Jason Cooper, On Thu, 16 May 2013 11:40:31 -0400, Jason Cooper wrote: +static int mvebu_pcie_init(void) Building this showed a warning here. It seems you forgot to mark this one as __init. Thomas, I'll fix this up when I pull this in, no need to resend. :) I'll resend, because beyond this function pointed by Ezequiel, there are two other functions that can be marked __init. The one pointed by Ezequiel is important because it causes a section mismatch when !CONFIG_MODULES, because in this case platform_driver_probe() is __init (and this explains what I wasn't seeing the warning, since I'm building CONFIG_MODULES=y). The two other functions are more cosmetic, but good to have as well. It would already been sent if git hadn't decided to do a 'git gc' right after my rebase. It's been gc-ing for quite some time now... Dear boss, I am in desperate need of a 500GB SSD on which to do my kernel work. Thanks, Kranky Kernel Developer hehehe... I'll pull in once you send. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 0/9] PCIe support for the Armada 370 and Armada XP SoCs
Hello, This series of patches introduces PCIe support for the Marvell Armada 370 and Armada XP. I'd like this code to be merged for 3.11. For easier testing, the code has been pushed to: git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v10 This PATCHv10 follows: * PATCHv9, sent on May, 16th 2013 * PATCHv8, sent on April, 9th 2013 * PATCHv7, sent on March, 27th 2013 * PATCHv6, sent on March, 26st 2013 * PATCHv5, sent on March, 21st 2013 * PATCHv4, sent on March, 8th 2013 * PATCHv3, sent on February, 12th 2013 * PATCHv2, sent on January, 28th 2013 * RFCv1, sent on December, 7th 2012 Changes between v9 and v10: * Mark mvebu_pcie_init() as __init, as reported by Ezequiel Garcia. platform_driver_probe() is __init_or_module, so when !CONFIG_MODULES is used, platform_driver_probe() belongs to the __init section. * Mark two other small functions as __init, just because they are only used during the initialization (mvebu_pcie_enable and mvebu_pcie_map_registers). Suggested by Ezequiel Garcia. Changes between v8 and v9: * Rebased on top of 3.10-rc1. Since the PCIe Device Tree informations were merged in 3.10-rc1, it allowed to reduce quite significantly the size of this patch set. * A fix for the PCIe Device Tree information is added as the first patch, it adds a missing range entry to let the global PCIe memory/IO window addresses be correctly translated. It should be merged into the 3.10-rc cycle, to fix the hardware definition of the platform. * The patch set now integrates the latest version of Andrew Murray of/pci patch, that adds the PCI range parsing functions. The one I've integrated is: [PATCH v9 1/3] of/pci: Provide support for parsing PCI DT ranges property * I've fixed the PowerPC64 build problem, which was the reason why this driver was not taken for 3.10. In fact, the patch 'pci: infrastructure to add drivers in drivers/pci/host' was introducing a drivers/pci/host directory, with just an empty Makefile. Unfortunately, an empty Makefile doesn't trigger the generation of drivers/pci/host/built-in.o. So if you try to build the kernel with just this patch applied, and not the PCIe driver itself, the Makefile is empty, and the build breaks. To solve this, I've simply merged this patch with the PCIe driver patch itself. The PCIe driver patch adds the drivers/pci/host/ directory and the related Kconfig/Makefile bits. * Fixed a regression in the driver introduced between the v7 and the v8. A #define something 1 was changed to #define something BIT(1), which obviously doesn't work. Changed to BIT(0), which is correct. Changes between v7 and v8: * In the patch introducing the drivers/pci/host directory, add an empty drivers/pci/host/Makefile to ensure that the kernel still build. This Makefile will actually gets its first useful line when the Marvell PCIe driver gets added. Noted by Neil Greatorex. * Remove bogus (and useless) CFLAGS in drivers/pci/host/Makefile for the compilation of the Marvell PCIe driver. Noticed by Bjorn Helgaas. * Added missing parenthesis in the definition of the PCIE_BAR_CTRL_OFF macro. Noticed by Bjorn Helgaas. * Make mvebu_pcie_link_up() return 'bool' instead of 'int'. Suggested by Bjorn Helgaas. * Change mvebu_pcie_link_up(), mvebu_pcie_set_local_bus_nr(), mvebu_pcie_setup_wins(), mvebu_pcie_setup_hw(), mvebu_pcie_hw_rd_conf(), mvebu_pcie_hw_wr_conf() so that they take a 'struct mvebu_pcie_port *' instead of a 'void __iomem *' as first argument. The base address of the PCIe interface register are available using the 'base' field of 'struct mvebu_pcie_port'. Suggested by Bjorn Helgaas. * Fixed multi-line comments that should have been one line comments. Noticed by Bjorn Helgaas. * Fixed a for() loop in mvebu_pcie_setup_wins() to use the more conventional 'ii 3' ending condition instead of 'i = 2'. Suggested by Bjorn Helgaas. * Add a #define instead of an hardcoded magic value when enabling interrupts A-D in mvebu_pcie_setup_hw(). Suggested by Bjorn Helgaas. * Add a PCIE_CONF_ADDR() to simplify the code in mvebu_pcie_hw_rd_conf() and mvebu_pcie_hw_wr_conf(). Suggested by Bjorn Helgaas. * Clarify the comments in mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change() so that it is clear we look at the new iobase/iolimit (respectively membase/memlimit) values. Suggested by Bjorn Helgaas. * Replace mvebu_pcie_find_port_by_bus() and mvebu_pcie_find_port_by_devfn() by a single mvebu_pcie_find_port() function, and simplify the mvebu_pcie_rd_conf() and mvebu_pcie_wr_conf() functions. Suggested by Bjorn Helgaas. * Fix the computation of the real I/O resource start and end addresses, according to the suggestions of Arnd Bergmann and Jason Gunthorpe. * Remove the MASK/OFFS definition, and use definitions more in the style of
[PATCHv10 1/9] arm: mvebu: fix the 'ranges' property to handle PCIe
Since 82a682676 ('ARM: dts: mvebu: Convert all the mvebu files to use
the range property') all the device nodes of Armada 370/XP are under a
common 'ranges' property that translates the device register addresses
into their absolute address, thanks to the base address of the
internal register space.
However, beyond just the register areas, there are also PCIe I/O and
memory regions, whose addresses should be properly translated. This
patch fixes the Armada 370 and XP ranges property to take PCIe into
account properly.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
Since the PCIe Device Tree description has been merged in 3.10-rc1,
this commit should go in 3.10-rc as well.
---
arch/arm/boot/dts/armada-370-xp.dtsi |3 ++-
arch/arm/boot/dts/armada-370.dtsi|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 272bbc6..550eb77 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -33,7 +33,8 @@
#size-cells = 1;
compatible = simple-bus;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x10;
+ ranges = 0 0 0xd000 0x010 /* internal
registers */
+ 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index b2c1b5a..834c9be 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,7 +29,8 @@
};
soc {
- ranges = 0 0xd000 0x10;
+ ranges = 0 0xd000 0x010 /* internal registers
*/
+ 0xe000 0xe000 0x810 /* PCIe */;
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 2/9] of/pci: Provide support for parsing PCI DT ranges property
From: Andrew Murray andrew.mur...@arm.com
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser_init(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Reviewed-by: Rob Herring rob.herr...@calxeda.com
Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Tested-by: Linus Walleij linus.wall...@linaro.org
Tested-by: Jingoo Han jg1@samsung.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/of/address.c | 67
include/linux/of_address.h | 48 +++
2 files changed, 115 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..fdd0636 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
+
+struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = parser-range[0];
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
+
#endif /* CONFIG_PCI */
/*
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 0506eb5..4c2e6f2 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -4,6 +4,36 @@
#include linux/errno.h
#include linux/of.h
+struct of_pci_range_parser {
+ struct device_node *node;
+ const __be32 *range;
+ const __be32 *end;
+ int np;
+ int pna;
+};
+
+struct of_pci_range {
+ u32 pci_space;
+ u64 pci_addr;
+
[PATCHv10 3/9] of/pci: Add of_pci_get_devfn() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/of/of_pci.c| 34 +-
include/linux/of_pci.h |1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..4dd7b9b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -5,14 +5,15 @@
#include asm/prom.h
static inline int __of_pci_pci_compare(struct device_node *node,
- unsigned int devfn)
+ unsigned int data)
{
- unsigned int size;
- const __be32 *reg = of_get_property(node, reg, size);
+ int devfn;
- if (!reg || size 5 * sizeof(__be32))
+ devfn = of_pci_get_devfn(node);
+ if (devfn 0)
return 0;
- return ((be32_to_cpup(reg[0]) 8) 0xff) == devfn;
+
+ return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -40,3 +41,26 @@ struct device_node *of_pci_find_child_device(struct
device_node *parent,
return NULL;
}
EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+ unsigned int size;
+ const __be32 *reg;
+
+ reg = of_get_property(np, reg, size);
+
+ if (!reg || size 5 * sizeof(__be32))
+ return -EINVAL;
+
+ return (be32_to_cpup(reg) 8) 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..91ec484 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -10,5 +10,6 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq
*out_irq);
struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 8/9] arm: mvebu: PCIe support is now available on mvebu
Now that the PCIe driver for mvebu has been integrated and all its relevant dependencies, we can mark the ARCH_MVEBU platform has MIGHT_HAVE_PCI, which allows to select the PCI bus support if needed. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/mach-mvebu/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index e11acbb..381062d 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -15,6 +15,8 @@ config ARCH_MVEBU select MVEBU_CLK_GATING select MVEBU_MBUS select ZONE_DMA if ARM_LPAE + select MIGHT_HAVE_PCI + select PCI_QUIRKS if PCI if ARCH_MVEBU -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the mvebu-mbus driver.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Bjorn Helgaas bhelg...@google.com
---
.../devicetree/bindings/pci/mvebu-pci.txt | 220 +
drivers/pci/Kconfig|2 +
drivers/pci/Makefile |3 +
drivers/pci/host/Kconfig |8 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pci-mvebu.c | 880
6 files changed, 1114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
create mode 100644 drivers/pci/host/Kconfig
create mode 100644 drivers/pci/host/Makefile
create mode 100644 drivers/pci/host/pci-mvebu.c
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 000..eb69d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,220 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+marvell,armada-370-pcie
+marvell,armada-xp-pcie
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- bus-range: PCI bus numbers covered
+- device_type, set to pci
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+ MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+ are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+ this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either disabled or okay
+- device_type, set to pci
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+ multiple lanes. If this property is not found, we assume that the
+ value is 0.
+
+Example:
+
+pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port 0.0
registers */
+ 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port 2.0
registers */
+ 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port 0.1
registers */
+ 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port 0.2
registers */
+ 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port 0.3
registers */
+ 0x8200 0 0xd008 0xd008 0 0x2000 /* Port 1.0
registers */
+ 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port 3.0
registers */
+ 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port 1.1
registers */
+ 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port 1.2
registers */
+ 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port 1.3
registers */
+ 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
+ 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 0 0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0
[PATCHv10 9/9] arm: mvebu: update defconfig with PCI and USB support
Now that we have the necessary drivers and Device Tree informations to support PCIe on Armada 370 and Armada XP, enable the CONFIG_PCI option. Also, since the Armada 370 Mirabox has a built-in USB XHCI controller connected on the PCIe bus, enable the corresponding options as well. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index f3e8ae0..966281e 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -13,6 +13,8 @@ CONFIG_MACH_ARMADA_370=y CONFIG_MACH_ARMADA_XP=y # CONFIG_CACHE_L2X0 is not set # CONFIG_SWP_EMULATE is not set +CONFIG_PCI=y +CONFIG_PCI_MVEBU=y CONFIG_SMP=y CONFIG_AEABI=y CONFIG_HIGHMEM=y @@ -60,6 +62,7 @@ CONFIG_USB_SUPPORT=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y +CONFIG_USB_XHCI_HCD=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_NEW_LEDS=y -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: kernel: fix __cpu_logical_map default initialization
On Thu, May 16, 2013 at 04:34:07PM +0100, Lorenzo Pieralisi wrote:
For legacy reasons, the __cpu_logical_map array is initialized to 0.
On old pre-DT ARM platforms, smp_setup_processor_id() generates
__cpu_logical_map entries at boot before the number of possible CPUs is
set-up, with values that can be considered valid MPIDRs even if they are
not present in the system booting; this implies that the __cpu_logical_map[]
might end up containing MPIDR values that can be considered valid at logical
indexes corresponding to CPUs that are not marked as possible.
To prevent issues with the current implementation, this patch defines an
MPIDR_INVALID value, statically initializes the __cpu_logical_map[] array to
it
and allows DT parsing code to overwrite values in the __cpu_logical_map array
that were erroneously set-up in smp_setup_processor_id().
What issues have you actually hit with this?
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/cputype.h | 2 ++
arch/arm/include/asm/smp_plat.h | 2 +-
arch/arm/kernel/devtree.c | 10 ++
arch/arm/kernel/setup.c | 2 +-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7652712..dba62cb 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -32,6 +32,8 @@
#define MPIDR_HWID_BITMASK 0xFF
+#define MPIDR_INVALID (~MPIDR_HWID_BITMASK)
+
#define MPIDR_LEVEL_BITS 8
#define MPIDR_LEVEL_MASK ((1 MPIDR_LEVEL_BITS) - 1)
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index aaa61b6..e789832 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -49,7 +49,7 @@ static inline int cache_ops_need_broadcast(void)
/*
* Logical CPU mapping.
*/
-extern int __cpu_logical_map[];
+extern u32 __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
/*
* Retrieve logical cpu index corresponding to a given MPIDR[23:0]
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index d2293c0..08f012e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -79,12 +79,12 @@ void __init arm_dt_init_cpu_maps(void)
* read as 0.
*/
static u32 tmp_map[NR_CPUS] __initdata = {
- [0 ... NR_CPUS-1] = UINT_MAX };
+ [0 ... NR_CPUS-1] = MPIDR_INVALID };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
-
bool bootcpu_valid = false;
+
Random whitespace change.
Will
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv10 4/9] of/pci: Add of_pci_parse_bus_range() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/of/of_pci.c| 25 +
include/linux/of_pci.h |1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 4dd7b9b..42c687a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -64,3 +64,28 @@ int of_pci_get_devfn(struct device_node *np)
return (be32_to_cpup(reg) 8) 0xff;
}
EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+ const __be32 *values;
+ int len;
+
+ values = of_get_property(node, bus-range, len);
+ if (!values || len sizeof(*values) * 2)
+ return -EINVAL;
+
+ res-name = node-name;
+ res-start = be32_to_cpup(values++);
+ res-end = be32_to_cpup(values);
+ res-flags = IORESOURCE_BUS;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 91ec484..7a04826 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,5 +11,6 @@ struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Jason Cooper, On Thu, 16 May 2013 11:56:17 -0400, Jason Cooper wrote: Building this showed a warning here. It seems you forgot to mark this one as __init. Thomas, I'll fix this up when I pull this in, no need to resend. :) I'll resend, because beyond this function pointed by Ezequiel, there are two other functions that can be marked __init. The one pointed by Ezequiel is important because it causes a section mismatch when !CONFIG_MODULES, because in this case platform_driver_probe() is __init (and this explains what I wasn't seeing the warning, since I'm building CONFIG_MODULES=y). The two other functions are more cosmetic, but good to have as well. It would already been sent if git hadn't decided to do a 'git gc' right after my rebase. It's been gc-ing for quite some time now... Dear boss, I am in desperate need of a 500GB SSD on which to do my kernel work. Thanks, Kranky Kernel Developer hehehe... Adding boss in the Cc list :-) Thanks! Thomas -- 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: [PATCHv9 7/9] pci: PCIe driver for Marvell Armada 370/XP systems
On Thu, May 16, 2013 at 06:08:50PM +0200, Thomas Petazzoni wrote: Dear Jason Cooper, On Thu, 16 May 2013 11:56:17 -0400, Jason Cooper wrote: Building this showed a warning here. It seems you forgot to mark this one as __init. Thomas, I'll fix this up when I pull this in, no need to resend. :) I'll resend, because beyond this function pointed by Ezequiel, there are two other functions that can be marked __init. The one pointed by Ezequiel is important because it causes a section mismatch when !CONFIG_MODULES, because in this case platform_driver_probe() is __init (and this explains what I wasn't seeing the warning, since I'm building CONFIG_MODULES=y). The two other functions are more cosmetic, but good to have as well. It would already been sent if git hadn't decided to do a 'git gc' right after my rebase. It's been gc-ing for quite some time now... Dear boss, I am in desperate need of a 500GB SSD on which to do my kernel work. Thanks, Kranky Kernel Developer hehehe... Adding boss in the Cc list :-) Hey, whatever works for you. Good luck! thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: OMAP2+: Simplify NAND support
* Jon Hunter jon-hun...@ti.com [130430 07:16]: Commit 8c8a777 (ARM: OMAP2+: Add function to read GPMC settings from device-tree) added a device-tree property gpmc,device-nand to indicate is the GPMC child device is NAND. This commit should have updated the GPMC NAND documentation (Documentation/devicetree/bindings/mtd/gpmc-nand.txt) to list the property gpmc,device-nand as a required property and also updated the example. However, this property is redundant and not needed because the GPMC child device node for NAND is called nand. Therefore, remove this property. Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks applying into omap-for-v3.11/gpmc. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: kernel: fix __cpu_logical_map default initialization
On Thu, May 16, 2013 at 04:50:38PM +0100, Will Deacon wrote:
On Thu, May 16, 2013 at 04:34:07PM +0100, Lorenzo Pieralisi wrote:
For legacy reasons, the __cpu_logical_map array is initialized to 0.
On old pre-DT ARM platforms, smp_setup_processor_id() generates
__cpu_logical_map entries at boot before the number of possible CPUs is
set-up, with values that can be considered valid MPIDRs even if they are
not present in the system booting; this implies that the __cpu_logical_map[]
might end up containing MPIDR values that can be considered valid at logical
indexes corresponding to CPUs that are not marked as possible.
To prevent issues with the current implementation, this patch defines an
MPIDR_INVALID value, statically initializes the __cpu_logical_map[] array
to it
and allows DT parsing code to overwrite values in the __cpu_logical_map
array
that were erroneously set-up in smp_setup_processor_id().
What issues have you actually hit with this?
I have not hit any, I just thought it would be proper to have the
cpu_logical_map filled with only valid (ie present in HW) MPIDRs (and
by default initialized with MPIDR_INVALID, not 0s which are valid MPIDRs).
I wrote the patch while coding the MPIDR to logical CPU reverse look-up
for the CCI driver and noticed that, if for any reason we do not
constrain the look-up to possible cpus, we might get a logical index
for a CPU that does not exist since smp_setup_processor_id() initializes
the cpu_logical_map up to nr_cpu_ids, with values that might well be
real MPIDRs (but not present in HW).
If we pass an mpidr value to get_logical_index(), that function must not
return a logical index for an MPIDR that does not exist in HW. This can
happen with current code (but I do not think anyone will ever call
get_logical_index() with a mpidr value that has not been read from a CPU
coprocessor, so what I am saying is purely hypothetical).
True, we might check the return value is actually a CPU marked as possible,
provided that check is safe to carry out in low-level PM code where it is
likely to be used.
Overall it can be overkill, granted, it was just meant to clean-up the code,
no more than that.
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
CC: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/cputype.h | 2 ++
arch/arm/include/asm/smp_plat.h | 2 +-
arch/arm/kernel/devtree.c | 10 ++
arch/arm/kernel/setup.c | 2 +-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 7652712..dba62cb 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -32,6 +32,8 @@
#define MPIDR_HWID_BITMASK 0xFF
+#define MPIDR_INVALID (~MPIDR_HWID_BITMASK)
+
#define MPIDR_LEVEL_BITS 8
#define MPIDR_LEVEL_MASK ((1 MPIDR_LEVEL_BITS) - 1)
diff --git a/arch/arm/include/asm/smp_plat.h
b/arch/arm/include/asm/smp_plat.h
index aaa61b6..e789832 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -49,7 +49,7 @@ static inline int cache_ops_need_broadcast(void)
/*
* Logical CPU mapping.
*/
-extern int __cpu_logical_map[];
+extern u32 __cpu_logical_map[];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
/*
* Retrieve logical cpu index corresponding to a given MPIDR[23:0]
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index d2293c0..08f012e 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -79,12 +79,12 @@ void __init arm_dt_init_cpu_maps(void)
* read as 0.
*/
static u32 tmp_map[NR_CPUS] __initdata = {
- [0 ... NR_CPUS-1] = UINT_MAX };
+ [0 ... NR_CPUS-1] = MPIDR_INVALID };
struct device_node *cpu, *cpus;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() MPIDR_HWID_BITMASK : 0;
-
bool bootcpu_valid = false;
+
Random whitespace change.
Gah, sorry.
Thanks for having a look,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On Thu, May 16, 2013 at 10:35 AM, Dan Murphy dmur...@ti.com wrote: I am not sure you really want to do this. If I make the pinctrl part of the led structure then the only way the gpio_wk7 on a1-a3 to be configured is when the CONFIG_LEDS_GPIO flag is set. Do you really want that dependency? You did say it was a key fix At least this way the pins are configured regardless of that flag. That is better as the system will be left in the pinmux configuration handed over from bootloader. The point being, muxing up pins even when not needed(config switched off) has no real benefit - in this case albeit, the default mux was causing a bug. pinctrl IMHO should be considered as any other resource, if it is not mandatory for boot, and needed only for a device functionality when probed, it should done there only. just my 2 cents. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 0/2] clk: add metag specific gate/mux clocks
On 05/16/13 02:56, James Hogan wrote: On 15/05/13 23:31, Stephen Boyd wrote: On 05/10/13 08:02, James Hogan wrote: This adds a metag architecture specific clk-gate and clk-mux which extends the generic ones to use global lock2 to protect the register fields. It is common with metag to have an RTOS running on a different thread or core with access to different bits in the same register (which contain clock gate/switch bits for other clocks). Access to such registers must be serialised with a global lock such as the one provided by the metag architecture port in asm/global_lock.h RFC because despite extending the generic clocks there's still a bit of duplicated code necessary. One alternative is to add special cases to the generic clock components for when a global or callback function based lock is desired instead of a spinlock, but I wasn't sure if that sort of hack would really be appreciated in the generic drivers. Comments? Can you please Cc the devicetree mailing list when proposing new bindings? Erm, I think it was on Cc (devicetree-discuss@lists.ozlabs.org yeh?) I added them in my reply. Your patchset brings up a question I've had which is if we should be putting the bits and register width information in devicetree at all. On the one hand it's nice to not have anything in C code, just iterate over nodes and register clocks. On the other hand, it's the first time I've seen anyone put the register interface into devicetree. From what I can tell, the regulator bindings have put at most the register base and physical properties like enable-time, max voltage, etc., but not what bits are needed to enable/disable a regulator. Also I thought I read somewhere that reg properties shouldn't overlap each other, so if you ever have two clocks living in the same register we're going to violate that. Oh, I wasn't aware of that limitation. The SoC I'm working with has some registers full of clock enable bits (I guess one could have a gate array component with up to 32 clock inputs and outputs) and some registers full of clock mux switch bits (that would get really messy to define as a block since each bit switches between 2 parents, and some of the parents are other clock muxes in the same block). Some registers contain a bunch of low power related bits together, including clock enable bits in the same register as various pinconf settings which is used by a separate pinctrl driver. I have similar hardware and so I would like to hear what the devicetree knowledgeable people think about it. Hopefully Rob or Grant can shed some light here. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] linux/of_platform.h: fix compilation warnings with DT disabled
On Thu, May 16, 2013 at 3:58 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. On 03/01/2013 05:02 PM, Rob Herring wrote: Fix the following compilation warnings (in Simon Horman's renesas.git repo): In file included from arch/arm/mach-shmobile/setup-r8a7779.c:24:0: include/linux/of_platform.h:107:13: warning: ‘struct of_device_id’ declared inside parameter list [enabled by default] include/linux/of_platform.h:107:13: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/of_platform.h:107:13: warning: ‘struct device_node’ declared inside parameter list [enabled by default] linux/of_platform.h only #include's headers with definitions of the above mentioned structures if CONFIG_OF_DEVICE=y but uses them even if not. One solution is to move some #include's out of #ifdef CONFIG_OF_DEVICE and use incomplete declarations for the rest of the structures where the #ifdef move doesn't help... Reported-by: Vladimir Barinov vladimir.bari...@cogentembedded.com Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Reviewed-by: Simon Horman horms+rene...@verge.net.au Grant, could you consider taking this patch? Yes, I can, but I don't seem to have the original patch. Can you send it again. Nevermind. Found it. I'll apply it. Will you drop 'struct device_node' declaration then or should I resend? In fact, I think I should better resend it with the changelog somewhat edited. No, I plan to leave it as is and not rely on device.h by chance declaring device_node. I hoped to see this fix in 3.10-rc1. Is there any hope to see it in 3.10-rc's? The code it fixes the warnings in is already in Linus tree. So I had this queued up, but Grant did not send DT update to Linus for 3.10. The main thing we had was the preprocessor support and that went thru arm-soc tree. I plan to send this and other fixes to Linus for 3.10. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] powerpc/512x: DMA via LocalPlus Bus testing driver
On Thu, May 02, 2013 at 07:23:15PM +0400, Alexander Popov wrote: This module tests Direct Memory Access to some device on LocalPlus Bus for Freescale MPC512x. In other words it tests the bundle of mpc512x_lpbfifo and mpc512x_dma drivers. This testing driver was multiply used with static RAM (CY62167EV30LL-45ZXI) which lives on LocalPlus Bus on our board. This testing driver was used instead of the original static RAM driver and it is an abnormal hack. That is why I just provide the driver code and don't modify any environment. Signed-off-by: Alexander Popov a13xp0p0...@gmail.com --- drivers/misc/mpc512x_lpbdma_test.c | 310 + 1 file changed, 310 insertions(+) create mode 100644 drivers/misc/mpc512x_lpbdma_test.c You obviously didn't test your testing driver to see if it would build in the kernel source tree :( Care to try again? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
