Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework
On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote: +menuconfig GENERIC_PHY + tristate PHY Subsystem + help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. Shouldn't this be something that other drivers select? How will anyone know if they need this or not? --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,544 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2013 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. You really mean any later version (I have to ask)? + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. Are these two paragraphs needed? This isn't a program, and they got a copy of the GPL already with the kernel. +static struct class *phy_class; Why do you need a class? When modifying/adding new sysfs stuff, you need a Documentation/ABI/ entry as well. thanks, greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
Am Dienstag, den 16.07.2013, 09:47 -0600 schrieb Stephen Warren: On 07/16/2013 12:51 AM, Shawn Guo wrote: On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote: Hi Philipp, On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote: This driver implements a reset controller device that toggle a gpio connected to a reset pin of a peripheral IC. The delay between assertion and de-assertion of the reset signal can be configured via device tree. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Stephen Warren swar...@nvidia.com I see this patch is very useful, as GPIOs are widely used to reset components/devices on board. But I do not find the patch in v3.11-rc1. What's your plan about it? Also, I'm wondering if we should register the driver a little bit early. Please see the following patch. If it makes sense to you, I can send the patch to you, or you can just quash it into yours. And here is another change request. diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c - gpio_set_value(drvdata-gpio, value); + if (gpio_cansleep(drvdata-gpio)) + gpio_set_value_cansleep(drvdata-gpio, value); + else + gpio_set_value(drvdata-gpio, value); That's not right. Calling gpio_set_value() v.s. gpio_set_value_cansleep() should be based on the properties of the calling context, not the GPIO being controlled. In other words, if it's permissible to call gpio_set_value_cansleep() at this point in the code, simply always call that, and remove the conditional logic. In which case I'd say let's just call the _cansleep variant here unconditionally and declare that reset_control_assert/deassert() may sleep, just as reset_control_reset() has to anyway. regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] tty: serial: Add initial MSM UART High Speed Lite driver
Hi Kumar,
On Tue, 2013-07-16 at 15:17 -0500, Kumar Gala wrote:
On Jul 1, 2013, at 4:11 AM, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
This is a tty driver with console support for Qualcomm's UART
controllers found in the MSM8974 chipsets. Driver is completely
based on implementation found in codeaurora.org msm_serial_hs_lite
with Android dependences removed. Other changes include, moved to
device managed resources and few cleanups.
Driver functionality was tested in LEGACY_HSUART mode.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
.../bindings/tty/serial/msm_serial_hsl.txt | 52 +
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile|1 +
drivers/tty/serial/msm_serial_hsl.c| 1399
drivers/tty/serial/msm_serial_hsl.h| 294
5 files changed, 1764 insertions(+)
create mode 100644
Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
create mode 100644 drivers/tty/serial/msm_serial_hsl.c
create mode 100644 drivers/tty/serial/msm_serial_hsl.h
diff --git
a/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
new file mode 100644
index 000..972552f
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
@@ -0,0 +1,52 @@
+* Qualcomm MSM HSUART Lite
+
+Required properties:
+- compatible :
+ qcom,msm-lsuart-v14 to be used for UARTDM Core v1.4
If its really v1.4 than the string should be qcom,msm-lsuart-v1.4
I am not sure which is the right number here. codeaurora code uses v14
string for compatible name and 1.4 here and there in the comments.
I am inclined to believe that 1.4 is true.
+
+- reg :
+ offset and length of the register set for both the device,
+ UART core and GBSI core
+
+- reg-names :
+ uart_mem to be used as name of the UART core
+ gbsi_mem to be used as name of the GBSI core
+
+The registers for the qcom,msm-lsuart-v14 device have specify
+UART core block. GSBI reg is optional if specified driver will use
+GSBI specific functionality.
+
+- interrupts : interrupts for UART core
+
+- clocks : Must contain an entry for each entry in clock-names.
+
+- clock-names : Must include the following entries:
+ core_clk - mandatory
+ iface_clk - optional
+
+For details see:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Example:
+
+ serial@f991e000 {
+ compatible = qcom,msm-lsuart-v14;
+ reg = 0xf991e000 0x1000;
+ reg-names = uart_mem;
+ interrupts = 0 108 0;
+ clocks = blsp1_uart2_apps_cxc, blsp1_ahb_cxc;
+ clock-names = core_clk, iface_clk;
+ };
+
+Aliases :
+An alias may be optionally used to bind the UART device to a TTY device
+(ttyHSLalias_num) with a given alias number. Aliases are of the form
+uartn where n is an integer representing the alias number to use.
+On systems with multiple UART devices present, an alias may optionally be
+defined for such devices. The alias value should be from 0 to 255.
+
+Example:
+
+ aliases {
+ uart4 = uart7; // This device will be enumerated as ttyHSL4
+ };
diff --git a/drivers/tty/serial/msm_serial_hsl.c
b/drivers/tty/serial/msm_serial_hsl.c
new file mode 100644
index 000..56c15a8
--- /dev/null
+++ b/drivers/tty/serial/msm_serial_hsl.c
@@ -0,0 +1,1399 @@
+/*
+ * drivers/tty/serial/msm_serial_hsl.c - driver for serial device and
console
+ *
+ * Copyright (C) 2007 Google, Inc.
+ * Copyright (c) 2010-2013, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/* Acknowledgements:
+ * This file is based on msm_serial.c, originally
+ * Written by Robert Love rl...@google.com */
+
+#include linux/clk.h
+#include linux/console.h
+#include linux/debugfs.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/module.h
+#include linux/nmi.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/pm_runtime.h
+#include linux/serial_core.h
+#include linux/tty.h
+#include linux/tty_flip.h
+
+#include msm_serial_hsl.h
+
+/*
+ * There are 3 different kind of UART Core available on MSM.
+ * High Speed UART (i.e. Legacy HSUART), GSBI based
Re: [PATCH -next] mtd: orion_nand: convert to use devm_* APIs
On Wed, Jul 17, 2013 at 10:09:10AM +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Convert to use devm_* APIs to avoid resources leak on error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/mtd/nand/orion_nand.c | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 46f308d..ce711b4 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -85,25 +85,23 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
int ret = 0;
u32 val = 0;
- nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info),
GFP_KERNEL);
+ nc = devm_kzalloc(pdev-dev,
+ sizeof(struct nand_chip) + sizeof(struct mtd_info),
+ GFP_KERNEL);
if (!nc) {
printk(KERN_ERR orion_nand: failed to allocate device
structure.\n);
- ret = -ENOMEM;
- goto no_res;
+ return -ENOMEM;
}
mtd = (struct mtd_info *)(nc + 1);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENODEV;
- goto no_res;
- }
+ if (!res)
+ return -ENODEV;
- io_base = ioremap(res-start, resource_size(res));
+ io_base = devm_ioremap(pdev-dev, res-start, resource_size(res));
if (!io_base) {
printk(KERN_ERR orion_nand: ioremap failed\n);
- ret = -EIO;
- goto no_res;
+ return -EIO;
Hi Wei
Thanks for working on this.
The above code can be further simplified:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
io_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(io_base))
return PTR_ERR(io_base);
While you are editing this file, it would be nice to replace all the
printk() statements with dev_err(), dev_info() etc. Please do that as
a separate patch.
Thanks
Andrew
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP
On 16/07/2013 21:17, Thomas Petazzoni : Dear Jonathan Cameron, On Tue, 16 Jul 2013 20:03:38 +0100, Jonathan Cameron wrote: On 07/16/2013 12:30 PM, Thomas Petazzoni wrote: I've asked exactly this question last week at Linaro Connect during the ARM SoC consolidation panel/discussion, where Grant Likely, Arnd Bergmann, Olof and others were answering Device Tree related questions. My question, which precisely had the at91-adc DT binding in mind was precisely whether we should use different compatible properties to identify different revisions of an IP block and let the driver handle those differences, or whether the DT binding should provide sufficient properties (register offsets, bit numbers, etc.) to make the driver independent of the IP revisions. And clearly, the answer was that different compatible properties should be used to identify the different versions of the IP block, and the driver should abstract out the differences. I.e, was has been done for at91-adc is completely the opposite of the best practices for Device Tree on ARM. See http://www.youtube.com/watch?v=zF_AXLgkFy4feature=player_detailpage#t=1581s where I ask exactly this question, and get answers from Olof Johansson and Grant Likely. They clearly say that the solution of having separate compatible properties and a driver that handles the differences is the way to go. So the way at91-adc (and possibly other at91 drivers) is using the Device Tree is wrong, there should have been multiple compatible properties. It's a shame because this is something we did say when we submitted at91-adc and during the reviews, but the maintainer wasn't listening to our comments... Thanks for getting some clarity on this Thomas. So I'll ask the somewhat obvious question - how do we unwind from where we are to where we want to be wrt to the bindings? During Linaro Connect last week, there was some discussion about marking DT bindings as unstable for a little while, once they get reviewed by a group of DT experts that mark them as stable. Until they are stable, the kernel does not offer any ABI guarantees, and we are free to change the DT bindings as needed. Now, since this unstable/stable thing is not in place at the moment, deciding whether to break or not existing bindings is something to be decided by the maintainer of this platform, judging what is the best option depending on whether there are already many users of the DT for this platform or not, for example. I didn't had in mind that the current discussion about the addition of some properties could cast doubt on the entire at91-adc binding! The binding itself has several drawbacks and is kind of over engineered, I agree with that. Some register offsets in particular have nothing to do in a DT binding. On the other hand, some values are highly dependent on the SoC process itself and can't be stored in the driver because it would require to change the driver for each new SoC, depending on the electrical characteristics. In conclusion, we have to be cautious with this binding and make sure that we don't throw the baby out with the bath water. Moreover, at the time we are just beginning to be comfortable with DT on AT91 and beginning to overcome the difficulty of converting our platforms, I see this new step on the path to mainline + DT stable as another slowdown. Bye, -- Nicolas Ferre ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC v4] media: OF: add sync-on-green-active property
Hi Sylwester, Thanks for the review. On Wed, Jul 17, 2013 at 2:08 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: Hi Prabhakar, [snip] diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..5186c7e 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,9 @@ 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-active: polarity field when video synchronization is + Sync-On-Green. When set the driver determines whether it's a normal operation + or inverted operation. Would you mind adding this entry after pclk-sample property description ? OK. And how about describing it a bit more precisely and similarly to VSYNC/HSYNC, e.g. - sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively. OK I'll paste the above one itself :-) -- Regards, Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/4] ARM: mach-moxart: add MOXA ART device tree files
Just as a reminder, I intend to update this set with some minor changes: 1. remove devicetree bindings for drivers, I will mail those out separately 2. a devicetree node for DMA was added 3. GPIO numbers are now in DT aswell Best regards, Jonas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote: /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Not that it really matters now, but my vexpress-sysreg rework will - most likely - leave only skeleton in the MFD (registering mfd_cells) and other stuff is going to be spread all around. Then I'm planning to move the remaining of the vexpress-specific initialization to drivers/platform/arm/vexpress.c, so maybe sticking vexpress-spc.c to this (non-existing yet) directory would be the right thing to do? Other than that: Acked-by: Pawel Moll pawel.m...@arm.com Thanks! Paweł ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework
Hi, On Wednesday 17 July 2013 11:59 AM, Greg KH wrote: On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote: +menuconfig GENERIC_PHY +tristate PHY Subsystem +help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. Shouldn't this be something that other drivers select? How will anyone know if they need this or not? All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those PHY drivers can be selected like in [1]. The PHY consumer driver should ideally use *depends on* in their Kconfig. [1] - http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,544 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2013 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. You really mean any later version (I have to ask)? That was copied from somewhere :-s + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. Are these two paragraphs needed? This isn't a program, and they got a copy of the GPL already with the kernel. hmm.. I can remove that. +static struct class *phy_class; Why do you need a class? Wanted to group all the PHY drivers to be used by different subsystems (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my initial version [3] on using a bus_type instead of class but then it was decided to go with class itself. [3] - http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html When modifying/adding new sysfs stuff, you need a Documentation/ABI/ entry as well. I'm not actually adding any new sysfs entry other than what a *class_create* must have created. Do I need to add one for that? Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 0/2] regulator: palmas-pmic: doc: update device tree bindings
On Tue, Jul 16, 2013 at 11:41:08AM -0500, Nishanth Menon wrote: We seem to have a few missing updates to device tree bindings with the latest set of changes getting merged in. Applied both, thanks. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC v2 2/5] dma: mpc512x: add support for peripheral transfers
On Tue, Jul 16, 2013 at 12:37 +0200, Lars-Peter Clausen wrote:
On 07/14/2013 02:01 PM, Gerhard Sittig wrote:
From: Alexander Popov a13xp0p0...@gmail.com
introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers
refuse to prepare chunked transfers (transfers with more than one part)
as long as proper support for scatter/gather is lacking
keep MPC8308 operational by always starting transfers from software,
this SoC appears to not have request lines for flow control when
peripherals are involved in transfers
I had a look at the current driver and it seems that any channel can be used
for memcpy operation not only the MDDRC channel. Since the dmaengine API
will just pick one of the currently free channels when performing a memcpy
operation I think this patch breaks memcpy operations. You probably need to
register two dma controllers, one for memcpy operations one for slave
operations, that way you can ensure that only the MDDRC channel is used for
memcpy operations.
OK, so the need for explicit start in software or external
request by the peripheral remains, but the condition for the
choice is different. It might become a flag attached to the DMA
channel, that gets setup in the prep routines (memory and slave
access each use their own prep calls) and gets evaluated in
execute. Something like will access memory, or will access
peripheral (the latter may be preferrable since slave support is
the new feature).
This assumes that the non-MDDRC channels can get used for memory
transfers as well, which your description of the the former use
suggests, when slave support was absent.
Making the MDDRC channel preferrable for memcpy operations is
orthogonal to that.
[ introduction of slave s/g preparation and device control ]
Signed-off-by: Alexander Popov a13xp0p0...@gmail.com
[ execute() start condition, mpc8308 compat, terminate all, s/g length
check, reworded commit msg ]
Signed-off-by: Gerhard Sittig g...@denx.de
---
[...]
+
+static int mpc_dma_device_control(struct dma_chan *chan, enum dma_ctrl_cmd
cmd,
+ unsigned long arg)
+{
+ struct mpc_dma_chan *mchan;
+ struct mpc_dma *mdma;
+ struct dma_slave_config *cfg;
+
+ mchan = dma_chan_to_mpc_dma_chan(chan);
+ switch (cmd) {
+ case DMA_TERMINATE_ALL:
+ /* disable channel requests */
+ mdma = dma_chan_to_mpc_dma(chan);
+ out_8(mdma-regs-dmacerq, chan-chan_id);
+ list_splice_tail_init(mchan-prepared, mchan-free);
+ list_splice_tail_init(mchan-queued, mchan-free);
+ list_splice_tail_init(mchan-active, mchan-free);
This probably need locking.
Ah, yes. It needs to grab the same lock as all the other list
manipulations in the driver's source.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, Jul 17, 2013 at 10:18:25AM +0100, Pawel Moll wrote: On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote: /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Not that it really matters now, but my vexpress-sysreg rework will - most likely - leave only skeleton in the MFD (registering mfd_cells) and other stuff is going to be spread all around. Then I'm planning to move the remaining of the vexpress-specific initialization to drivers/platform/arm/vexpress.c, so maybe sticking vexpress-spc.c to this (non-existing yet) directory would be the right thing to do? Done. I do not think there is a point in splitting the patch to create the dir and make infrastructure, so I squashed everything in the original patch. I have not added any maintainer for that dir/file, I guess it can wait till you finish the rework so that you can add yourself there. If that's all I need to change I do not even think that reposting is necessary. It does matter though, since it implies changes on who is in charge of ack/nack'ing this code, if it is no more an mfd matter. I will wait to check all interested/concerned parties opinions, that are always welcome. Other than that: Acked-by: Pawel Moll pawel.m...@arm.com Thank you !!! Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
Hi Stephen, On Monday 15 July 2013 21:39:31 Stephen Warren wrote: On 07/15/2013 07:10 PM, Laurent Pinchart wrote: On Friday 12 July 2013 08:42:41 Stephen Warren wrote: ... I think the values for any common system-wide flags should be defined once in some system-wide place, and the values for any HW-specific values should be defined only in the documentation for that specific HW. You could try and avoid conflicts by either: a) Allocating system-wide flags from bit 0 up, and HW-specific flags from bit 31 down. or: b) Using 1 cell for standard flags, and a separate cell for any HW-specific flags. Drivers can quite easily adapt to adding extra cells to #pwm-cells, thus making adding a HW-specific cell later backwards-compatible. I wasn't referring to HW-specific flags, but rather to system-wide flags that might not be supported by all drivers. If we later add new system-wide flags I think the individual DT bindings should explicitly document which flags they support. Shouldn't all system-wide flags be supported by all HW, perhaps being implemented by the core subsystem rather than individual drivers to ensure that? Consider the case of the GPIO active-low flag which is actually implemented in SW, hence can work with any GPIO controller. Perhaps that's not possible in all cases, in which case, yes, it does make sense to define which of the common flags a particular HW module supports. It largely depends on what we consider as system flags. We should probably be talking about common flags instead of system flags. I usually try to standardize DT properties that are common to multiple devices. Some of those properties can apply to all devices of the same class (possibly implemented/emulated in software when the hardware doesn't support them), but others are just commonly seen properties that don't make sense for all the devices. One example I'm familiar with can be found in V4L2 DT bindings. We've standardized properties to specify what kind of video synchronization signals devices support/use. Not all synchronization signals are supported by a given video transmitter, so DT bindings for such chips list (or at least should list) the common properties supported by a given device. The definitions of the properties should of course not be duplicated to all individual DT bindings. But then there's a problem where people assume that the common flags are always available, and somewhere they aren't... Care is needed in the choice of which common flags to define and/or how they're used. Exactly. That's why I think listing the supported common flags in individual bindings makes sense when some of the flags are not supported by all devices. As the only PWM flags currently used are common to all PWM devices I can leave this out now. I have no strong preference, I'll follow your opinion on this. -- Regards, Laurent Pinchart ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote: On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote: clocks need to get prepared before they can get enabled, fix the MPC512x PSC SPI master's initialization Signed-off-by: Gerhard Sittig g...@denx.de --- drivers/spi/spi-mpc512x-psc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c index 29fce6a..76b20ea 100644 --- a/drivers/spi/spi-mpc512x-psc.c +++ b/drivers/spi/spi-mpc512x-psc.c @@ -395,7 +395,7 @@ static int mpc512x_psc_spi_port_config(struct spi_master *master, sprintf(name, psc%d_mclk, master-bus_num); spiclk = clk_get(master-dev, name); - clk_enable(spiclk); + clk_prepare_enable(spiclk); mps-mclk = clk_get_rate(spiclk); clk_put(spiclk); This code is *clearly* buggy and should be fixed rather than papered over. Not only is there no matching put the driver is also dropping the reference to the clock rather than holding on to it while it's in use. This code refers to the driver's original condition, right? I agree that the driver has been suffering from incomplete clock handling since it was born three years ago. And that this issue shall get addressed. The question is just whether it needs to be part of this series which has a different focus. What the above patch addresses is prevention of an immediate and fatal breakage, when common clock gets used but clocks aren't prepared before getting enabled. So I consider it appropriate as a step in preparation before introducing support for common clock on the platform. (It's funny that I had a comment in this spirit in the commit message, but trimmed it to not be overly verbose.) What the patch does not address is to fix any other deficiencies in the driver which might have been lurking there for ages. This would be the scope of a different patch or series, as addressing it here as well would mix orthogonal issues within one series, and would complicate review and test (and would delay or even potentially kill the introduction of desirable support for common infrastructure just because other legacy non-fatal issues aren't addressed as well in bypassing). I will look into what I can do to address your concerns about proper general clock handling in this specific driver. But I'm unable to do this for all other drivers as well which I happen to pass by as I work on platform code (partially due to lack of knowledge). In any case I won't be able to test all of these changes in all subsystems (mostly due to lack of hardware and test setups). So I suggest to leave these general cleanup activities for a separate series. The current series certainly improves general platform code, transparently brings new drivers into successful operation, and keeps the quality of existing code (doesn't break anything, does even actively prevent breakage). So it shall be acceptable despite its not being perfect (like addressing each and every other aspect which may arise elsewhere). Where would I stop then? Sorry for the lengthy reply, but I guess it's about just one general aspect which equally applies to other parts of the series, not just the specific SPI driver which the feedback was provided for. And I do appreciate your looking at the submission. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 15/24] serial: mpc512x: OF clock lookup, use the 'mclk' name
On Mon, Jul 15, 2013 at 23:54 +0200, Sascha Hauer wrote:
On Mon, Jul 15, 2013 at 11:46:01PM +0200, Gerhard Sittig wrote:
with device tree based clock lookup, the MCLK name no longer
depends on the PSC index
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/tty/serial/mpc52xx_uart.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tty/serial/mpc52xx_uart.c
index 53c1093..221fb89 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -619,21 +619,17 @@ static irqreturn_t mpc512x_psc_handle_irq(struct
uart_port *port)
static int mpc512x_psc_clock(struct uart_port *port, int enable)
{
struct clk *psc_clk;
- int psc_num;
- char clk_name[10];
if (uart_console(port))
return 0;
- psc_num = (port-mapbase 0xf00) 8;
- snprintf(clk_name, sizeof(clk_name), psc%d_mclk, psc_num);
- psc_clk = clk_get(port-dev, clk_name);
+ psc_clk = clk_get(port-dev, mclk);
Same comment applies here as Mark made to the spi driver.
So I'd like to respond in the same way as I did for the SPI
driver. :)
The scope of this series is the introduction of support for the
common clock framework. Addressing other (legacy non-fatal and
previously accepted) issues as they get identified in bypassing
would be the scope of a separate patch or series.
I'm not questioning the need to fix other additionally identified
issues. I'm just asking whether they shall be in the scope of
this very series.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] msm_serial: add missing iounmap() on error in msm_request_port()
On Wed, 2013-07-17 at 13:34 +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing iounmap() before return from msm_request_port()
in the error handling case.
Reviewed-by: Ivan T. Ivanov iiva...@mm-sol.com
Regards,
Ivan
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/tty/serial/msm_serial.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 2c6cfb3..0b38b28 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -637,7 +637,7 @@ static int msm_request_port(struct uart_port *port)
if (!request_mem_region(gsbi_resource-start, size,
msm_serial)) {
ret = -EBUSY;
- goto fail_release_port;
+ goto fail_release_port_membase;
}
msm_port-gsbi_base = ioremap(gsbi_resource-start, size);
@@ -651,6 +651,8 @@ static int msm_request_port(struct uart_port *port)
fail_release_gsbi:
release_mem_region(gsbi_resource-start, size);
+fail_release_port_membase:
+ iounmap(port-membase);
fail_release_port:
release_mem_region(port-mapbase, size);
return ret;
--
To unsubscribe from this list: send the line unsubscribe linux-serial in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] ARM: OMAP2+: omap_device: add dynamic pinctrl handling
Hi Grygorii, On 07/17/2013 02:41 PM, Grygorii Strashko wrote: Hi Tony, Kevin This patch series introduces dynamic pinctrl handling in OMAP device framework in the same way as it was before switching to DT. This allow OMAP devices driver's developers to simply add dynamic pinctrl handling for default, active, idle, sleep PIN states in their drivers by modifying DT definitions only - no modifications in drivers code are not needed. Overall I like the idea but can we make a provision for device drivers to override this default pin state handling? The OMAP EHCI driver is one such special case where the wakeup mechanism is tied to pinctrl states as it uses IO daisy chaining to implement wakeup. So depending on whether wakeup needs to be enabled or not I must be able to chose whether I put the pin in just sleep state or sleep with wakeup state. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 05/24] clk: wrap I/O access for improved portability
On Mon, Jul 15, 2013 at 21:38 +0200, Sascha Hauer wrote: On Mon, Jul 15, 2013 at 08:47:34PM +0200, Gerhard Sittig wrote: diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c index 6d55eb2..2c07061 100644 --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -104,7 +104,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw, struct clk_divider *divider = to_clk_divider(hw); unsigned int div, val; - val = readl(divider-reg) divider-shift; + val = clk_readl(divider-reg) divider-shift; val = div_mask(divider); Would it be an option to use regmap for the generic dividers/muxes instead? This should be suitable for ppc and also for people who want to use the generic clocks on i2c devices. Does regmap assume that those registers form a (dense) array of equal sized items? Does it introduce unconditional indirection and requirement for explicit setup beyond mere mapping? What's the overhead compared to the readl/inbe32 approach that's currently resolved at compile time? Neither of the above needs to be a blocker, just needs to be acceptable after consideration. So far nobody appears to have felt pain with the LE32 register assumption. BTW does the common clock support that I introduce for MPC512x only cover those parts from crystal over internal busses to internal peripherals (register files). It does not include bitrate generation within the peripherals -- this appears to remain the domain of individual drivers, which keep manipulating register fields to derive wire bitrates from internal references. Sharing drivers between platforms with and without common clock support forbids the switch anyway, or both CCF abstraction as well as local register manipulation need to get implemented in parallel, as I did for the mscan(4) driver. Some of these bitrate related registers aren't 32bit entities and thus could not get managed by the common clock primitives in their current form. Some of the IP blocks may even spread integer values across several non-adjacent bit fields for legacy reasons, but I guess that these aren't in the scope of the shared primitives either (and they may not be popular either). While we are at improvements for the common clock primitives: What I missed was support for fractional dividers, i.e. dividers with a register bitfield backed divider part but a fixed factor multiplier part. Currently there's only dividers (bitfield factor or bitfield with table lookup for the factor) and fixed-factor (multiplier and divider, but both of them fixed and not adjustable by register manipulation). This was addressed by intermediate clock items (ungated, x4) virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
On Wed, Jul 17, 2013 at 01:22:29PM +0200, Gerhard Sittig wrote: On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote: On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote: sprintf(name, psc%d_mclk, master-bus_num); spiclk = clk_get(master-dev, name); - clk_enable(spiclk); + clk_prepare_enable(spiclk); mps-mclk = clk_get_rate(spiclk); clk_put(spiclk); This code is *clearly* buggy and should be fixed rather than papered over. Not only is there no matching put the driver is also dropping the reference to the clock rather than holding on to it while it's in use. This code refers to the driver's original condition, right? I agree that the driver has been suffering from incomplete clock handling since it was born three years ago. And that this issue shall get addressed. The question is just whether it needs to be part of this series which has a different focus. This is a pretty long e-mail. It'd probably have taken less time to fix the issues than to reply to the e-mail... but anyway. A big part of the issue with the state of the driver is that there's obvious clock API abuse going on that isn't corrected here - the main one is that the sprintf() for the clock name is a fairly clear warning sign, the driver should be using a fixed value there. This raises a warning flag for me about the quality of the common clock API implementation that's being sent and/or the potential for bugs to be noticed with the common clock framework. I'd not expect this code to actually work, and looking at the rest of the series I don't see how it does since I can't see what forces the name. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 17 Jul 2013, Pawel Moll wrote: On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote: /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Not that it really matters now, but my vexpress-sysreg rework will - most likely - leave only skeleton in the MFD (registering mfd_cells) and other stuff is going to be spread all around. Then I'm planning to move the remaining of the vexpress-specific initialization to drivers/platform/arm/vexpress.c, so maybe sticking vexpress-spc.c to this (non-existing yet) directory would be the right thing to do? I don't like this idea. We worked hard to shrink platform specific directories such as arch/arm/mach-*/ as much as possible. Simply moving stuff to drivers/platform/arm/* doesn't make the situation any much better. If this is really miscelaneous code that really doesn't fit anywhere else, it should rather go into drivers/misc/ as a last resort. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] Input: olpc_apsp - remove redundant dev_err call in olpc_apsp_probe()
On Tue, Jul 16, 2013 at 11:31 PM, Wei Yongjun weiyj...@gmail.com wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Daniel Drake d...@laptop.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote: If this is really miscelaneous code that really doesn't fit anywhere else, it should rather go into drivers/misc/ as a last resort. Interestingly enough drivers/misc was my first choice for all the vexpress stuff, but it wasn't received well... Anyway, the SPC driver as it is now seem to be a power management system driver. Maybe a relevant directory would be in place? Wouldn't PSCI belong there as well? (there are two psci.c files in arch/arm and arch/arm64, surprisingly similar ones ;-) The bottom line is: today it is not an MFD driver. Paweł ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'
Arnd -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: 2013年7月15日 3:30 To: Neil Zhang Cc: Jason Cooper; Matt Sealey; grant.lik...@linaro.org; haojian.zhu...@gmail.com; devicetree-discuss@lists.ozlabs.org; linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell' On Thursday 11 July 2013, Neil Zhang wrote: To do this properly, the drivers are going to have to be compatible with the old and the new names, and the binding docs updated to reflect the legacy name and the preferred name. Properly would be as above. You can stop using stock tickers for new company names, but anything that has been defined in a device tree before has to stay that way, and all the manufacturer prefixes to device names should be the same. What you're proposing is purely driver bloat and increasing the size of kernel. *I'm* not proposing to change the name, Neil is. I'm proposing that iff they chose to do that, don't break sh*t along the way. What's your opinion? We discussed the topic of fixing bad bindings vs. keeping backwards compatibility during last week's Linaro Connect. The main outcome was that we need to have a better review for new bindings getting merged to avoid this situation in the future, but the general consensus seems that bindings that are already in use but were never reviewed properly (which should have caught this) should be changed. So would you mind if I leave it there (discard this patch) and still use the current 'mvrl' prefix for this patch set. We will likely establish an annotation in the binding soon to mark those that can not be changed as opposed to those that are not considered stable yet. Arnd Best Regards, Neil Zhang ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 03/15] ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
OF/DT core library now provides architecture specific hook to match the
logical cpu index with the corresponding physical identifier. Most of the
cpu DT node parsing and initialisation is contained in devtree.c. So it's
better to define ARM specific arch_match_cpu_phys_id there.
This mainly helps to avoid replication of the code doing CPU node parsing
and physical(MPIDR) to logical mapping.
Cc: Russell King li...@arm.linux.org.uk
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
arch/arm/kernel/devtree.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5859c8b..5a36f32 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -169,6 +169,11 @@ void __init arm_dt_init_cpu_maps(void)
}
}
+int arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+ return (phys_id MPIDR_HWID_BITMASK) == cpu_logical_map(cpu);
+}
+
/**
* setup_machine_fdt - Machine setup when an dtb was passed to the kernel
* @dt_phys: physical address of dt blob
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 02/15] driver/core: cpu: initialize of_node in cpu's device struture
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com CPUs are also registered as devices but the of_node in these cpu devices are not initialized. Currently different drivers requiring to access cpu device node are parsing the nodes themselves and initialising the of_node in cpu device. The of_node in all the cpu devices needs to be initialized properly and at one place. The best place to update this is CPU subsystem driver when registering the cpu devices. The OF/DT core library now provides of_get_cpu_node to retrieve a cpu device node for a given logical index by abstracting the architecture specific details. This patch uses of_get_cpu_node to assign of_node when registering the cpu devices. Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com --- drivers/base/cpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index a16d20e..c0f7a08 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -14,6 +14,7 @@ #include linux/slab.h #include linux/percpu.h #include linux/acpi.h +#include linux/of.h #include base.h @@ -289,6 +290,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num) cpu-dev.release = cpu_device_release; cpu-dev.offline_disabled = !cpu-hotpluggable; cpu-dev.offline = !cpu_online(num); + cpu-dev.of_node = of_get_cpu_node(num); #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE cpu-dev.bus-uevent = arch_cpu_uevent; #endif -- 1.8.1.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 05/15] ARM: mvebu: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently set_secondary_cpus_clock assume the CPU logical ordering
and the MPDIR in DT are same, which is incorrect.
Since the CPU device nodes can be retrieved in the logical ordering
using the DT helper, we can remove the devices tree parsing.
This patch removes DT parsing by making use of of_get_cpu_node.
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
arch/arm/mach-mvebu/platsmp.c | 52 ---
1 file changed, 24 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 93f2f3a..12585ad 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -23,51 +23,47 @@
#include linux/of.h
#include linux/mbus.h
#include asm/cacheflush.h
+#include asm/prom.h
#include asm/smp_plat.h
#include common.h
#include armada-370-xp.h
#include pmsu.h
#include coherency.h
+static struct clk *__init get_cpu_clk(int cpu)
+{
+ struct clk *cpu_clk;
+ struct device_node *np = of_get_cpu_node(cpu);
+
+ if (WARN(!np, missing cpu node\n))
+ return NULL;
+ cpu_clk = of_clk_get(np, 0);
+ if (WARN_ON(IS_ERR(cpu_clk)))
+ return NULL;
+ return cpu_clk;
+}
+
void __init set_secondary_cpus_clock(void)
{
- int thiscpu;
+ int thiscpu, cpu;
unsigned long rate;
- struct clk *cpu_clk = NULL;
- struct device_node *np = NULL;
+ struct clk *cpu_clk;
thiscpu = smp_processor_id();
- for_each_node_by_type(np, cpu) {
- int err;
- int cpu;
-
- err = of_property_read_u32(np, reg, cpu);
- if (WARN_ON(err))
- return;
-
- if (cpu == thiscpu) {
- cpu_clk = of_clk_get(np, 0);
- break;
- }
- }
- if (WARN_ON(IS_ERR(cpu_clk)))
+ cpu_clk = get_cpu_clk(thiscpu);
+ if (!cpu_clk)
return;
clk_prepare_enable(cpu_clk);
rate = clk_get_rate(cpu_clk);
/* set all the other CPU clk to the same rate than the boot CPU */
- for_each_node_by_type(np, cpu) {
- int err;
- int cpu;
-
- err = of_property_read_u32(np, reg, cpu);
- if (WARN_ON(err))
+ for_each_possible_cpu(cpu) {
+ if (cpu == thiscpu)
+ continue;
+ cpu_clk = get_cpu_clk(cpu);
+ if (!cpu_clk)
return;
-
- if (cpu != thiscpu) {
- cpu_clk = of_clk_get(np, 0);
- clk_set_rate(cpu_clk, rate);
- }
+ clk_set_rate(cpu_clk, rate);
}
}
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 09/15] cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Cc: Mark Langsdorf mark.langsd...@calxeda.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/highbank-cpufreq.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/highbank-cpufreq.c
b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..794123f 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -69,23 +69,17 @@ static int hb_cpufreq_driver_init(void)
if (!of_machine_is_compatible(calxeda,highbank))
return -ENODEV;
- for_each_child_of_node(of_find_node_by_path(/cpus), np)
- if (of_get_property(np, operating-points, NULL))
- break;
-
- if (!np) {
- pr_err(failed to find highbank cpufreq node\n);
- return -ENOENT;
- }
-
cpu_dev = get_cpu_device(0);
if (!cpu_dev) {
pr_err(failed to get highbank cpufreq device\n);
- ret = -ENODEV;
- goto out_put_node;
+ return -ENODEV;
}
- cpu_dev-of_node = np;
+ np = of_node_get(cpu_dev-of_node);
+ if (!np) {
+ pr_err(failed to find highbank cpufreq node\n);
+ return -ENOENT;
+ }
cpu_clk = clk_get(cpu_dev, NULL);
if (IS_ERR(cpu_clk)) {
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/kirkwood-cpufreq.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
b/drivers/cpufreq/kirkwood-cpufreq.c
index c233ea6..18aa3eb 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/clk.h
#include linux/clk-provider.h
+#include linux/cpu.h
#include linux/cpufreq.h
#include linux/of.h
#include linux/platform_device.h
@@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
static int kirkwood_cpufreq_probe(struct platform_device *pdev)
{
struct device_node *np;
+ struct device *cpu_dev;
struct resource *res;
int err;
@@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device
*pdev)
if (IS_ERR(priv.base))
return PTR_ERR(priv.base);
- np = of_find_node_by_path(/cpus/cpu@0);
- if (!np)
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ dev_err(pdev-dev, failed to get cpu device\n);
return -ENODEV;
+ }
+
+ np = of_node_get(cpu_dev-of_node);
+ if (!np) {
+ dev_err(pdev-dev, failed to get cpu device node\n);
+ return -ENODEV;
+ }
priv.cpu_clk = of_clk_get_by_name(np, cpu_clk);
if (IS_ERR(priv.cpu_clk)) {
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 13/15] cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/maple-cpufreq.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c
index cdd6291..bc7233b 100644
--- a/drivers/cpufreq/maple-cpufreq.c
+++ b/drivers/cpufreq/maple-cpufreq.c
@@ -19,6 +19,7 @@
#include linux/kernel.h
#include linux/delay.h
#include linux/sched.h
+#include linux/cpu.h
#include linux/cpufreq.h
#include linux/init.h
#include linux/completion.h
@@ -201,7 +202,7 @@ static struct cpufreq_driver maple_cpufreq_driver = {
static int __init maple_cpufreq_init(void)
{
- struct device_node *cpus;
+ struct device *cpu_dev;
struct device_node *cpunode;
unsigned int psize;
unsigned long max_freq;
@@ -217,24 +218,17 @@ static int __init maple_cpufreq_init(void)
!of_machine_is_compatible(Momentum,Apache))
return 0;
- cpus = of_find_node_by_path(/cpus);
- if (cpus == NULL) {
- DBG(No /cpus node !\n);
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ pr_err(failed to get cpu device\n);
return -ENODEV;
}
/* Get first CPU node */
- for (cpunode = NULL;
-(cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
- const u32 *reg = of_get_property(cpunode, reg, NULL);
- if (reg == NULL || (*reg) != 0)
- continue;
- if (!strcmp(cpunode-type, cpu))
- break;
- }
+ cpunode = of_node_get(cpu_dev-of_node);
if (cpunode == NULL) {
printk(KERN_ERR cpufreq: Can't find any CPU 0 node\n);
- goto bail_cpus;
+ goto bail_noprops;
}
/* Check 970FX for now */
@@ -290,14 +284,11 @@ static int __init maple_cpufreq_init(void)
rc = cpufreq_register_driver(maple_cpufreq_driver);
of_node_put(cpunode);
- of_node_put(cpus);
return rc;
bail_noprops:
of_node_put(cpunode);
-bail_cpus:
- of_node_put(cpus);
return rc;
}
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 00/15] DT/core: update cpu device of_node
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com As more and more information is getting added into the cpu node, the number of drivers needing to parse the device tree for CPU nodes are increasing. Most of the time, the information needed from the cpu node is preferred in the logical CPU order. Hence many drivers first parse and search the CPU node, match them to logical index if needed and then search for the required property inside a particular cpu node. Some of them assume the logical and physical CPU ordering to be same which is incorrect. This patch series initialises the of_node in all the cpu devices when registering the CPU device. 1. This avoids different drivers having to parse the cpu nodes to obtain different attributes like operating points, latency,...etc. 2. This handles different physical and logical cpu ordering which is not the case in current code. 3. Also all the cpu nodes will have their of_node initialised correctly. Currently different drivers assign them partially and incorrectly. 4. Removes all the reduntant parsing in various drivers. Changes v1-v2: 1. Moved most of arch_of_get_cpu_node to OF/DT core as of_get_cpu_node adding a provision for architecture specific hooks for matching logical and physical ids. 2. Extended removal of DT cpu node parsing to PPC cpufreq drivers 3. Added Acks from Viresh and Shawn Regards, Sudeep Sudeep KarkadaNagesha (15): of: add support for retrieving cpu node for a given logical cpu index driver/core: cpu: initialize of_node in cpu's device struture ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id ARM: topology: remove hwid/MPIDR dependency from cpu_capacity ARM: mvebu: remove device tree parsing for cpu nodes drivers/bus: arm-cci: avoid parsing DT for cpu device nodes cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes cpufreq: arm_big_little: remove device tree parsing for cpu nodes cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes arch/arm/kernel/devtree.c | 5 +++ arch/arm/kernel/topology.c | 61 +++--- arch/arm/mach-imx/mach-imx6q.c | 3 +- arch/arm/mach-mvebu/platsmp.c | 52 ++--- drivers/base/cpu.c | 2 ++ drivers/bus/arm-cci.c | 28 drivers/cpufreq/arm_big_little_dt.c | 39 ++ drivers/cpufreq/cpufreq-cpu0.c | 23 +++-- drivers/cpufreq/highbank-cpufreq.c | 18 -- drivers/cpufreq/imx6q-cpufreq.c | 4 +-- drivers/cpufreq/kirkwood-cpufreq.c | 14 ++-- drivers/cpufreq/maple-cpufreq.c | 23 - drivers/cpufreq/pmac32-cpufreq.c| 11 ++- drivers/cpufreq/pmac64-cpufreq.c| 54 ++ drivers/cpufreq/spear-cpufreq.c | 10 +- drivers/of/base.c | 66 + include/linux/of.h | 5 +++ 17 files changed, 213 insertions(+), 205 deletions(-) -- 1.8.1.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 07/15] cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Acked-by: Shawn Guo shawn@linaro.org
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
arch/arm/mach-imx/mach-imx6q.c | 3 +--
drivers/cpufreq/imx6q-cpufreq.c | 4 +---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 7be13f8..a02f275 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -254,13 +254,12 @@ static void __init imx6q_opp_init(struct device *cpu_dev)
{
struct device_node *np;
- np = of_find_node_by_path(/cpus/cpu@0);
+ np = of_node_get(cpu_dev-of_node);
if (!np) {
pr_warn(failed to find cpu0 node\n);
return;
}
- cpu_dev-of_node = np;
if (of_init_opp_table(cpu_dev)) {
pr_warn(failed to init OPP table\n);
goto put_node;
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index e37cdae..b16632b 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -221,14 +221,12 @@ static int imx6q_cpufreq_probe(struct platform_device
*pdev)
cpu_dev = pdev-dev;
- np = of_find_node_by_path(/cpus/cpu@0);
+ np = of_node_get(cpu_dev-of_node);
if (!np) {
dev_err(cpu_dev, failed to find cpu0 node\n);
return -ENOENT;
}
- cpu_dev-of_node = np;
-
arm_clk = devm_clk_get(cpu_dev, arm);
pll1_sys_clk = devm_clk_get(cpu_dev, pll1_sys);
pll1_sw_clk = devm_clk_get(cpu_dev, pll1_sw);
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 14/15] cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/pmac64-cpufreq.c | 54 ++--
1 file changed, 18 insertions(+), 36 deletions(-)
diff --git a/drivers/cpufreq/pmac64-cpufreq.c b/drivers/cpufreq/pmac64-cpufreq.c
index 7ba4234..b60ccea 100644
--- a/drivers/cpufreq/pmac64-cpufreq.c
+++ b/drivers/cpufreq/pmac64-cpufreq.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/delay.h
#include linux/sched.h
+#include linux/cpu.h
#include linux/cpufreq.h
#include linux/init.h
#include linux/completion.h
@@ -383,9 +384,8 @@ static struct cpufreq_driver g5_cpufreq_driver = {
#ifdef CONFIG_PMAC_SMU
-static int __init g5_neo2_cpufreq_init(struct device_node *cpus)
+static int __init g5_neo2_cpufreq_init(struct device_node *cpunode)
{
- struct device_node *cpunode;
unsigned int psize, ssize;
unsigned long max_freq;
char *freq_method, *volt_method;
@@ -405,20 +405,6 @@ static int __init g5_neo2_cpufreq_init(struct device_node
*cpus)
else
return -ENODEV;
- /* Get first CPU node */
- for (cpunode = NULL;
-(cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
- const u32 *reg = of_get_property(cpunode, reg, NULL);
- if (reg == NULL || (*reg) != 0)
- continue;
- if (!strcmp(cpunode-type, cpu))
- break;
- }
- if (cpunode == NULL) {
- printk(KERN_ERR cpufreq: Can't find any CPU 0 node\n);
- return -ENODEV;
- }
-
/* Check 970FX for now */
valp = of_get_property(cpunode, cpu-version, NULL);
if (!valp) {
@@ -537,9 +523,9 @@ static int __init g5_neo2_cpufreq_init(struct device_node
*cpus)
#endif /* CONFIG_PMAC_SMU */
-static int __init g5_pm72_cpufreq_init(struct device_node *cpus)
+static int __init g5_pm72_cpufreq_init(struct device_node *cpunode)
{
- struct device_node *cpuid = NULL, *hwclock = NULL, *cpunode = NULL;
+ struct device_node *cpuid = NULL, *hwclock = NULL;
const u8 *eeprom = NULL;
const u32 *valp;
u64 max_freq, min_freq, ih, il;
@@ -548,17 +534,6 @@ static int __init g5_pm72_cpufreq_init(struct device_node
*cpus)
DBG(cpufreq: Initializing for PowerMac7,2, PowerMac7,3 and
RackMac3,1...\n);
- /* Get first CPU node */
- for (cpunode = NULL;
-(cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
- if (!strcmp(cpunode-type, cpu))
- break;
- }
- if (cpunode == NULL) {
- printk(KERN_ERR cpufreq: Can't find any CPU node\n);
- return -ENODEV;
- }
-
/* Lookup the cpuid eeprom node */
cpuid = of_find_node_by_path(/u3@0,f800/i2c@f8001000/cpuid@a0);
if (cpuid != NULL)
@@ -718,25 +693,32 @@ static int __init g5_pm72_cpufreq_init(struct device_node
*cpus)
static int __init g5_cpufreq_init(void)
{
- struct device_node *cpus;
+ struct device *cpu_dev;
+ struct device_node *cpunode;
int rc = 0;
- cpus = of_find_node_by_path(/cpus);
- if (cpus == NULL) {
- DBG(No /cpus node !\n);
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ pr_err(failed to get cpu device\n);
+ return -ENODEV;
+ }
+
+ /* Get first CPU node */
+ cpunode = of_node_get(cpu_dev-of_node);
+ if (cpunode == NULL) {
+ pr_err(cpufreq: Can't find any CPU node\n);
return -ENODEV;
}
if (of_machine_is_compatible(PowerMac7,2) ||
of_machine_is_compatible(PowerMac7,3) ||
of_machine_is_compatible(RackMac3,1))
- rc = g5_pm72_cpufreq_init(cpus);
+ rc = g5_pm72_cpufreq_init(cpunode);
#ifdef CONFIG_PMAC_SMU
else
- rc = g5_neo2_cpufreq_init(cpus);
+ rc = g5_neo2_cpufreq_init(cpunode);
#endif /* CONFIG_PMAC_SMU */
- of_node_put(cpus);
return rc;
}
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 01/15] of: add support for retrieving cpu node for a given logical cpu index
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.
It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.
This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.
It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/of/base.c | 66 ++
include/linux/of.h | 5 +
2 files changed, 71 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..363b8f9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node *np,
const char *name,
}
EXPORT_SYMBOL(of_get_property);
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecure specific.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns 1 if the physical identifier and the logical index correspond
+ * to the same cpu, 0 otherwise.
+ */
+int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+ return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialise the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecure specific and is built
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+ struct device_node *cpun, *cpus;
+ const u32 *cell;
+ u64 hwid;
+ int ac, prop_len;
+
+ cpus = of_find_node_by_path(/cpus);
+ if (WARN(!cpus, Missing cpus node, bailing out\n))
+ return NULL;
+
+ if (WARN_ON(of_property_read_u32(cpus, #address-cells, ac)))
+ ac = of_n_addr_cells(cpus);
+
+ for_each_child_of_node(cpus, cpun) {
+ if (of_node_cmp(cpun-type, cpu))
+ continue;
+ cell = of_get_property(cpun, reg, prop_len);
+ if (WARN(!cell, %s: missing reg property\n, cpun-full_name))
+ continue;
+
+ while (prop_len) {
+ hwid = of_read_number(cell, ac);
+ prop_len -= ac;
+ if (arch_match_cpu_phys_id(cpu, hwid))
+ return cpun;
+ }
+ }
+
+ return NULL;
+}
+
/** Checks if the given compat string matches one of the strings in
* the device's compatible property
*/
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..150b48e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -266,6 +266,7 @@ extern int of_device_is_available(const struct device_node
*device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
+extern struct device_node *of_get_cpu_node(int cpu);
#define for_each_property_of_node(dn, pp) \
for (pp = dn-properties; pp != NULL; pp = pp-next)
@@ -458,6 +459,10 @@ static inline const void *of_get_property(const struct
device_node *node,
{
return NULL;
}
+static inline struct device_node *of_get_cpu_node(int cpu)
+{
+ return NULL;
+}
static inline int of_property_read_u64(const struct device_node *np,
const char *propname, u64 *out_value)
--
1.8.1.2
___
devicetree-discuss mailing list
[RFC PATCH v2 06/15] drivers/bus: arm-cci: avoid parsing DT for cpu device nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Since the CPU device nodes can be retrieved using arch_of_get_cpu_node,
we can use it to avoid parsing the cpus node searching the cpu nodes and
mapping to logical index.
This patch removes parsing DT for cpu nodes by using of_get_cpu_node.
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/bus/arm-cci.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 7332889..7dd891c 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -122,17 +122,8 @@ EXPORT_SYMBOL_GPL(cci_ace_get_port);
static void __init cci_ace_init_ports(void)
{
- int port, ac, cpu;
- u64 hwid;
- const u32 *cell;
- struct device_node *cpun, *cpus;
-
- cpus = of_find_node_by_path(/cpus);
- if (WARN(!cpus, Missing cpus node, bailing out\n))
- return;
-
- if (WARN_ON(of_property_read_u32(cpus, #address-cells, ac)))
- ac = of_n_addr_cells(cpus);
+ int port, cpu;
+ struct device_node *cpun;
/*
* Port index look-up speeds up the function disabling ports by CPU,
@@ -141,18 +132,13 @@ static void __init cci_ace_init_ports(void)
* The stashed index array is initialized for all possible CPUs
* at probe time.
*/
- for_each_child_of_node(cpus, cpun) {
- if (of_node_cmp(cpun-type, cpu))
- continue;
- cell = of_get_property(cpun, reg, NULL);
- if (WARN(!cell, %s: missing reg property\n, cpun-full_name))
- continue;
-
- hwid = of_read_number(cell, ac);
- cpu = get_logical_index(hwid MPIDR_HWID_BITMASK);
+ for_each_possible_cpu(cpu) {
+ /* too early to use cpu-of_node */
+ cpun = of_get_cpu_node(cpu);
- if (cpu 0 || !cpu_possible(cpu))
+ if (WARN(!cpun, Missing cpu device node\n))
continue;
+
port = __cci_ace_get_port(cpun, ACE_PORT);
if (port 0)
continue;
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 12/15] cpufreq: arm_big_little: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/arm_big_little_dt.c | 39 -
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little_dt.c
b/drivers/cpufreq/arm_big_little_dt.c
index fd9e3ea..d2648d1 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -34,27 +34,19 @@
/* get cpu node with valid operating-points */
static struct device_node *get_cpu_node_with_valid_op(int cpu)
{
- struct device_node *np = NULL, *parent;
- int count = 0;
+ struct device *cpu_dev = get_cpu_device(cpu);
+ struct device_node *np;
- parent = of_find_node_by_path(/cpus);
- if (!parent) {
- pr_err(failed to find OF /cpus\n);
+ if (!cpu_dev) {
+ pr_err(failed to get cpu device\n);
return NULL;
}
-
- for_each_child_of_node(parent, np) {
- if (count++ != cpu)
- continue;
- if (!of_get_property(np, operating-points, NULL)) {
- of_node_put(np);
- np = NULL;
- }
-
- break;
+ np = of_node_get(cpu_dev-of_node);
+ if (!of_get_property(np, operating-points, NULL)) {
+ of_node_put(np);
+ np = NULL;
}
- of_node_put(parent);
return np;
}
@@ -63,11 +55,12 @@ static int dt_init_opp_table(struct device *cpu_dev)
struct device_node *np;
int ret;
- np = get_cpu_node_with_valid_op(cpu_dev-id);
- if (!np)
- return -ENODATA;
+ np = of_node_get(cpu_dev-of_node);
+ if (!np) {
+ pr_err(failed to find cpu%d node\n, cpu_dev-id);
+ return -ENOENT;
+ }
- cpu_dev-of_node = np;
ret = of_init_opp_table(cpu_dev);
of_node_put(np);
@@ -79,9 +72,11 @@ static int dt_get_transition_latency(struct device *cpu_dev)
struct device_node *np;
u32 transition_latency = CPUFREQ_ETERNAL;
- np = get_cpu_node_with_valid_op(cpu_dev-id);
- if (!np)
+ np = of_node_get(cpu_dev-of_node);
+ if (!np) {
+ pr_info(Failed to find cpu node. Use CPUFREQ_ETERNAL
transition latency\n);
return CPUFREQ_ETERNAL;
+ }
of_property_read_u32(np, clock-latency, transition_latency);
of_node_put(np);
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 04/15] ARM: topology: remove hwid/MPIDR dependency from cpu_capacity
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently the topology code computes cpu capacity and stores it in
the list along with hwid(which is MPIDR) as it parses the CPU nodes
in the device tree. This is required as it needs to be mapped to the
logical CPU later.
Since the CPU device nodes can be retrieved in the logical ordering
using DT/OF helpers, its possible to store cpu_capacity also in logical
ordering and avoid storing hwid for each entry.
This patch removes hwid by making use of of_get_cpu_node.
Cc: Russell King li...@arm.linux.org.uk
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
arch/arm/kernel/topology.c | 61 +++---
1 file changed, 19 insertions(+), 42 deletions(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index c5a5954..28ef27a 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -74,12 +74,8 @@ struct cpu_efficiency table_efficiency[] = {
{NULL, },
};
-struct cpu_capacity {
- unsigned long hwid;
- unsigned long capacity;
-};
-
-struct cpu_capacity *cpu_capacity;
+unsigned long *__cpu_capacity;
+#define cpu_capacity(cpu) __cpu_capacity[cpu]
unsigned long middle_capacity = 1;
@@ -100,15 +96,19 @@ static void __init parse_dt_topology(void)
unsigned long capacity = 0;
int alloc_size, cpu = 0;
- alloc_size = nr_cpu_ids * sizeof(struct cpu_capacity);
- cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
+ alloc_size = nr_cpu_ids * sizeof(*__cpu_capacity);
+ __cpu_capacity = kzalloc(alloc_size, GFP_NOWAIT);
- while ((cn = of_find_node_by_type(cn, cpu))) {
- const u32 *rate, *reg;
+ for_each_possible_cpu(cpu) {
+ const u32 *rate;
int len;
- if (cpu = num_possible_cpus())
- break;
+ /* too early to use cpu-of_node */
+ cn = of_get_cpu_node(cpu);
+ if (!cn) {
+ pr_err(missing device node for CPU %d\n, cpu);
+ continue;
+ }
for (cpu_eff = table_efficiency; cpu_eff-compatible; cpu_eff++)
if (of_device_is_compatible(cn, cpu_eff-compatible))
@@ -124,12 +124,6 @@ static void __init parse_dt_topology(void)
continue;
}
- reg = of_get_property(cn, reg, len);
- if (!reg || len != 4) {
- pr_err(%s missing reg property\n, cn-full_name);
- continue;
- }
-
capacity = ((be32_to_cpup(rate)) 20) * cpu_eff-efficiency;
/* Save min capacity of the system */
@@ -140,13 +134,9 @@ static void __init parse_dt_topology(void)
if (capacity max_capacity)
max_capacity = capacity;
- cpu_capacity[cpu].capacity = capacity;
- cpu_capacity[cpu++].hwid = be32_to_cpup(reg);
+ cpu_capacity(cpu) = capacity;
}
- if (cpu num_possible_cpus())
- cpu_capacity[cpu].hwid = (unsigned long)(-1);
-
/* If min and max capacities are equals, we bypass the update of the
* cpu_scale because all CPUs have the same capacity. Otherwise, we
* compute a middle_capacity factor that will ensure that the capacity
@@ -154,9 +144,7 @@ static void __init parse_dt_topology(void)
* SCHED_POWER_SCALE, which is the default value, but with the
* constraint explained near table_efficiency[].
*/
- if (min_capacity == max_capacity)
- cpu_capacity[0].hwid = (unsigned long)(-1);
- else if (4*max_capacity (3*(max_capacity + min_capacity)))
+ if (4*max_capacity (3*(max_capacity + min_capacity)))
middle_capacity = (min_capacity + max_capacity)
(SCHED_POWER_SHIFT+1);
else
@@ -170,23 +158,12 @@ static void __init parse_dt_topology(void)
* boot. The update of all CPUs is in O(n^2) for heteregeneous system but the
* function returns directly for SMP system.
*/
-void update_cpu_power(unsigned int cpu, unsigned long hwid)
+void update_cpu_power(unsigned int cpu)
{
- unsigned int idx = 0;
-
- /* look for the cpu's hwid in the cpu capacity table */
- for (idx = 0; idx num_possible_cpus(); idx++) {
- if (cpu_capacity[idx].hwid == hwid)
- break;
-
- if (cpu_capacity[idx].hwid == -1)
- return;
- }
-
- if (idx == num_possible_cpus())
+ if (!cpu_capacity(cpu))
return;
- set_power_scale(cpu, cpu_capacity[idx].capacity / middle_capacity);
+ set_power_scale(cpu, cpu_capacity(cpu) / middle_capacity);
printk(KERN_INFO CPU%u: update
[patch] spi/xilinx: signedness issue checking platform_get_irq()
xspi-irq is unsigned int so it's never less than zero. I have added
a cast.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
index fea815c..e5201fb 100644
--- a/drivers/spi/spi-xilinx.c
+++ b/drivers/spi/spi-xilinx.c
@@ -442,7 +442,7 @@ static int xilinx_spi_probe(struct platform_device *pdev)
xspi_init_hw(xspi);
xspi-irq = platform_get_irq(pdev, 0);
- if (xspi-irq 0) {
+ if ((int)xspi-irq 0) {
ret = xspi-irq;
goto put_master;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 10/15] cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Cc: Deepak Sikri deepak.si...@st.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/spear-cpufreq.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/spear-cpufreq.c b/drivers/cpufreq/spear-cpufreq.c
index c3efa7f..eb73c47 100644
--- a/drivers/cpufreq/spear-cpufreq.c
+++ b/drivers/cpufreq/spear-cpufreq.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
#include linux/clk.h
+#include linux/cpu.h
#include linux/cpufreq.h
#include linux/err.h
#include linux/init.h
@@ -218,12 +219,19 @@ static struct cpufreq_driver spear_cpufreq_driver = {
static int spear_cpufreq_driver_init(void)
{
struct device_node *np;
+ struct device *cpu_dev;
const struct property *prop;
struct cpufreq_frequency_table *freq_tbl;
const __be32 *val;
int cnt, i, ret;
- np = of_find_node_by_path(/cpus/cpu@0);
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ pr_err(failed to get cpu device\n);
+ return -ENODEV;
+ }
+
+ np = of_node_get(cpu_dev-of_node);
if (!np) {
pr_err(No cpu node found);
return -ENODEV;
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 17 Jul 2013, Pawel Moll wrote: On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote: If this is really miscelaneous code that really doesn't fit anywhere else, it should rather go into drivers/misc/ as a last resort. Interestingly enough drivers/misc was my first choice for all the vexpress stuff, but it wasn't received well... Anyway, the SPC driver as it is now seem to be a power management system driver. Maybe a relevant directory would be in place? Wouldn't PSCI belong there as well? (there are two psci.c files in arch/arm and arch/arm64, surprisingly similar ones ;-) The bottom line is: today it is not an MFD driver. But we know it will, right? So better save some churn by storing the initial code where it would end up anyway once complete. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH v2 08/15] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Acked-by: Shawn Guo shawn@linaro.org
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/cpufreq-cpu0.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..5b05c26 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -174,29 +174,17 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
static int cpu0_cpufreq_probe(struct platform_device *pdev)
{
- struct device_node *np, *parent;
+ struct device_node *np;
int ret;
- parent = of_find_node_by_path(/cpus);
- if (!parent) {
- pr_err(failed to find OF /cpus\n);
- return -ENOENT;
- }
-
- for_each_child_of_node(parent, np) {
- if (of_get_property(np, operating-points, NULL))
- break;
- }
+ cpu_dev = pdev-dev;
+ np = of_node_get(cpu_dev-of_node);
if (!np) {
pr_err(failed to find cpu0 node\n);
- ret = -ENOENT;
- goto out_put_parent;
+ return -ENOENT;
}
- cpu_dev = pdev-dev;
- cpu_dev-of_node = np;
-
cpu_reg = devm_regulator_get(cpu_dev, cpu0);
if (IS_ERR(cpu_reg)) {
/*
@@ -269,15 +257,12 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
}
of_node_put(np);
- of_node_put(parent);
return 0;
out_free_table:
opp_free_cpufreq_table(cpu_dev, freq_table);
out_put_node:
of_node_put(np);
-out_put_parent:
- of_node_put(parent);
return ret;
}
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote: On Wed, 17 Jul 2013, Pawel Moll wrote: On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote: If this is really miscelaneous code that really doesn't fit anywhere else, it should rather go into drivers/misc/ as a last resort. Interestingly enough drivers/misc was my first choice for all the vexpress stuff, but it wasn't received well... Anyway, the SPC driver as it is now seem to be a power management system driver. Maybe a relevant directory would be in place? Wouldn't PSCI belong there as well? (there are two psci.c files in arch/arm and arch/arm64, surprisingly similar ones ;-) The bottom line is: today it is not an MFD driver. But we know it will, right? So better save some churn by storing the initial code where it would end up anyway once complete. Not in that form, no. The code living in mfd will just register mfd_cells while functional parts are going to live elsewhere. This is how I understand what Samuel asked me to do and that's what is happening to vexpress-sysreg now. Paweł ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
On Wed, Jul 17, 2013 at 13:07 +0100, Mark Brown wrote: On Wed, Jul 17, 2013 at 01:22:29PM +0200, Gerhard Sittig wrote: On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote: On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote: sprintf(name, psc%d_mclk, master-bus_num); spiclk = clk_get(master-dev, name); - clk_enable(spiclk); + clk_prepare_enable(spiclk); mps-mclk = clk_get_rate(spiclk); clk_put(spiclk); This code is *clearly* buggy and should be fixed rather than papered over. Not only is there no matching put the driver is also dropping the reference to the clock rather than holding on to it while it's in use. This code refers to the driver's original condition, right? I agree that the driver has been suffering from incomplete clock handling since it was born three years ago. And that this issue shall get addressed. The question is just whether it needs to be part of this series which has a different focus. This is a pretty long e-mail. It'd probably have taken less time to fix the issues than to reply to the e-mail... but anyway. [ this is meta stuff, technical details are after the next quotation ] Not quite. Please consider that careful submission is as expensive as thorough review is, and that a lot of work is done before v1 gets submitted, which you may not always notice from looking at a concentrated series that may no longer suggest how much it took to get there (especially when prepared carefully). As mentioned before I did not question the need to fix issues as they get identified. I just asked whether reworking the serial driver is in the scope of this series which provides a different clock driver implementation for the platform. To me these two things are orthogonal, while I did promise to see how I can address your concerns. Let's provide the technical information you need to judge the quality of the submission and see why it shall be acceptable: A big part of the issue with the state of the driver is that there's obvious clock API abuse going on that isn't corrected here - the main one is that the sprintf() for the clock name is a fairly clear warning sign, the driver should be using a fixed value there. This raises a warning flag for me about the quality of the common clock API implementation that's being sent and/or the potential for bugs to be noticed with the common clock framework. I'd not expect this code to actually work, and looking at the rest of the series I don't see how it does since I can't see what forces the name. Why the code does work: OK, here is why the driver keeps its state throughout the set and is operational as good or as bad as it was before: The sprintf() in the SPI driver used to construct a name which includes the PSC index. This applies to the UART driver as well, as they both use the PSC controller hardware to implement their serial communication. The corresponding clock name was found in the previous PPC_CLOCK implementation since the clock driver provided those names which include the PSC index (fixed strings in a table). The initial COMMON_CLK implementation in part 09/24 registers clkdev items for compatibility during migration. The string isn't greppable since it's constructed by the preprocessor in the MCLK data setup, see the MCLK_SETUP_DATA_PSC() macro. Part 13/24 adjusts the SPI driver to no longer construct a name, but instead use a fixed string after OF based clock lookup became available. This shall meet your expectation and simplifies the client side. Part 15/24 does the same for the UART driver. Part 16/24 removes the clkdev registration in the clock driver after both the UART and SPI clients switched to OF clock lookups. At this stage things are the way you would expect: The client uses a fixed string in the lookup, while lookup occurs via device tree, and instances are supported without the clients' constructing something based on a component index. Remaining issues are not with the common clock support of the platform, but in the serial driver and are identical to the previous (actually: the initial) status. While we agree on the existance of the remaining issue and the desire to address it. Just not on which context that fix shall be done in. The series' status and perspective: The UART and SPI drivers did work before, while it's true that clock handling wasn't complete (in non-fatal ways). This has been the case in the past, and has been identified just now. The serial drivers are kept operational during migration, and still are operational after the series. But now they use common clock and OF lookups, which is an improvement for the platform in my eyes. It's true that the status of the serial driver isn't improved with the series -- but it isn't degraded either, while (additional) breakage actively gets prevented. Now let me see how I can improve the SPI driver with regard to overall
Re: [RFC PATCH v2 01/15] of: add support for retrieving cpu node for a given logical cpu index
On Wed, 17 Jul 2013, sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.
It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.
This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.
It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/of/base.c | 66
++
include/linux/of.h | 5 +
2 files changed, 71 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..363b8f9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node
*np, const char *name,
}
EXPORT_SYMBOL(of_get_property);
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecure specific.
Typo.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns 1 if the physical identifier and the logical index correspond
+ * to the same cpu, 0 otherwise.
+ */
+int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
Please use a bool return type, and use true/false rather than 1/0 in the
comment.
+{
+ return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialise the of_node in
Typo.
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecure specific and is built
Typo.
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+ struct device_node *cpun, *cpus;
+ const u32 *cell;
+ u64 hwid;
+ int ac, prop_len;
+
+ cpus = of_find_node_by_path(/cpus);
+ if (WARN(!cpus, Missing cpus node, bailing out\n))
+ return NULL;
+
+ if (WARN_ON(of_property_read_u32(cpus, #address-cells, ac)))
+ ac = of_n_addr_cells(cpus);
+
+ for_each_child_of_node(cpus, cpun) {
+ if (of_node_cmp(cpun-type, cpu))
+ continue;
+ cell = of_get_property(cpun, reg, prop_len);
+ if (WARN(!cell, %s: missing reg property\n, cpun-full_name))
+ continue;
+
+ while (prop_len) {
+ hwid = of_read_number(cell, ac);
+ prop_len -= ac;
+ if (arch_match_cpu_phys_id(cpu, hwid))
+ return cpun;
+ }
+ }
+
+ return NULL;
+}
+
/** Checks if the given compat string matches one of the strings in
* the device's compatible property
*/
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..150b48e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -266,6 +266,7 @@ extern int of_device_is_available(const struct
device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
+extern struct device_node *of_get_cpu_node(int cpu);
#define for_each_property_of_node(dn, pp) \
for (pp = dn-properties; pp != NULL; pp = pp-next)
@@ -458,6 +459,10 @@ static inline const void *of_get_property(const struct
device_node *node,
{
return NULL;
}
+static inline struct device_node *of_get_cpu_node(int cpu)
+{
+ return NULL;
+}
static inline int
[PATCH v5] Input: sysrq - DT binding for key sequence
From: Mathieu J. Poirier mathieu.poir...@linaro.org
Adding a simple device tree binding for the specification of key sequences.
Definition of the keys found in the sequence are located in
'include/uapi/linux/input.h'.
For the sysrq driver, holding the sequence of keys down for a specific amount
of time
will reset the system.
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
---
changes for v5:
- Corrected error in binding definition.
- Using helper macro to fetch the key sequence.
- Removing white space.
---
.../devicetree/bindings/input/input-reset.txt | 34
drivers/tty/sysrq.c| 37 ++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/input-reset.txt
diff --git a/Documentation/devicetree/bindings/input/input-reset.txt
b/Documentation/devicetree/bindings/input/input-reset.txt
new file mode 100644
index 000..c69390c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/input-reset.txt
@@ -0,0 +1,34 @@
+Input: sysrq reset sequence
+
+A simple binding to represent a set of keys as described in
+include/uapi/linux/input.h. This is to communicate a
+sequence of keys to the sysrq driver. Upon holding the keys
+for a specified amount of time (if specified) the system is
+sync'ed and reset.
+
+Key sequences are global to the system but all the keys in a
+set must be coming from the same input device.
+
+The /chosen node should contain a 'linux,sysrq-reset-seq' child
+node to define a set of keys.
+
+Required property:
+sysrq-reset-seq: array of keycodes
+
+Optional property:
+timeout-ms: duration keys must be pressed together in milliseconds
+before generating a sysrq
+
+Example:
+
+ chosen {
+linux,sysrq-reset-seq {
+keyset = 0x03
+ 0x04
+ 0x0a;
+timeout-ms = 3000;
+};
+ };
+
+Would represent KEY_2, KEY_3 and KEY_9.
+
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index b51c154..ed8f00f 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -44,6 +44,7 @@
#include linux/uaccess.h
#include linux/moduleparam.h
#include linux/jiffies.h
+#include linux/of.h
#include asm/ptrace.h
#include asm/irq_regs.h
@@ -671,6 +672,34 @@ static void sysrq_detect_reset_sequence(struct sysrq_state
*state,
}
}
+static void sysrq_of_get_keyreset_config(void)
+{
+ u32 key;
+ struct device_node *np;
+ struct property *prop;
+ const __be32 *p;
+
+ np = of_find_node_by_path(/chosen/linux,sysrq-reset-seq);
+ if (!np) {
+ pr_debug(No sysrq node found);
+ return;
+ }
+
+ /* reset in case a __weak definition was present */
+ sysrq_reset_seq_len = 0;
+
+ of_property_for_each_u32(np, keyset, prop, p, key) {
+ if ((key == KEY_RESERVED || key KEY_MAX) ||
+ (sysrq_reset_seq_len == SYSRQ_KEY_RESET_MAX))
+ break;
+
+ sysrq_reset_seq[sysrq_reset_seq_len++] = (unsigned short)key;
+ }
+
+ /* get reset timeout if any */
+ of_property_read_u32(np, timeout-ms, sysrq_reset_downtime_ms);
+}
+
static void sysrq_reinject_alt_sysrq(struct work_struct *work)
{
struct sysrq_state *sysrq =
@@ -903,6 +932,7 @@ static inline void sysrq_register_handler(void)
int error;
int i;
+ /* first check if a __weak interface was instantiated */
for (i = 0; i ARRAY_SIZE(sysrq_reset_seq); i++) {
key = platform_sysrq_reset_seq[i];
if (key == KEY_RESERVED || key KEY_MAX)
@@ -911,6 +941,13 @@ static inline void sysrq_register_handler(void)
sysrq_reset_seq[sysrq_reset_seq_len++] = key;
}
+ /*
+* DT configuration takes precedence over anything
+* that would have been defined via the __weak
+* interface
+*/
+ sysrq_of_get_keyreset_config();
+
error = input_register_handler(sysrq_handler);
if (error)
pr_err(Failed to register input handler, error %d, error);
--
1.8.1.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 01/15] of: add support for retrieving cpu node for a given logical cpu index
On 07/17/2013 09:06 AM, sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.
It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.
This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.
It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
One comment below, but otherwise for patches 1-4, 8 and 9:
Acked-by: Rob Herring rob.herr...@calxeda.com
Also, patch 3 needs to come before patch 2 or the matching will be wrong
if patch 3 is not applied.
---
drivers/of/base.c | 66
++
include/linux/of.h | 5 +
2 files changed, 71 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..363b8f9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node
*np, const char *name,
}
EXPORT_SYMBOL(of_get_property);
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecure specific.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns 1 if the physical identifier and the logical index correspond
+ * to the same cpu, 0 otherwise.
+ */
+int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+ return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialise the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecure specific and is built
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+ struct device_node *cpun, *cpus;
+ const u32 *cell;
+ u64 hwid;
+ int ac, prop_len;
+
+ cpus = of_find_node_by_path(/cpus);
+ if (WARN(!cpus, Missing cpus node, bailing out\n))
What happens on a system with no /cpus nodes? Seems like this is another
case of adding new warnings to existing working systems.
I'd replace all the WARN's with a single pr_warn on any errors below.
For missing /cpus, I would just silently return.
Rob
+ return NULL;
+
+ if (WARN_ON(of_property_read_u32(cpus, #address-cells, ac)))
+ ac = of_n_addr_cells(cpus);
+
+ for_each_child_of_node(cpus, cpun) {
+ if (of_node_cmp(cpun-type, cpu))
+ continue;
+ cell = of_get_property(cpun, reg, prop_len);
+ if (WARN(!cell, %s: missing reg property\n, cpun-full_name))
+ continue;
+
+ while (prop_len) {
+ hwid = of_read_number(cell, ac);
+ prop_len -= ac;
+ if (arch_match_cpu_phys_id(cpu, hwid))
+ return cpun;
+ }
+ }
+
+ return NULL;
+}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 1/2] ARM: dts: twl: Add GPADC data to device tree
On 07/17/2013 04:33 PM, Sergei Shtylyov wrote:
Hello.
On 17-07-2013 15:12, Oleksandr Kozaruk wrote:
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..322aa8e 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = ti,twl6030-pwmled;
#pwm-cells = 2;
};
+
+adc: twl6030_gpadc {
I was talking about the device name, not label. The twl6030_gpadc part.
The compatible property should also be: 'twl6030-gpadc' instead of
'twl6030_gpadc' and you need to add documentation for it.
- Lars
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 11/15] cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
On Wed, Jul 17, 2013 at 03:06:20PM +0100, sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu-of_node instead.
Cc: Andrew Lunn and...@lunn.ch
Cc: Jason Cooper ja...@lakedaemon.net
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
---
drivers/cpufreq/kirkwood-cpufreq.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
b/drivers/cpufreq/kirkwood-cpufreq.c
index c233ea6..18aa3eb 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++ b/drivers/cpufreq/kirkwood-cpufreq.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/clk.h
#include linux/clk-provider.h
+#include linux/cpu.h
#include linux/cpufreq.h
#include linux/of.h
#include linux/platform_device.h
@@ -165,6 +166,7 @@ static struct cpufreq_driver kirkwood_cpufreq_driver = {
static int kirkwood_cpufreq_probe(struct platform_device *pdev)
{
struct device_node *np;
+ struct device *cpu_dev;
struct resource *res;
int err;
@@ -175,9 +177,17 @@ static int kirkwood_cpufreq_probe(struct platform_device
*pdev)
if (IS_ERR(priv.base))
return PTR_ERR(priv.base);
- np = of_find_node_by_path(/cpus/cpu@0);
- if (!np)
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev) {
+ dev_err(pdev-dev, failed to get cpu device\n);
return -ENODEV;
+ }
+
+ np = of_node_get(cpu_dev-of_node);
+ if (!np) {
+ dev_err(pdev-dev, failed to get cpu device node\n);
+ return -ENODEV;
+ }
Hi Sudeep
Are we not going a bit backwards here? You are replacing two lines
with 10 lines.
How about putting these 10 lines into some helper,
of_get_cpu_device()? It would be useful for spear, kirkwood and
imx6q, and maybe others.
Thanks
Andrew
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/17/2013 03:45 PM, Oleksandr Kozaruk wrote:
On Mon, Jul 15, 2013 at 01:33:53PM +0200, Lars-Peter Clausen wrote:
On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
[...]
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ twl6030_gpadc_irq_handler,
+ IRQF_ONESHOT, twl6030_gpadc, gpadc);
You access memory in the interrupt handler which is freed before the
interrupt
handler is freed.
Thanks for pointing this. devm_* will free memory for irq after the driver
is removed and memory for the device is freed. I took me awhile to
understand
this. Is there going to be something like devm_iio_device_alloc? whould
it be helpfull?
Yes, I think it certainly makes sense to add a devm_iio_device_alloc(), care
to send a patch?
Anything like this? (of course it's not a patch)
No. I think you can for example use devm_regulator_get() as a template. But
instead of regulator_get() and regulator_put() use iio_device_alloc() and
iio_device_free().
struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
{
struct iio_dev *indio_dev;
size_t alloc_size;
alloc_size = sizeof(struct iio_dev);
if (sizeof_priv) {
alloc_size = ALIGN(alloc_size, IIO_ALIGN);
alloc_size += sizeof_priv;
}
/* ensure 32-byte alignment of whole construct ? */
alloc_size += IIO_ALIGN - 1;
indio_dev = devm_kzalloc(dev, alloc_size, GFP_KERNEL);
if (indio_dev) {
indio_dev-dev.groups = indio_dev-groups;
indio_dev-dev.type = iio_device_type;
indio_dev-dev.bus = iio_bus_type;
device_initialize(indio_dev-dev);
dev_set_drvdata(indio_dev-dev, (void *)indio_dev);
mutex_init(indio_dev-mlock);
mutex_init(indio_dev-info_exist_lock);
INIT_LIST_HEAD(indio_dev-channel_attr_list);
indio_dev-id = ida_simple_get(iio_ida, 0, 0, GFP_KERNEL);
if (indio_dev-id 0) {
/* cannot use a dev_err as the name isn't available */
printk(KERN_ERR Failed to get id\n);
kfree(dev);
return NULL;
}
dev_set_name(indio_dev-dev, iio:device%d, indio_dev-id);
INIT_LIST_HEAD(indio_dev-buffer_list);
}
return indio_dev;
}
EXPORT_SYMBOL(devm_iio_device_alloc);
Regards,
OK
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Add dynamic active/idle pin states for uart3/4 which will be applied when uart3/4 state is switched from active to idle and back by Runtime PM or during system suspend. This is good for testing code, but should not be merged because omap4 has the iopad wake-ups available for uarts. So those can be always enabled. --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -181,18 +181,40 @@ pinctrl-single,pins = 0x100 (PIN_INPUT_PULLUP | MUX_MODE0)/* uart3_cts_rctx.uart3_cts_rctx */ 0x102 (PIN_OUTPUT | MUX_MODE0) /* uart3_rts_sd.uart3_rts_sd */ - 0x104 (PIN_INPUT | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ 0x106 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx */ ; }; This just need to become: pinctrl-single,pins = ... 0x104 (WAKEUP_EN | PIN_INPUT_MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ ... ; interrupts = GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH; }; And so on. For am33xx you need to remux things to GPIO for the wake-up events, so you should maybe test on that instead. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch] spi/xilinx: signedness issue checking platform_get_irq()
On Wed, Jul 17, 2013 at 09:03:53AM -0600, Stephen Warren wrote: On 07/17/2013 06:26 AM, Dan Carpenter wrote: xspi-irq is unsigned int so it's never less than zero. I have added a cast. Um. Doesn't this just hide a warning, not solve the problem? If the value can't be negative, so the if condition never fires, then the cast won't change that... No. It fixes the problem but Mark is right that it's ugly. Sorry for that. I will resend. regards, dan carpenter ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[patch v2] spi/xilinx: signedness issue checking platform_get_irq()
In xilinx_spi_probe() we use xspi-irq to store negative error codes so
it has to be signed. We weren't going to use the upper bit any way so
this is fine.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
v2: The first version introduced an ugly cast. Sorry for that.
diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
index fea815c..0f4a093 100644
--- a/drivers/spi/spi-xilinx.c
+++ b/drivers/spi/spi-xilinx.c
@@ -82,7 +82,7 @@ struct xilinx_spi {
struct completion done;
void __iomem*regs; /* virt. address of the control registers */
- u32 irq;
+ int irq;
u8 *rx_ptr; /* pointer in the Tx buffer */
const u8 *tx_ptr; /* pointer in the Rx buffer */
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod framework. After switching to DT-boot the pinctrl handling was dropped from hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html) But this is not right for OMAP2+ SoC where real IPs state is controlled by omap_device core which enables/disables modules clocks actually. I'm not convinced we should try to handle this in a generic way as only some devices need dynamic remuxing of some pins. For example, if OMAP I2C driver will handle pinctrl state during system wide suspend the following issue may occure: - suspend_noirq - I2C device can be still active because of PM auto-suspend |-_od_suspend_noirq |- omap_i2c_suspend_noirq |- PINs state set to SLEEP |- pm_generic_runtime_suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE --- *oops* PINs state is IDLE and not SLEEP |- omap_device_idle() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) And in this example you are assuming that you need separate idle and sleep states, which is not true at least for most cases I've seen. It is possible that am33xx needs separate idle and sleep states, but most likely only for some pins. For omap[345] we can get away with just the default state for most cases. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] pinctrl: rollback check for !dev-pins in pinctrl_pm_select*() APIs
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: The pinctrl support in Device core assumed to be optional - so, It's valid case, when there are no definition for default device's pinctrl states in DT at all (default, active, idle, sleep). And in this case dev-pins == NULL and pinctrl_pm_select*() API should return 0 always. Now the checks for !dev-pins have been removed from pinctrl_pm_select*() API mistakenly by the patch pinctrl: Remove duplicate code in pinctrl_pm_select_state functions http://www.spinics.net/lists/arm-kernel/msg258829.html Hence, rollback these checks in in pinctrl_pm_select*() APIs. Thanks, it's best that I fold this fix into my patch as it has not been committed yet. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v2 01/15] of: add support for retrieving cpu node for a given logical cpu index
On 17/07/13 15:50, Rob Herring wrote:
On 07/17/2013 09:06 AM, sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplication and in some
cases even incorrect logic.
It's better to consolidate them by adding support for getting cpu
device node for a given logical cpu index in DT core library. However
logical to physical index mapping can be architecture specific.
This patch adds of_get_cpu_node to retrieve a cpu device node for a
given logical cpu index. The default matching of the physical id to the
logical cpu index can be overridden by architecture specific code.
It is recommended to use these helper function only in pre-SMP/early
initialisation stages to retrieve CPU device node pointers in logical
ordering. Once the cpu devices are registered, it can be retrieved easily
from cpu device of_node which avoids unnecessary parsing and matching.
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
One comment below, but otherwise for patches 1-4, 8 and 9:
Acked-by: Rob Herring rob.herr...@calxeda.com
Also, patch 3 needs to come before patch 2 or the matching will be wrong
if patch 3 is not applied.
Ah, correct will fix it in next version.
---
drivers/of/base.c | 66
++
include/linux/of.h | 5 +
2 files changed, 71 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5c54279..363b8f9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -230,6 +230,72 @@ const void *of_get_property(const struct device_node
*np, const char *name,
}
EXPORT_SYMBOL(of_get_property);
+/*
+ * arch_match_cpu_phys_id - Match the given logical CPU and physical id
+ *
+ * @cpu: logical index of a cpu
+ * @phys_id: physical identifier of a cpu
+ *
+ * CPU logical to physical index mapping is architecure specific.
+ * However this __weak function provides a default match of physical
+ * id to logical cpu index.
+ *
+ * Returns 1 if the physical identifier and the logical index correspond
+ * to the same cpu, 0 otherwise.
+ */
+int __weak arch_match_cpu_phys_id(int cpu, u64 phys_id)
+{
+return (u32)phys_id == cpu;
+}
+
+/**
+ * of_get_cpu_node - Get device node associated with the given logical CPU
+ *
+ * @cpu: CPU number(logical index) for which device node is required
+ *
+ * The main purpose of this function is to retrieve the device node for the
+ * given logical CPU index. It should be used to intialise the of_node in
+ * cpu device. Once of_node in cpu device is populated, all the further
+ * references can use that instead.
+ *
+ * CPU logical to physical index mapping is architecure specific and is
built
+ * before booting secondary cores. This function uses arch_match_cpu_phys_id
+ * which can be overridden by architecture specific implementation.
+ *
+ * Returns a node pointer for the logical cpu if found, else NULL.
+ */
+struct device_node *of_get_cpu_node(int cpu)
+{
+struct device_node *cpun, *cpus;
+const u32 *cell;
+u64 hwid;
+int ac, prop_len;
+
+cpus = of_find_node_by_path(/cpus);
+if (WARN(!cpus, Missing cpus node, bailing out\n))
What happens on a system with no /cpus nodes? Seems like this is another
case of adding new warnings to existing working systems.
I'd replace all the WARN's with a single pr_warn on any errors below.
For missing /cpus, I would just silently return.
Ah, forgot recent discussions on this, will fix it.
Regards,
Sudeep
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch] spi/xilinx: signedness issue checking platform_get_irq()
On 07/17/2013 06:26 AM, Dan Carpenter wrote: xspi-irq is unsigned int so it's never less than zero. I have added a cast. Um. Doesn't this just hide a warning, not solve the problem? If the value can't be negative, so the if condition never fires, then the cast won't change that... ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC FINAL v5] media: OF: add sync-on-green-active property
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- Changes for v5: 1: Changed description for sync-on-green-active property in documentation file as suggested by Sylwester. Changes for v4: 1: Fixed review comments pointed by Sylwester. Changes for v3: 1: Fixed review comments pointed by Laurent and Sylwester. RFC v2 https://patchwork.kernel.org/patch/2578091/ RFC V1 https://patchwork.kernel.org/patch/2572341/ .../devicetree/bindings/media/video-interfaces.txt |2 ++ drivers/media/v4l2-core/v4l2-of.c |4 include/media/v4l2-mediabus.h |2 ++ 3 files changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..ce719f8 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -88,6 +88,8 @@ Optional endpoint properties - field-even-active: field signal level during the even field data transmission. - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock signal. +- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for + LOW/HIGH respectively. - data-lanes: an array of physical data lane indexes. Position of an entry determines the logical lane number, while the value of an entry indicates physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..5c4c9f0 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,10 @@ 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_property_read_u32(node, sync-on-green-active, v)) + flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH : + V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..d47eb81 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_VIDEO_SOG_ACTIVE_HIGH(1 12) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch] spi/xilinx: signedness issue checking platform_get_irq()
On Wed, Jul 17, 2013 at 03:26:38PM +0300, Dan Carpenter wrote: xspi-irq is unsigned int so it's never less than zero. I have added a cast. Why is this better than changing irq to a signed type? signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 17 Jul 2013, Pawel Moll wrote: On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote: On Wed, 17 Jul 2013, Pawel Moll wrote: On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote: If this is really miscelaneous code that really doesn't fit anywhere else, it should rather go into drivers/misc/ as a last resort. Interestingly enough drivers/misc was my first choice for all the vexpress stuff, but it wasn't received well... Anyway, the SPC driver as it is now seem to be a power management system driver. Maybe a relevant directory would be in place? Wouldn't PSCI belong there as well? (there are two psci.c files in arch/arm and arch/arm64, surprisingly similar ones ;-) The bottom line is: today it is not an MFD driver. But we know it will, right? So better save some churn by storing the initial code where it would end up anyway once complete. Not in that form, no. The code living in mfd will just register mfd_cells while functional parts are going to live elsewhere. This is how I understand what Samuel asked me to do and that's what is happening to vexpress-sysreg now. A drivers/pm/ or drivers/power/ could be created, but that implies sort of a more defined subsystem with a common API and the SPC code doesn't fit that as it is only providing services to actual drivers on top of it. The sanest location at this point might simply be drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c depending on whether or not more such driver glue is expected in the vexpress future. No point putting arm in the path, especially if this is later reused on arm64. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC FINAL v5] media: OF: add sync-on-green-active property
On 07/17/2013 05:47 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Thanks Prabhakar, it looks good to me. Just a side note, the 'From' tag above isn't needed. It wasn't added automatically, was it ? Unless there are comments from others I think this patch should be merged together with the users of this new property. Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Regards, Sylwester --- Changes for v5: 1: Changed description for sync-on-green-active property in documentation file as suggested by Sylwester. Changes for v4: 1: Fixed review comments pointed by Sylwester. Changes for v3: 1: Fixed review comments pointed by Laurent and Sylwester. RFC v2 https://patchwork.kernel.org/patch/2578091/ RFC V1 https://patchwork.kernel.org/patch/2572341/ .../devicetree/bindings/media/video-interfaces.txt |2 ++ drivers/media/v4l2-core/v4l2-of.c |4 include/media/v4l2-mediabus.h |2 ++ 3 files changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..ce719f8 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -88,6 +88,8 @@ Optional endpoint properties - field-even-active: field signal level during the even field data transmission. - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock signal. +- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for + LOW/HIGH respectively. - data-lanes: an array of physical data lane indexes. Position of an entry determines the logical lane number, while the value of an entry indicates physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..5c4c9f0 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,10 @@ 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_property_read_u32(node, sync-on-green-active, v)) + flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH : + V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..d47eb81 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_VIDEO_SOG_ACTIVE_HIGH (1 12) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ -- Sylwester Nawrocki Samsung RD Institute Poland ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3] media: i2c: tvp7002: add OF support
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the tvp7002 driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
This patch depends on https://patchwork.kernel.org/patch/2828800/
Changes for v3:
1: Fixed review comments pointed by Sylwester.
.../devicetree/bindings/media/i2c/tvp7002.txt | 43 +
drivers/media/i2c/tvp7002.c| 67 ++--
2 files changed, 103 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
new file mode 100644
index 000..744125f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
@@ -0,0 +1,43 @@
+* Texas Instruments TV7002 video decoder
+
+The TVP7002 device supports digitizing of video and graphics signal in RGB and
+YPbPr color space.
+
+Required Properties :
+- compatible : Must be ti,tvp7002
+
+- hsync-active: HSYNC Polarity configuration for endpoint.
+
+- vsync-active: VSYNC Polarity configuration for endpoint.
+
+- pclk-sample: Clock polarity of the endpoint.
+
+- sync-on-green-active: Active state of Sync-on-green signal property of the
+ endpoint, 0/1 for normal/inverted operation respectively.
+
+- field-even-active: Active-high Field ID polarity of the endpoint.
+
+For further reading of port node refer Documentation/devicetree/bindings/media/
+video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ tvp7002@5c {
+ compatible = ti,tvp7002;
+ reg = 0x5c;
+
+ port {
+ tvp7002_1: endpoint {
+ hsync-active = 1;
+ vsync-active = 1;
+ pclk-sample = 0;
+ sync-on-green-active = 1;
+ field-even-active = 0;
+ };
+ };
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index f6b1f3f..24a08fa 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -35,6 +35,8 @@
#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-ctrls.h
+#include media/v4l2-of.h
+
#include tvp7002_reg.h
MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
@@ -943,6 +945,48 @@ static const struct v4l2_subdev_ops tvp7002_ops = {
.pad = tvp7002_pad_ops,
};
+static struct tvp7002_config *
+tvp7002_get_pdata(struct i2c_client *client)
+{
+ struct v4l2_of_endpoint bus_cfg;
+ struct tvp7002_config *pdata;
+ struct device_node *endpoint;
+ unsigned int flags;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+ return client-dev.platform_data;
+
+ endpoint = v4l2_of_get_next_endpoint(client-dev.of_node, NULL);
+ if (!endpoint)
+ return NULL;
+
+ pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ 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;
+
+ if (flags V4L2_MBUS_FIELD_EVEN_HIGH)
+ pdata-fid_polarity = 1;
+
+ if (flags V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH)
+ pdata-sog_polarity = 1;
+
+done:
+ of_node_put(endpoint);
+ return pdata;
+}
+
/*
* tvp7002_probe - Probe a TVP7002 device
* @c: ptr to i2c_client struct
@@ -954,32 +998,32 @@ static const struct v4l2_subdev_ops tvp7002_ops = {
*/
static int tvp7002_probe(struct i2c_client *c, const struct i2c_device_id *id)
{
+ struct tvp7002_config *pdata = tvp7002_get_pdata(c);
struct v4l2_subdev *sd;
struct tvp7002 *device;
struct v4l2_dv_timings timings;
int polarity_a;
int polarity_b;
u8 revision;
-
int error;
+ if (pdata == NULL) {
+ dev_err(c-dev, No platform data\n);
+ return -EINVAL;
+ }
+
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(c-adapter,
I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
return -EIO;
- if (!c-dev.platform_data) {
- v4l_err(c, No platform data!!\n);
- return -ENODEV;
- }
-
device = devm_kzalloc(c-dev, sizeof(struct tvp7002), GFP_KERNEL);
if (!device)
Re: [PATCH RFC FINAL v5] media: OF: add sync-on-green-active property
Hi Sylwester, On Wed, Jul 17, 2013 at 9:50 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 07/17/2013 05:47 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Thanks Prabhakar, it looks good to me. Just a side note, the 'From' tag above isn't needed. It wasn't added automatically, was it ? Yes this was added automatically. Unless there are comments from others I think this patch should be merged together with the users of this new property. Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Thanks for the Ack. -- Regards, Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] media: i2c: tvp7002: add OF support
On 07/17/2013 06:20 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add OF support for the tvp7002 driver. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- This patch depends on https://patchwork.kernel.org/patch/2828800/ Changes for v3: 1: Fixed review comments pointed by Sylwester. .../devicetree/bindings/media/i2c/tvp7002.txt | 43 + drivers/media/i2c/tvp7002.c| 67 ++-- 2 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode 100644 index 000..744125f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt @@ -0,0 +1,43 @@ +* Texas Instruments TV7002 video decoder + +The TVP7002 device supports digitizing of video and graphics signal in RGB and +YPbPr color space. + +Required Properties : +- compatible : Must be ti,tvp7002 + +- hsync-active: HSYNC Polarity configuration for endpoint. + +- vsync-active: VSYNC Polarity configuration for endpoint. I woudn't refer to endpoint here, perhaps to the specific hardware bus instead ? So it is clear what part of the device it refers to ? +- pclk-sample: Clock polarity of the endpoint. This description is not very useful, my feeling is that this property is better described in video-interfaces.txt. +- sync-on-green-active: Active state of Sync-on-green signal property of the + endpoint, 0/1 for normal/inverted operation respectively. + +- field-even-active: Active-high Field ID polarity of the endpoint. I find it hard to understand what this property is about exactly. Not sure if you need to repeat detailed description of the signal polarity properties. Perhaps its sufficient to list which properties are relevant for this device, but I'm not opposed to having supplementary description here. I would just make it more specific to the TVP7002 chip. Also please note that only 'compatible' property is required, all other are optional. And it probably makes sense to specify what are default values for each property when it is not specified. Otherwise the patch looks good. -- Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 8/9] ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO4 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied.
So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.
Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3ff5874..ef05676 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -397,10 +397,10 @@
ldo7_reg: ldo7 {
/* VDD_VPP: vpp1 */
regulator-name = ldo7;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 200;
+ regulator-max-microvolt = 200;
+ /* Only for efuse reprograming! */
+ status = disabled;
};
ldo8_reg: ldo8 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/9] ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.
Further, vdda_lli is supposed to be 1.5V and not 3V.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a55f4d8..c6d560b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -362,10 +362,11 @@
ldo3_reg: ldo3 {
/* VDDAPHY_MDM: vdda_lli */
regulator-name = ldo3;
- regulator-min-microvolt = 300;
- regulator-max-microvolt = 300;
- regulator-always-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
regulator-boot-on;
+ /* Only if Modem is used */
+ status = disabled;
};
ldo4_reg: ldo4 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/9] ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 1550d6a..3ff5874 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -388,8 +388,8 @@
ldo6_reg: ldo6 {
/* VDDS_1V2_WKUP: hsic/ldo_emu_wkup */
regulator-name = ldo6;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
regulator-always-on;
regulator-boot-on;
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/9] ARM: dts: omap5-uevm: fixup wrong regulator configuration
Due to wrong older revision of documentation used as reference, we seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This series is based power tree on production board 750-2628-XXX platform. Unfortunately, the wrong voltages may be detrimental to OMAP5 as they supply hardware blocks at voltages that are out of specification. Also available at: based on v3.11-rc1 tag http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes git link: git://github.com/nmenon/linux-2.6-playground.git branch: push/omap5-palmas-fixes Tested with https://patchwork.kernel.org/patch/2545061/ + https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data Test result: http://pastebin.com/YqASYkXG Relevant documentation: - OMAP5 uEVM documentation: https://www.svtronics.com/omap/omap54xx?product_id=33 - OMAP5432 Data Manual: http://www.ti.com/product/OMAP5432 - TWL6037 / OTP information: Currently available only under NDA Nishanth Menon (9): ARM: dts: omap5-uevm: document regulator signals used on the actual board ARM: dts: omap5-uevm: update SMPS9 settings ARM: dts: omap5-uevm: update and disable unused regulators LDO[28] ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO3 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings ARM: dts: omap5-uevm: update LDO6 voltage to 1.2V ARM: dts: omap5-uevm: update LDO7 voltage to 2V and settings ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3 arch/arm/boot/dts/omap5-uevm.dts | 78 -- 1 file changed, 49 insertions(+), 29 deletions(-) -- 1.7.9.5 Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 6/9] ARM: dts: omap5-uevm: update LDO4 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi
This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index c6d560b..1550d6a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -372,10 +372,8 @@
ldo4_reg: ldo4 {
/* VDDAPHY_DISP: vdda_dsiport/hdmi */
regulator-name = ldo4;
- regulator-min-microvolt = 220;
- regulator-max-microvolt = 220;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 180;
};
ldo5_reg: ldo5 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/9] ARM: dts: omap5-uevm: document regulator signals used on the actual board
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b430b8f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -282,6 +282,7 @@
regulators {
smps123_reg: smps123 {
+ /* VDD_OPP_MPU */
regulator-name = smps123;
regulator-min-microvolt = 60;
regulator-max-microvolt = 150;
@@ -290,6 +291,7 @@
};
smps45_reg: smps45 {
+ /* VDD_OPP_MM */
regulator-name = smps45;
regulator-min-microvolt = 60;
regulator-max-microvolt = 131;
@@ -298,6 +300,7 @@
};
smps6_reg: smps6 {
+ /* VDD_DDR3 - over VDD_SMPS6 */
regulator-name = smps6;
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
@@ -306,6 +309,7 @@
};
smps7_reg: smps7 {
+ /* VDDS_1v8_OMAP over VDDS_1v8_MAIN */
regulator-name = smps7;
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
@@ -314,6 +318,7 @@
};
smps8_reg: smps8 {
+ /* VDD_OPP_CORE */
regulator-name = smps8;
regulator-min-microvolt = 60;
regulator-max-microvolt = 131;
@@ -322,6 +327,7 @@
};
smps9_reg: smps9 {
+ /* VDDA_2v1_AUD over VDD_2v1 */
regulator-name = smps9;
regulator-min-microvolt = 210;
regulator-max-microvolt = 210;
@@ -331,6 +337,7 @@
};
smps10_reg: smps10 {
+ /* VBUS_5V_OTG */
regulator-name = smps10;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
@@ -339,6 +346,7 @@
};
ldo1_reg: ldo1 {
+ /* VDDAPHY_CAM: vdda_csiport */
regulator-name = ldo1;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
@@ -347,6 +355,7 @@
};
ldo2_reg: ldo2 {
+ /* VCC_2V8_DISP: Does not go anywhere */
regulator-name = ldo2;
regulator-min-microvolt = 290;
regulator-max-microvolt = 290;
@@ -355,6 +364,7 @@
};
ldo3_reg: ldo3 {
+ /* VDDAPHY_MDM: vdda_lli */
regulator-name = ldo3;
regulator-min-microvolt = 300;
regulator-max-microvolt = 300;
@@ -363,6 +373,7 @@
};
ldo4_reg: ldo4 {
+ /* VDDAPHY_DISP: vdda_dsiport/hdmi */
regulator-name = ldo4;
regulator-min-microvolt = 220;
[PATCH 2/9] ARM: dts: omap5-uevm: update SMPS9 settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7 (ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes) introduced regulator entries for OMAP5uEVM. However, The regulator information is based on an older temporary pre-production board variant and does not reflect production board 750-2628-XXX boards. SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be enabled only when audio is active. Since it does not come active by default, it does not require always-on or boot-on. Reported-by: Marc Jüttner m-juett...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/boot/dts/omap5-uevm.dts |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index b430b8f..6709f1e 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++ b/arch/arm/boot/dts/omap5-uevm.dts @@ -331,8 +331,6 @@ regulator-name = smps9; regulator-min-microvolt = 210; regulator-max-microvolt = 210; - regulator-always-on; - regulator-boot-on; ti,smps-range = 0x80; }; -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 9/9] ARM: dts: omap5-uevm: update SDCARD LDO9 and resource REGEN3
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index ef05676..65d7b60 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -235,7 +235,7 @@
};
mmc1 {
- vmmc-supply = vmmcsd_fixed;
+ vmmc-supply = ldo9_reg;
bus-width = 4;
};
@@ -417,8 +417,7 @@
/* VCC_DV_SDIO: vdds_sdcard */
regulator-name = ldo9;
regulator-min-microvolt = 180;
- regulator-max-microvolt = 330;
- regulator-always-on;
+ regulator-max-microvolt = 300;
regulator-boot-on;
};
@@ -439,6 +438,13 @@
regulator-always-on;
regulator-boot-on;
};
+
+ regen3_reg: regen3 {
+ /* REGEN3 controls LDO9 supply to card
*/
+ regulator-name = regen3;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/9] ARM: dts: omap5-uevm: update and disable unused regulators LDO[28]
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards - On production boards, LDO2 and 8 are unused.
LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6709f1e..87b3e9e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -355,10 +355,10 @@
ldo2_reg: ldo2 {
/* VCC_2V8_DISP: Does not go anywhere */
regulator-name = ldo2;
- regulator-min-microvolt = 290;
- regulator-max-microvolt = 290;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ /* Unused */
+ status = disabled;
};
ldo3_reg: ldo3 {
@@ -409,10 +409,11 @@
ldo8_reg: ldo8 {
/* VDD_3v0: Does not go anywhere */
regulator-name = ldo8;
- regulator-min-microvolt = 150;
- regulator-max-microvolt = 150;
- regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
regulator-boot-on;
+ /* Unused */
+ status = disabled;
};
ldo9_reg: ldo9 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/9] ARM: dts: omap5-uevm: update LDO1 voltage to 1.5V and settings
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.
Reported-by: Marc Jüttner m-juett...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 87b3e9e..a55f4d8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -346,10 +346,8 @@
ldo1_reg: ldo1 {
/* VDDAPHY_CAM: vdda_csiport */
regulator-name = ldo1;
- regulator-min-microvolt = 280;
- regulator-max-microvolt = 280;
- regulator-always-on;
- regulator-boot-on;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 180;
};
ldo2_reg: ldo2 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
On Wed, Jul 17, 2013 at 04:26:28PM +0200, Gerhard Sittig wrote: On Wed, Jul 17, 2013 at 13:07 +0100, Mark Brown wrote: This is a pretty long e-mail. It'd probably have taken less time to fix the issues than to reply to the e-mail... but anyway. Not quite. Please consider that careful submission is as expensive as thorough review is, and that a lot of work is done before v1 gets submitted, which you may not always notice from looking at a concentrated series that may no longer suggest how much it took to get there (especially when prepared carefully). This is rather undermined the more time and effort gets spent pushing back against doing trival fixes, of course... besides, the issues here are all really simple to fix and test. It's not a major or risky rewrite of the driver or anything like that - most of this can be tested by just probing the driver. As mentioned before I did not question the need to fix issues as they get identified. I just asked whether reworking the serial OK, so send patches then. The initial COMMON_CLK implementation in part 09/24 registers clkdev items for compatibility during migration. The string isn't greppable since it's constructed by the preprocessor in the MCLK data setup, see the MCLK_SETUP_DATA_PSC() macro. Ugh, right - it didn't show up in searches due to being hidden by the macro. Now let me see how I can improve the SPI driver with regard to overall clock handling and beyond mere operation by coincidence in the absence of errors. But please understand that I don't want to stall the common clock support for a whole platform just because some of the drivers it needs to touch to keep them operational have other issues that weren't addressed yet, while these issues aren't introduced with the series but preceed it. Again, you're not being asked to implement substantial new functionality here. From my point of view I can't test this at all so I'm looking at code that's obviously not good for the standard clock API and wondering if it even works or how robust it's going to be going forward as the common clock code changes which makes me relucatant to say it'll be OK. The fact that you're switching over to use generic code is itself a reason to make sure that the API usage is sane, dodgy API usage against open coded clock implementations is less risky than against the common code. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On 07/16/2013 09:02 PM, Shawn Guo wrote: On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote: Registering the driver earlier won't cause any bugs. However, it's not the correct approach. Deferred probe /is/ the approach for assuring correct dependencies between drivers. It works and should be used. There are not enough initcall levels to play games using initcalls and solve all the issues, and the ordering requirements vary board-to-board. Deferred probe at runtime handles this without having to manually place all the drivers into specific initcall levels, and dynamically adjusts to board differences, since it all happens automatically at run-time. I do not quite follow the argument here. I agree with you that deferred probe is the approach to solve dependencies. But it does not necessarily mean that initcall can not be used to help it save some nasty or nested deferring. Deferred probe and initcalls are not two mutually exclusive mechanisms but two which can help each other. My understanding is that deferred probe was implemented specifically to avoid having to, or allowing, the use of initcall levels to determine probe order. However, if someone closely associated with the implementation of deferred probe (e.g. Grant, or a device core maintainer) is willing to step up and say I'm wrong, I'll drop my objection. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote: The sanest location at this point might simply be drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c depending on whether or not more such driver glue is expected in the vexpress future. No point putting arm in the path, especially if this is later reused on arm64. You wouldn't be making that argument if it were arch/arm64 and arch/arm32 - you'd probably be arguing that arm made perfect sense. Don't get too hung up on names please, it's really not worth the time and effort being soo pedantic, and being soo pedantic leads to pointless churn when someone comes along and wants to pedantically change the names because it no longer matches the users. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On 07/17/2013 05:00 AM, Laurent Pinchart wrote: On Monday 15 July 2013 21:39:31 Stephen Warren wrote: ... But then there's a problem where people assume that the common flags are always available, and somewhere they aren't... Care is needed in the choice of which common flags to define and/or how they're used. Exactly. That's why I think listing the supported common flags in individual bindings makes sense when some of the flags are not supported by all devices. As the only PWM flags currently used are common to all PWM devices I can leave this out now. I have no strong preference, I'll follow your opinion on this. Yes, I guess separating the concept of defining common flags and which devices use them is good. And then indeed individual devices need to define which of the common flags they support. I'd still like to see the *definition* of those common flags in some central place (i.e. pwm.txt or a header that defines constants for it), and the other device bindings simply reference that for the actual definitions. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch v2] spi/xilinx: signedness issue checking platform_get_irq()
On Wed, Jul 17, 2013 at 06:34:48PM +0300, Dan Carpenter wrote: In xilinx_spi_probe() we use xspi-irq to store negative error codes so it has to be signed. We weren't going to use the upper bit any way so this is fine. Applied, thanks. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] media: i2c: tvp7002: add OF support
Hi Sylwester, Thanks for the quick review. On Wed, Jul 17, 2013 at 10:09 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 07/17/2013 06:20 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add OF support for the tvp7002 driver. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- This patch depends on https://patchwork.kernel.org/patch/2828800/ Changes for v3: 1: Fixed review comments pointed by Sylwester. .../devicetree/bindings/media/i2c/tvp7002.txt | 43 + drivers/media/i2c/tvp7002.c| 67 ++-- 2 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode 100644 index 000..744125f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt @@ -0,0 +1,43 @@ +* Texas Instruments TV7002 video decoder + +The TVP7002 device supports digitizing of video and graphics signal in RGB and +YPbPr color space. + +Required Properties : +- compatible : Must be ti,tvp7002 + +- hsync-active: HSYNC Polarity configuration for endpoint. + +- vsync-active: VSYNC Polarity configuration for endpoint. I woudn't refer to endpoint here, perhaps to the specific hardware bus instead ? So it is clear what part of the device it refers to ? OK, I'll refer to bus instead. +- pclk-sample: Clock polarity of the endpoint. This description is not very useful, my feeling is that this property is better described in video-interfaces.txt. agreed its just a one liner, and below I have mentioned a link to video-interfaces.txt for better understanding of this generic properties. +- sync-on-green-active: Active state of Sync-on-green signal property of the + endpoint, 0/1 for normal/inverted operation respectively. + +- field-even-active: Active-high Field ID polarity of the endpoint. I find it hard to understand what this property is about exactly. Not sure if you need to repeat detailed description of the signal polarity properties. Perhaps its sufficient to list which properties are relevant for this device, but I'm not opposed to having supplementary description here. I would just make it more specific to the TVP7002 chip. How about the below description ? Active-high Field ID output polarity control. Under normal operation, the field ID output is set to logic 1 for an odd field (field 1) and set to logic 0 for an even field (field 0). 0 = Normal operation (default) 1 = FID output polarity inverted Also please note that only 'compatible' property is required, all other are optional. And it probably makes sense to specify what are default values for each property when it is not specified. Agreed I'll add them to optional list, and mention their default values too. -- Regards, Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework
On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote: Hi, On Wednesday 17 July 2013 11:59 AM, Greg KH wrote: On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote: +menuconfig GENERIC_PHY + tristate PHY Subsystem + help +Generic PHY support. + +This framework is designed to provide a generic interface for PHY +devices present in the kernel. This layer will have the generic +API by which phy drivers can create PHY using the phy framework and +phy users can obtain reference to the PHY. Shouldn't this be something that other drivers select? How will anyone know if they need this or not? All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those PHY drivers can be selected like in [1]. The PHY consumer driver should ideally use *depends on* in their Kconfig. [1] - http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html No, switch it around the other way. How would I even _know_ that I need to enable the generic PHY subsystem in the first place? How can I determine that I need this for my hardware? You need to give hints to someone who doesn't even know what a PHY is, otherwise they will always disable it and move on. --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,544 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2013 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. You really mean any later version (I have to ask)? That was copied from somewhere :-s So, is that what you really mean to have for this code? + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. Are these two paragraphs needed? This isn't a program, and they got a copy of the GPL already with the kernel. hmm.. I can remove that. +static struct class *phy_class; Why do you need a class? Wanted to group all the PHY drivers to be used by different subsystems (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my initial version [3] on using a bus_type instead of class but then it was decided to go with class itself. [3] - http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html Ok, but what does the class usage get you? When modifying/adding new sysfs stuff, you need a Documentation/ABI/ entry as well. I'm not actually adding any new sysfs entry other than what a *class_create* must have created. Do I need to add one for that? If you are not creating anything in sysfs at all, why use the driver model? (hint, I think you need to do something here to justify it...) thanks, greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: DT binding review for Armada display subsystem
On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer s.ha...@pengutronix.de wrote: You don't have to call drm_irq_install(). Both the exynos and i.MX driver do without it and at least the i.MX driver uses multiple irqs per drm_device. Good point, thanks. That unblocks that item. Secondly, devm. I understand from the best practices thread that we want to have exactly one platform_device which corresponds to the super node, and all of the individual display controller components will be represented by DT nodes but *without* their own platform_device. A super node approach doesn't mean that there's only one platform device. You can still have a platform device for each component. Yes. As noted, this was simply a preference that seemed to emerge in the previous discussion. If in practice it causes too many headaches, maybe we will change our minds. For now devm is the only issue I have seen; I am avoiding devm where it is no longer possible under this design. The goal of getting this driver working properly on OLPC XO seems to be a twisty path that presents a new issue at every turn. In the above work I am trying to first implement the DT binding for Armada 510/cubox, as that is what the current code is aimed at. I am now facing a problem with i2c/TDA998x which Russell already noted: http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html What *can't* be done without a rewrite of the DRM slave encoder backend is to have the TDA998x I2C device provided by DT. There are mumblings about redoing the slave encoder API, hopefully this will be fixed there. This is because the existing DRM/encoder system works something like this: 1. i2c driver (e.g. tda998x_drv) registers as an i2c_driver via drm_i2c_encoder_register() 2. The drm driver (i.e. armada) later has to know that it is expecting a tda998x instance. It calls drm_i2c_encoder_init() to set this up. drm_i2c_encoder init requires: 1. The i2c_adapter in question. In a DT world, we could get this from finding the parent node of the tda998x node (this is the i2c bus master), and then using i2c_for_each_dev to find the first i2c adapter instance that has the same of_node. 2. i2c_board_info - basically the address of the device on the i2c bus. This is basically the way of instantiating i2c devices from platform data. Not the DT way :( In a DT world the i2c driver would be instantiated from a node in the DT, which already includes the info that would come in i2c_board_info. Then later it would have to be linked to a DRM slave/encoder, perhaps when the DRM device finds the of_node corresponding to it. So I think the next step is fixing up DRM, as Russell hinted. Unless someone sees another acceptable option that doesn't break our DT design. I am going away for 3-4 weeks now, so you won't be hearing for me for a while. Just in case someone else wants to pick up the task in the mean time, here is my work in progress. I'm still reading and learning, so please don't do any detailed reviews yet :) http://dev.laptop.org/~dsd/20130717/0001-dove-clk-dt-wip.patch It includes the previous clock selection patch as this stuff is quite closely bound with DT support. Thanks Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/17/2013 01:12 PM, Oleksandr Kozaruk wrote:
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
known also as Phoenix and PhoenixLite.
The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
respectively. Some channels have current source and are used for
measuring voltage drop on resistive load for detecting battery ID
resistance, or measuring voltage drop on NTC resistors for external
temperature measurements. Some channels measure voltage, (i.e. battery
voltage), and have voltage dividers, thus, capable to scale voltage.
Some channels are dedicated for measuring die temperature.
Some channels are calibrated in 2 points, having offsets from ideal
values kept in trim registers. This is used to correct measurements.
The differences between GPADC in TWL6030 and TWL6032:
- 10 bit vs 12 bit ADC;
- 17 vs 19 channels;
- channels have different purpose(i.e. battery voltage
channel 8 vs channel 18);
- trim values are interpreted differently.
Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K,
Girish S Ghongdemath.
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
Almost there (I hope). But please run scripts/checkpatch, make C=2 and make
coccicheck on your driver and fix all errors those tools give you before
submitting the driver upstream.
[...]
+static int twl6030_gpadc_get_raw(struct twl6030_gpadc_data *gpadc,
+ int channel, int *res)
+{
+ u8 reg = gpadc-pdata-channel_to_reg(channel);
+ __le16 val;
+ int raw_code;
+ int ret;
+
+ ret = twl6030_gpadc_read(reg, (u8 *)val);
+ if (ret) {
+ dev_dbg(gpadc-dev, unable to read register 0x%X\n, reg);
+ return ret;
+ }
+
+ raw_code = le16_to_cpup(val);
raw_code = le16_to_cpu(val)
+ dev_dbg(gpadc-dev, GPADC raw code: %d, raw_code);
+
+ if (twl6030_channel_calibrated(gpadc-pdata, channel))
+ *res = twl6030_gpadc_make_correction(gpadc, channel, raw_code);
+ else
+ *res = raw_code;
+
+ return ret;
+}
+
[...]
+static int twl6030_gpadc_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct twl6030_gpadc_data *gpadc = iio_priv(indio_dev);
+ int ret = -EINVAL;
+ long timeout;
+
+ mutex_lock(gpadc-lock);
+
+ ret = gpadc-pdata-start_conversion(chan-channel);
+ if (ret) {
+ dev_err(gpadc-dev, failed to start conversion\n);
+ goto err;
+ }
+ /* wait for conversion to complete */
+ timeout = wait_for_completion_interruptible_timeout(
+ gpadc-irq_complete, msecs_to_jiffies(5000));
+ if (!timeout)
+ return -ETIMEDOUT;
+ else if (timeout 0)
+ return EINTR;
You still hold the mutex, try this instead:
ret = wait_for_
if (ret == 0)
ret = -ETIMEDOUT;
if (ret 0)
goto err;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = twl6030_gpadc_get_raw(gpadc, chan-channel, val);
+ ret = ret ? -EIO : IIO_VAL_INT;
+ break;
+
+ case IIO_CHAN_INFO_PROCESSED:
+ ret = twl6030_gpadc_get_processed(gpadc, chan-channel, val);
+ ret = ret ? -EIO : IIO_VAL_INT;
+ break;
+
+ default:
+ break;
+ }
+err:
+ mutex_unlock(gpadc-lock);
+
+ return ret;
+}
[...]
+
+static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
+{
+ int chn, d1 = 0, d2 = 0, temp;
+ u8 trim_regs[17];
+ int ret;
+
+ ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1,
+ TWL6030_GPADC_TRIM1, 16);
+ if (ret 0) {
+ dev_err(gpadc-dev, calibration failed\n);
+ return ret;
+ }
+
+ /*
+ * Loop to calculate the value needed for returning voltages from
+ * GPADC not values.
+ *
+ * gain is calculated to 3 decimal places fixed point.
+ */
+ for (chn = 0; chn TWL6032_GPADC_MAX_CHANNELS; chn++) {
+
+ switch (chn) {
+ case 0:
+ case 1:
+ case 2:
+ case 3:
+ case 4:
+ case 5:
+ case 6:
+ case 11:
+ case 12:
+ case 13:
+ case 14:
+ /* D1 */
+ d1 = (trim_regs[3] 0x1F) 2;
+ d1 |= (trim_regs[1] 0x06) 1;
+ if (trim_regs[1] 0x01)
+ d1 = -d1;
+
+ /* D2 */
+ d2 = (trim_regs[4] 0x3F) 2;
+ d2 |= (trim_regs[2] 0x06) 1;
+ if
Re: [PATCH 2/2] pwm: Add PWM polarity flag macros for DT
On Wed, Jul 17, 2013 at 11:11:19AM -0600, Stephen Warren wrote: On 07/17/2013 05:00 AM, Laurent Pinchart wrote: On Monday 15 July 2013 21:39:31 Stephen Warren wrote: ... But then there's a problem where people assume that the common flags are always available, and somewhere they aren't... Care is needed in the choice of which common flags to define and/or how they're used. Exactly. That's why I think listing the supported common flags in individual bindings makes sense when some of the flags are not supported by all devices. As the only PWM flags currently used are common to all PWM devices I can leave this out now. I have no strong preference, I'll follow your opinion on this. Yes, I guess separating the concept of defining common flags and which devices use them is good. And then indeed individual devices need to define which of the common flags they support. I'd still like to see the *definition* of those common flags in some central place (i.e. pwm.txt or a header that defines constants for it), and the other device bindings simply reference that for the actual definitions. That sounds reasonable to me. Thierry signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 17 Jul 2013, Russell King - ARM Linux wrote: On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote: The sanest location at this point might simply be drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c depending on whether or not more such driver glue is expected in the vexpress future. No point putting arm in the path, especially if this is later reused on arm64. You wouldn't be making that argument if it were arch/arm64 and arch/arm32 - you'd probably be arguing that arm made perfect sense. Well... in a sense: yes. But in the end, having per arch directories under drivers/ is silly. We already have per arch directories under arch/already. Don't get too hung up on names please, it's really not worth the time and effort being soo pedantic, and being soo pedantic leads to pointless churn when someone comes along and wants to pedantically change the names because it no longer matches the users. At this point I don't really care about the name. I just want the damn thing merged upstream. But after several iterations to either fit one or another maintainers taste, each rework ends up in that maintainer saying: Now that you've reworked the code, I still don't like it since this no longer fits in my subsystem tree. In fact what we'd need at this point is drivers/code_that_no_subsystem_maintainers_wants/. This is becoming overly ridiculous. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Oleksandr Kozaruk oleksandr.koza...@ti.com wrote: Hello Jonathan, Two very quick comments based on quick glance as it may be a while before I can do a full review. We still have channels that are only usable for temperature being output to user space as voltage channels? Is the conversion so very hard? Can you please clarify what should return temperature channel for in_tempX_input (processed)? Is it voltage or Celsius degree? Milli degrees centigrade. in_tempX_raw should return ADC code? Right? Yes See Documentation/ABI/testing/sysfs-bus-iio Regards, OK. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hi Lorenzo, On Tue, Jul 16, 2013 at 05:05:42PM +0100, Lorenzo Pieralisi wrote: Hello, version v5 of VExpress SPC driver, please read on the changelog for major changes and explanations. The probing scheme is unchanged, since after trying the early platform devices approach it appeared that the end result was no better than the current one. The only clean solution relies either on changing how secondaries are brought up in the kernel (later than now) or enable early platform device registration through DT. Please check this thread for the related discussion: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html The interface was adapted to regmap and again reverted to old driver for the following reasons: - Power down registers locking is hairy and requires arch spinlocks in the MCPM back end to work properly, normal spinlocks cannot be used - Regmap adds unnecessary code to manage SPC since it is just a bunch of registers used to control power management flags, the overhead is just not worth it (talking about power down registers, not the vexpress config interface) - The locking scheme behind regmap requires all registers in the map to be protected with the same lock, which is not exactly what we want here - Given the reasons above, adding a regmap interface buys us nothing from a driver readability and maintainability perspective (again just talking about the power interface, a few registers) because for the SPC it would simply not be used /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Could you please elaborate on how will the SPC driver extend into an MFD driver? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hi Pawel, On Wed, Jul 17, 2013 at 03:20:11PM +0100, Pawel Moll wrote: On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote: On Wed, 17 Jul 2013, Pawel Moll wrote: On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote: If this is really miscelaneous code that really doesn't fit anywhere else, it should rather go into drivers/misc/ as a last resort. Interestingly enough drivers/misc was my first choice for all the vexpress stuff, but it wasn't received well... Anyway, the SPC driver as it is now seem to be a power management system driver. Maybe a relevant directory would be in place? Wouldn't PSCI belong there as well? (there are two psci.c files in arch/arm and arch/arm64, surprisingly similar ones ;-) The bottom line is: today it is not an MFD driver. But we know it will, right? So better save some churn by storing the initial code where it would end up anyway once complete. Not in that form, no. The code living in mfd will just register mfd_cells while functional parts are going to live elsewhere. This is how I understand what Samuel asked me to do and that's what is happening to vexpress-sysreg now. Very good, I'll happily apply such changes. If I understand the IP correctly, the SPC driver will stay as a set of runtime APIs for controlling the SPC features. If that's the case, then misc sounds like a more appropriate place for this driver. drivers/power/ really is for power supplies and charging drivers. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hi Nicolas, On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote: On Wed, 17 Jul 2013, Russell King - ARM Linux wrote: On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote: The sanest location at this point might simply be drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c depending on whether or not more such driver glue is expected in the vexpress future. No point putting arm in the path, especially if this is later reused on arm64. You wouldn't be making that argument if it were arch/arm64 and arch/arm32 - you'd probably be arguing that arm made perfect sense. Well... in a sense: yes. But in the end, having per arch directories under drivers/ is silly. We already have per arch directories under arch/already. Don't get too hung up on names please, it's really not worth the time and effort being soo pedantic, and being soo pedantic leads to pointless churn when someone comes along and wants to pedantically change the names because it no longer matches the users. At this point I don't really care about the name. I just want the damn thing merged upstream. But after several iterations to either fit one or another maintainers taste, each rework ends up in that maintainer saying: Now that you've reworked the code, I still don't like it since this no longer fits in my subsystem tree. FWIW, we asked Pawel to rework the sysreg and config parts of the vexpress driver, make it an actual MFD driver, and spread the remaining bits of the code into their respective subsystems. I don't think this is an eccentric requirement. In fact what we'd need at this point is drivers/code_that_no_subsystem_maintainers_wants/. Which is what some people think drivers/mfd/ is... I don't mind merging Lorenzo's SPC driver as it is if he can explain to me how it will eventually evolve into an actual MFD driver. If that's not the case, I don't see how I could justify merging it through the MFD tree. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [lm-sensors] [RESEND PATCH V1 0/9] thermal: introduce DT thermal zone build
On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin wrote: Hello all, As you noticed, I am working in a way to represent thermal data using device tree [1]. Essentially, this should be a way to say what to do with a sensor and how to associate (cooling) actions with it. Seems to me that goes way beyond the supposed scope of devicetree data. Devicetree data is supposed to describe hardware, not its configuration or use. This is clearly a use case. Guenter The motivation to create such infrastructure is: (i) - to reuse the existing temperature sensor code base; (ii) - have a way to easily describe thermal data across different boards for the same sensor. Say you have an i2c temp sensor, which is placed close to your battery on board A but on board B, another instance of this same senor is placed close to your display, for instance. This series introduces then a DT parser. The data expected in DT must contain the needed properties to build a thermal zone out of the desired sensor. All properties are documented and they are derived from the existing requirements of current thermal API. In order to perform a binding with cooling devices, the new thermal zone built using DT nodes will use the existing thermal API that uses binding parameters. This is the current proposed way to register thermal zones with platform information, written by Durga. There are some virtual concepts that are pushed to device tree, I know. But I believe using device tree to do this makes sense because we are still describing the HW and how they are related to each other. Things like cooling devices are not represented in device tree though, as I believe that will cause a lot of confusion with real devices (as already does). So the series is short but I think it makes sense to describe how it is organized, as it touches several places. First four patches are a preparation for this parser. There is a change on cpufreq-cpu0, so that it knows now how to load its corresponding cooling device. There is a change on thermal_core to split its hwmon code, because I think we may need to improve this code base when we start to integrate better with hwmon temperature sensors. Then, another needed preparation is to improve the bind_params, so that we are able to bind with upper and lower limits. The remaining patches are the changes with the proposed DT parser. A part from the DT thermal zone builder itself (patch 05), I also changed the ti-soc-thermal driver to use this new API and the omap4430 bandgap DT node, as an example (this has been tested on panda omap4430); and also changed the hwmon drivers lm75 and tmp102 to have the option to build a thermal zone using DT. I haven't touched any dts file using lm75 or tmp102 because this should come on a need basis. I believe this code is pretty usable the way it is, but might need to be revisited, in case the enhancement proposed by Durga get in. This is because representing virtual thermal zones built out of several sensors may need a different representation in DT. [1] - RFC of this work: http://comments.gmane.org/gmane.linux.power-management.general/35874 Changes from RFC: - Added a way to load cpufreq cooling device out of DT - Added a way to bind with upper and lower limits using bind_params - Added a way to specify upper and lower binding limits on DT - Added DT thermal builder support to lm75 and tmp102 hwmon drivers - Changed ERANGE to EDOM - Added thermal constants for zone type and bind limit, so that dts file could be more readable Tested on panda omap4430 (3.11-rc1 with minor changes for getting cpufreq working) BR, Eduardo Valentin (9): cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling' thermal: hwmon: move hwmon support to single file thermal: thermal_core: allow binding with limits on bind_params arm: dts: flag omap4430 with needs-cooling for cpu node thermal: introduce device tree parser thermal: ti-soc-thermal: use thermal DT infrastructure arm: dts: add omap4430 thermal data hwmon: lm75: expose to thermal fw via DT nodes hwmon: tmp102: expose to thermal fw via DT nodes .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 3 + .../devicetree/bindings/thermal/thermal.txt| 133 ++ Documentation/thermal/sysfs-api.txt| 7 + arch/arm/boot/dts/omap443x.dtsi| 32 +- drivers/cpufreq/cpufreq-cpu0.c | 8 + drivers/hwmon/lm75.c | 29 ++ drivers/hwmon/tmp102.c | 25 ++ drivers/thermal/Kconfig| 22 + drivers/thermal/Makefile | 4 + drivers/thermal/thermal_core.c | 274 +--- drivers/thermal/thermal_dt.c | 458 + drivers/thermal/thermal_hwmon.c| 269
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 17 Jul 2013, Samuel Ortiz wrote: On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote: At this point I don't really care about the name. I just want the damn thing merged upstream. But after several iterations to either fit one or another maintainers taste, each rework ends up in that maintainer saying: Now that you've reworked the code, I still don't like it since this no longer fits in my subsystem tree. FWIW, we asked Pawel to rework the sysreg and config parts of the vexpress driver, make it an actual MFD driver, and spread the remaining bits of the code into their respective subsystems. I don't think this is an eccentric requirement. I agree. However the code that Lorenzo just posted can't be deprived of any more sysreg/config parts. They are simply nonexistent. Even the larger code you reviewed before is completely useless without _additional_ drivers to go on top which are indeed waiting after this code to be merged before they are submitted to their respective subsystems. And those additional drivers are way more interesting than this dumb register access arbitrator. Because this is fundamentally the only thing it does. In fact what we'd need at this point is drivers/code_that_no_subsystem_maintainers_wants/. Which is what some people think drivers/mfd/ is... Does mfd still stand for Multi Function Device? I don't mind merging Lorenzo's SPC driver as it is if he can explain to me how it will eventually evolve into an actual MFD driver. If that's not the case, I don't see how I could justify merging it through the MFD tree. Maybe the misunderstanding is about what actually is a MFD driver. Given your persisting reluctance, I may only conclude that this is indeed not a MFD driver after all. So I'll follow existing precedents in the kernel and move Lorenzo's code to drivers/platform/vexpress/. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins
On 07/17/2013 03:38 PM, Pavel Machek wrote: On Wed 2013-07-17 10:57:08, Stephen Warren wrote: On 07/16/2013 09:02 PM, Shawn Guo wrote: On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote: Registering the driver earlier won't cause any bugs. However, it's not the correct approach. Deferred probe /is/ the approach for assuring correct dependencies between drivers. It works and should be used. There are not enough initcall levels to play games using initcalls and solve all the issues, and the ordering requirements vary board-to-board. Deferred probe at runtime handles this without having to manually place all the drivers into specific initcall levels, and dynamically adjusts to board differences, since it all happens automatically at run-time. I do not quite follow the argument here. I agree with you that deferred probe is the approach to solve dependencies. But it does not necessarily mean that initcall can not be used to help it save some nasty or nested deferring. Deferred probe and initcalls are not two mutually exclusive mechanisms but two which can help each other. My understanding is that deferred probe was implemented specifically to avoid having to, or allowing, the use of initcall levels to determine probe order. However, if someone closely associated with the implementation of deferred probe (e.g. Grant, or a device core maintainer) is willing to step up and say I'm wrong, I'll drop my objection. AFAIR, defered probing is known to be a hack by its authors. We should still try to get initcall levels right... I don't /think/ it was the concept of deferred probe that was considered hacky, but perhaps just the first proof-of-concept implementation, and any hackiness was presumably solved before the feature was merged. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/4] Add PWM polarity flag macro for DT
Hello, Here's a small patch set that replaces PWM polarity numerical constants with macros in DT. The series is the result of splitting the original patch into four patches that - add the flag macro (both in a header file and in the PWM DT binding core documentation) - use the macro in the PWM core code - update existing DT bindings to refer to the PWM DT bindings core documentation - update existing DT sources to use the new macro I believe I've taken all comments received so far into account. Most notable changes include - splitting the original patch - removing the PWM_POLARITY_NORMAL flag, which wasn't a flag but was defined as 0 - renaming the PWM_POLARITY_INVERSED DT flag to PWM_POLARITY_INVERTED - not relying on DT flags and PWM C flags having identical names and values Laurent Pinchart (4): pwm: Add PWM polarity flag macro for DT pwm: Use the DT macro directly when parsing PWM DT flags pwm: Update DT bindings to reference pwm.txt for cells documentation ARM: dts: Use the PWM polarity flags Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt| 8 +++- Documentation/devicetree/bindings/pwm/imx-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/mxs-pwm.txt | 4 ++-- .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 5 ++--- Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/pwm-samsung.txt | 10 +++--- Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | 8 +++- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 8 +++- Documentation/devicetree/bindings/pwm/pwm.txt | 7 --- Documentation/devicetree/bindings/pwm/spear-pwm.txt| 5 ++--- Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt| 4 ++-- Documentation/devicetree/bindings/pwm/vt8500-pwm.txt | 8 +++- arch/arm/boot/dts/am335x-evmsk.dts | 3 ++- arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++- drivers/pwm/core.c | 7 +++ include/dt-bindings/pwm/pwm.h | 14 ++ 17 files changed, 54 insertions(+), 52 deletions(-) create mode 100644 include/dt-bindings/pwm/pwm.h -- Regards, Laurent Pinchart ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/4] pwm: Use the DT macro directly when parsing PWM DT flags
Don't redefine a PWM_SPEC_POLARITY macro with a value identical to PWM_POLARITY_INVERTED, use the PWM DT macro directly. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- drivers/pwm/core.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index dfbfbc5..2ca9504 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -30,10 +30,9 @@ #include linux/debugfs.h #include linux/seq_file.h -#define MAX_PWMS 1024 +#include dt-bindings/pwm/pwm.h -/* flags in the third cell of the DT PWM specifier */ -#define PWM_SPEC_POLARITY (1 0) +#define MAX_PWMS 1024 static DEFINE_MUTEX(pwm_lookup_lock); static LIST_HEAD(pwm_lookup_list); @@ -149,7 +148,7 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args) pwm_set_period(pwm, args-args[1]); - if (args-args[2] PWM_SPEC_POLARITY) + if (args-args[2] PWM_POLARITY_INVERTED) pwm_set_polarity(pwm, PWM_POLARITY_INVERSED); else pwm_set_polarity(pwm, PWM_POLARITY_NORMAL); -- 1.8.1.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/4] pwm: Update DT bindings to reference pwm.txt for cells documentation
The PWM client cells format is documented in the generic pwm.txt documentation and duplicated in all PWM driver bindings. Remove duplicate information and reference pwm.txt instead. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 8 +++- Documentation/devicetree/bindings/pwm/imx-pwm.txt| 4 ++-- Documentation/devicetree/bindings/pwm/mxs-pwm.txt| 4 ++-- Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 5 ++--- Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt| 4 ++-- Documentation/devicetree/bindings/pwm/pwm-samsung.txt| 10 +++--- Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | 8 +++- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 8 +++- Documentation/devicetree/bindings/pwm/spear-pwm.txt | 5 ++--- Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt | 4 ++-- Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt | 4 ++-- Documentation/devicetree/bindings/pwm/vt8500-pwm.txt | 8 +++- 12 files changed, 29 insertions(+), 43 deletions(-) diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed..8031148 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt @@ -2,11 +2,9 @@ Atmel TCB PWM controller Required properties: - compatible: should be atmel,tcb-pwm -- #pwm-cells: Should be 3. The first cell specifies the per-chip index - of the PWM to use, the second cell is the period in nanoseconds and - bit 0 in the third cell is used to encode the polarity of PWM output. - Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity - set to 0 for normal polarity. +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. - tc-block: The Timer Counter block to use as a PWM chip. Example: diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt index 8522bfb..b50d7a6d 100644 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt @@ -3,8 +3,8 @@ Freescale i.MX PWM controller Required properties: - compatible: should be fsl,soc-pwm - reg: physical base address and length of the controller's registers -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. - interrupts: The interrupt for the pwm controller Example: diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt index 9e3f8f1..96cdde5 100644 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt @@ -3,8 +3,8 @@ Freescale MXS PWM controller Required properties: - compatible: should be fsl,imx23-pwm - reg: physical base address and length of the controller's registers -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. - fsl,pwm-number: the number of PWM devices Example: diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt index 01438ec..c3fc57a 100644 --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt @@ -5,9 +5,8 @@ Required properties: - nvidia,tegra20-pwm - nvidia,tegra30-pwm - reg: physical base address and length of the controller's registers -- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The - first cell specifies the per-chip index of the PWM to use and the second - cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. Example: diff --git a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt index 1e3dfe7..f84ec9d 100644 --- a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt @@ -3,8 +3,8 @@ NXP PCA9685 16-channel 12-bit PWM LED controller Required properties: - compatible: nxp,pca9685-pwm - - #pwm-cells: should be 2. The first cell specifies the per-chip index -of the PWM to use and the second cell is the period in nanoseconds. + - #pwm-cells: Should be 2.
[PATCH v2 1/4] pwm: Add PWM polarity flag macro for DT
Define a PWM_POLARITY_INVERTED macro in include/dt-bindings/pwm/pwm.h to
be used by device tree sources.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
Documentation/devicetree/bindings/pwm/pwm.txt | 7 ---
include/dt-bindings/pwm/pwm.h | 14 ++
2 files changed, 18 insertions(+), 3 deletions(-)
create mode 100644 include/dt-bindings/pwm/pwm.h
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt
b/Documentation/devicetree/bindings/pwm/pwm.txt
index 06e6724..8556263 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -43,13 +43,14 @@ because the name backlight would be used as fallback
anyway.
pwm-specifier typically encodes the chip-relative PWM number and the PWM
period in nanoseconds.
-Optionally, the pwm-specifier can encode a number of flags in a third cell:
-- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
+Optionally, the pwm-specifier can encode a number of flags (defined in
+dt-bindings/pwm/pwm.h) in a third cell:
+- PWM_POLARITY_INVERTED: invert the PWM signal polarity
Example with optional PWM specifier for inverse polarity
bl: backlight {
- pwms = pwm 0 500 1;
+ pwms = pwm 0 500 PWM_POLARITY_INVERTED;
pwm-names = backlight;
};
diff --git a/include/dt-bindings/pwm/pwm.h b/include/dt-bindings/pwm/pwm.h
new file mode 100644
index 000..96f49e8
--- /dev/null
+++ b/include/dt-bindings/pwm/pwm.h
@@ -0,0 +1,14 @@
+/*
+ * This header provides constants for most PWM bindings.
+ *
+ * Most PWM bindings can include a flags cell as part of the PWM specifier.
+ * In most cases, the format of the flags cell uses the standard values
+ * defined in this header.
+ */
+
+#ifndef _DT_BINDINGS_PWM_PWM_H
+#define _DT_BINDINGS_PWM_PWM_H
+
+#define PWM_POLARITY_INVERTED (1 0)
+
+#endif
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/4] ARM: dts: Use the PWM polarity flags
Replace the numerical polarity flags with the PWM_POLARITY_INVERTED
symbolic constant.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..62124c7 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include am33xx.dtsi
+#include dt-bindings/pwm/pwm.h
/ {
model = TI AM335x EVM-SK;
@@ -298,7 +299,7 @@
backlight {
compatible = pwm-backlight;
- pwms = ecap2 0 5 1;
+ pwms = ecap2 0 5 PWM_POLARITY_INVERTED;
brightness-levels = 0 58 61 66 75 90 125 170 255;
default-brightness-level = 8;
};
diff --git a/arch/arm/boot/dts/wm8850-w70v2.dts
b/arch/arm/boot/dts/wm8850-w70v2.dts
index 90e913f..7a563d2 100644
--- a/arch/arm/boot/dts/wm8850-w70v2.dts
+++ b/arch/arm/boot/dts/wm8850-w70v2.dts
@@ -11,13 +11,14 @@
/dts-v1/;
/include/ wm8850.dtsi
+#include dt-bindings/pwm/pwm.h
/ {
model = Wondermedia WM8850-W70v2 Tablet;
backlight {
compatible = pwm-backlight;
- pwms = pwm 0 5 1;/* duty inverted */
+ pwms = pwm 0 5 PWM_POLARITY_INVERTED;
brightness-levels = 0 40 60 80 100 130 190 255;
default-brightness-level = 5;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
Hi Luciano,
On Monday 01 July 2013 15:39:30 Luciano Coelho wrote:
On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
(fixed Mike's address)
On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho
wrote:
On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho
wrote:
+Optional properties:
+
+
+- refclock: the internal WLAN reference clock frequency
(required for
+ WiLink6 and WiLink7; not used for WiLink8). Must be
one of the
+ following:
+ 0 = 19.2 MHz
+ 1 = 26.0 MHz
+ 2 = 38.4 MHz
+ 3 = 52.0 MHz
+ 4 = 38.4 MHz, XTAL
+ 5 = 26.0 MHz, XTAL
+
+- tcxoclock: the internal WLAN TCXO clock frequency
(required for
+ WiLink7 not used for WiLink6 and WiLink8). Must be
one of the
+ following:
+ 0 = 19.200 MHz
+ 1 = 26.000 MHz
+ 2 = 38.400 MHz
+ 3 = 52.000 MHz
+ 4 = 16.368 MHz
+ 5 = 32.736 MHz
+ 6 = 16.800 MHz
+ 7 = 33.600 MHz
This looks suspiciously like what we have the common clock
bindings for:
refclk {
compatible = fixed-clock;
#clock-cells = 0;
clock-frequency = 1920;
}
wilink {
compatible = ti,wilink7;
interrupt-parent = some_interrupt_controller;
interrupts = 0 1 1;
clocks = refclk, refclk;
clock-names = refclk, txoclk;
};
Could you not use them?
Hmmm... this actually does look good. But these are
internal clocks in the modules, they cannot be accessed from
outside. Does it make sense to register them with the clock
framework?
Given we already have a common way of describing clocks, I
think it makes sense to use it -- people already understand
the common bindings, and it's less code to add add to the
kernel. I don't think the fact these clocks are internal
should prevent us from describing them as we would an external
clock.
Yes, I agree with you. Thanks for the suggestion! I think it
will look much better. And now that I dug a bit more into the
code, I can see that there are only structs being populated, so
there shouldn't be any other side-effects.
Hmmm, one thing that escaped me. Besides the frequency, I also
need a boolean that tells if the clock is XTAL or not. I can't
figure out how to pass this if I use the generic clock framework.
Any suggestions?
Could you use clock-output-names for that ?
XTAL clock:
refclk {
compatible = fixed-clock;
#clock cells = 0;
clock-frequency = 1920;
clock-output-names = xtal;
};
non-XTAL clock:
refclk {
compatible = fixed-clock;
#clock cells = 0;
clock-frequency = 1920;
clock-output-names = osc; /* any better name ? */
};
This starts looking a bit hacky. Using the output name as a flag is
not very pretty.
I think it would be better to have a separate flag for it in the wlan
node. Like an optional refclock-xtal boolean or something. The
downside of this is that we would be adding information about the
clock details in the wilink node. :(
OTOH, we could add a flag to the generic clock binding? A new optional
boolean that tells whether the clock is XTAL or not:
refclk {
compatible = fixed-clock;
#clock cells = 0;
clock-frequency = 1920;
clock-xtal;
};
Do you think that would make sense?
sure, that looks alright to me. Surely there are other devices out there
who want to know if the clock comes from a crystal or not ?!?
Mike, what do you think about this idea? If it sounds okay to you, I can
cook up a patch adding this flag.
Hmmm... I started implementing this whole thing, but using these clocks
as fixed-clocks is not so straightforward. The problem is that I
would need to register my driver as a
Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property
Hi Stephen,
On Monday 15 July 2013 12:40:29 Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This property is no longer required by the GPIO binding. Remove it.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
This should presumably be applied along with the previous changes
The mach-shmobile tree includes patches for v3.12 that will add the #gpio-
ranges-cells to several .dtsi files. I can get that fixed locally (most
probably through a rebase), could you please ping me when this series will be
accepted for upstream merge ?
v2: Squash spear and mxc changes into a single patch; there's no
need to keep vf610.dtsi separate now that this series will go into
v3.12 or later, and that file is part of v3.11-rc1.
---
arch/arm/boot/dts/spear1310.dtsi | 1 -
arch/arm/boot/dts/spear1340.dtsi | 1 -
arch/arm/boot/dts/spear310.dtsi | 1 -
arch/arm/boot/dts/spear320.dtsi | 2 --
arch/arm/boot/dts/vf610.dtsi | 1 -
5 files changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/spear1310.dtsi
b/arch/arm/boot/dts/spear1310.dtsi index 122ae94..90e99b5 100644
--- a/arch/arm/boot/dts/spear1310.dtsi
+++ b/arch/arm/boot/dts/spear1310.dtsi
@@ -89,7 +89,6 @@
pinmux: pinmux@e070 {
compatible = st,spear1310-pinmux;
reg = 0xe070 0x1000;
- #gpio-range-cells = 3;
};
apb {
diff --git a/arch/arm/boot/dts/spear1340.dtsi
b/arch/arm/boot/dts/spear1340.dtsi index 54d128d..5003013 100644
--- a/arch/arm/boot/dts/spear1340.dtsi
+++ b/arch/arm/boot/dts/spear1340.dtsi
@@ -63,7 +63,6 @@
pinmux: pinmux@e070 {
compatible = st,spear1340-pinmux;
reg = 0xe070 0x1000;
- #gpio-range-cells = 3;
};
pwm: pwm@e018 {
diff --git a/arch/arm/boot/dts/spear310.dtsi
b/arch/arm/boot/dts/spear310.dtsi index 9537208..1e1318e 100644
--- a/arch/arm/boot/dts/spear310.dtsi
+++ b/arch/arm/boot/dts/spear310.dtsi
@@ -25,7 +25,6 @@
pinmux: pinmux@b400 {
compatible = st,spear310-pinmux;
reg = 0xb400 0x1000;
- #gpio-range-cells = 3;
};
fsmc: flash@4400 {
diff --git a/arch/arm/boot/dts/spear320.dtsi
b/arch/arm/boot/dts/spear320.dtsi index ffea342..f630d0c 100644
--- a/arch/arm/boot/dts/spear320.dtsi
+++ b/arch/arm/boot/dts/spear320.dtsi
@@ -1,4 +1,3 @@
-/*
* DTS file for SPEAr320 SoC
*
* Copyright 2012 Viresh Kumar viresh.li...@gmail.com
@@ -24,7 +23,6 @@
pinmux: pinmux@b300 {
compatible = st,spear320-pinmux;
reg = 0xb300 0x1000;
- #gpio-range-cells = 3;
};
clcd@9000 {
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index e1eb7da..8577780 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -162,7 +162,6 @@
iomuxc: iomuxc@40048000 {
compatible = fsl,vf610-iomuxc;
reg = 0x40048000 0x1000;
- #gpio-range-cells = 3;
/* functions and groups pins */
--
Regards,
Laurent Pinchart
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
