Re: [PATCH v7 1/9] drivers: phy: add generic PHY framework
On Wednesday 19 June 2013 02:52 AM, Sylwester Nawrocki wrote: Hi Kishon, I've noticed there is a little inconsistency between the code and documentation. On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote: +3. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. + +struct phy *phy_create(struct device *dev, int id, const struct phy_ops *ops, +void *priv); +struct phy *devm_phy_create(struct device *dev, int id, +const struct phy_ops *ops, void *priv); The 'label' argument is missing in those function prototypes. It seems the labels must be unique, I guess this needs to be documented. And do we allow NULL labels ? If so, then there is probably a check for NULL label needed in phy_lookup() and if not, then phy_create() should fail when NULL label is passed ? Yeah. Label is used only for non-dt case so NULL should be allowed while phy_create(). Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 7/9] usb: musb: omap2430: use the new generic PHY framework
Hi, On Mon, Jun 24, 2013 at 11:01:56AM +0530, Kishon Vijay Abraham I wrote: @@ -397,9 +407,10 @@ static int omap2430_musb_init(struct musb *musb) if (glue-status != OMAP_MUSB_UNKNOWN) omap_musb_set_mailbox(glue); - usb_phy_init(musb-xceiv); + phy_init(musb-phy); pm_runtime_put_noidle(musb-controller); + phy_pm_runtime_put(musb-phy); see, weird unbalanced calls :-) Make it all explicit: phy_pm_runtime_get_sync(phy); phy_init(phy); phy_pm_runtime_put(phy); I think then it makes sense to drop get_sync from phy_init()? maybe not, you don't know if the phy has already autosuspended or not. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/3] iio: Add Nuvoton NAU7802 ADC driver
On 06/20/2013 08:57 PM, Alexandre Belloni wrote:
The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
gain and sampling rates.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
.../bindings/iio/adc/nuvoton-nau7802.txt | 17 +
drivers/iio/adc/Kconfig| 9 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/nau7802.c | 603
+
4 files changed, 630 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
create mode 100644 drivers/iio/adc/nau7802.c
diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
new file mode 100644
index 000..9bc4218
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
@@ -0,0 +1,17 @@
+* Nuvoton NAU7802 Analog to Digital Converter (ADC)use
+
+Required properties:
+ - compatible: Should be nuvoton,nau7802
+ - reg: Should contain the ADC I2C address
+
+Optional properties:
+ - nuvoton,vldo: Reference voltage in millivolts (integer)
+ - interrupts: IRQ line for the ADC. If not used the driver will use
+polling.
+
+Example:
+adc2: nau7802@2a {
+ compatible = nuvoton,nau7802;
+ reg = 0x2a;
+ nuvoton,vldo = 3000;
We usually use the regulator framework for specifying the reference voltage.
+};
[...]
diff --git a/drivers/iio/adc/nau7802.c b/drivers/iio/adc/nau7802.c
new file mode 100644
index 000..e1b6981
--- /dev/null
+++ b/drivers/iio/adc/nau7802.c
@@ -0,0 +1,603 @@
[...]
+static int nau7802_set_gain(struct nau7802_state *st, int gain)
+{
+ u8 data;
+ int ret;
+
+ mutex_lock(st-lock);
+ st-conversion_count = 0;
+
+ data = i2c_smbus_read_byte_data(st-client, NAU7802_REG_CTRL1);
+ if (data 0)
+ goto nau7802_sysfs_set_gain_out;
ret will be uninitialized if the goto above is taken
+ ret = i2c_smbus_write_byte_data(st-client, NAU7802_REG_CTRL1,
+ (data (~NAU7802_CTRL1_GAINS_BITS)) |
+ gain);
+
+nau7802_sysfs_set_gain_out:
+ mutex_unlock(st-lock);
+
+ return ret ? ret : 0;
+}
[...]
+static int nau7802_read_irq(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val)
+{
+ struct nau7802_state *st = iio_priv(indio_dev);
+ int ret;
+
+ INIT_COMPLETION(st-value_ok);
+ enable_irq(st-client-irq);
Is it really necessary to enable/disable the IRQ or could you keep it
enabled all the time?
+
+ nau7802_sync(st);
+
+ /* read registers to ensure we flush everything */
+ ret = nau7802_read_conversion(st);
+ if (ret 0)
+ goto read_chan_info_failure;
+
+ /* Wait for a conversion to finish */
+ ret = wait_for_completion_interruptible_timeout(st-value_ok,
+ msecs_to_jiffies(1000));
+ if (ret == 0)
+ ret = -ETIMEDOUT;
+
+ if (ret 0)
+ goto read_chan_info_failure;
+
+ disable_irq(st-client-irq);
+
+ *val = st-last_value;
+
+ return IIO_VAL_INT;
+
+read_chan_info_failure:
+ disable_irq(st-client-irq);
+
+ return ret;
+}
[...]
[...]
+static int nau7802_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct iio_dev *indio_dev;
+ struct nau7802_state *st;
+ struct device_node *np = client-dev.of_node;
+ int i, ret;
+ u8 data;
+ u32 tmp;
+
+ if (!client-dev.of_node) {
+ dev_err(client-dev, No device tree node available.\n);
+ return -EINVAL;
+ }
Except for getting the vref the is no direct dependency on devicetree, if
you switch to the regulator framework for the vref this check can be removed.
[...]
+ /* Setup the ADC channels available on the board */
+ indio_dev-num_channels = 2;
ARRAY_SIZE(nau7802_chan_array)
+ indio_dev-channels = nau7802_chan_array;
+
+ init_completion(st-value_ok);
You need to initialize the completion before requesting the IRQ handler.
[...]
+}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5] serial:st-asc: Add ST ASC driver.
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch adds support to ASC (asynchronous serial controller)
driver, which is basically a standard serial driver. This IP is common
across all the ST parts for settop box platforms.
ASC is embedded in ST COMMS IP block. It supports Rx Tx functionality.
It support all industry standard baud rates.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Stephen Gallimore stephen.gallim...@st.com
CC: Stuart Menefy stuart.men...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
---
Hi Greg,
This patch is the part of the driver support for Sti SOCs.
This patch undergone 3-4 cycles of review in arm-kernel mailing list.
As Arnd prefered to take only SOC support patches via arm-soc, Am
sending this patch seperately.
If its not too late, can you consider this patch for 3.11 via tty tree?
Thanks,
srini
Changes since v4:
- rebased with tty-next branch from git.kernel.org tty repo.
Changes since v3:
- None.
Changes since v2:
- st-asc driver made POSIX compatible based on Russell K comment.
Changes since RFC:
- modified kconfig to remove default y
- removed all the forward declaration.
- use dynamic major numbering.
- merge header-file in to driver.
.../devicetree/bindings/tty/serial/st-asc.txt | 18 +
drivers/tty/serial/Kconfig | 16 +
drivers/tty/serial/Makefile|1 +
drivers/tty/serial/st-asc.c| 939
include/uapi/linux/serial_core.h |3 +
5 files changed, 977 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/st-asc.txt
create mode 100644 drivers/tty/serial/st-asc.c
diff --git a/Documentation/devicetree/bindings/tty/serial/st-asc.txt
b/Documentation/devicetree/bindings/tty/serial/st-asc.txt
new file mode 100644
index 000..75d877f
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/st-asc.txt
@@ -0,0 +1,18 @@
+*st-asc(Serial Port)
+
+Required properties:
+- compatible : Should be st,asc.
+- reg, reg-names, interrupts, interrupt-names : Standard way to define device
+ resources with names. look in
+ Documentation/devicetree/bindings/resource-names.txt
+
+Optional properties:
+- st,hw-flow-ctrl bool flag to enable hardware flow control.
+- st,force-m1 bool flat to force asc to be in Mode-1 recommeded
+ for high bit rates (above 19.2K)
+Example:
+serial@fe44{
+compatible= st,asc;
+reg = 0xfe44 0x2c;
+interrupts = 0 209 0;
+};
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 46dd1c7..4e0a3a6 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1497,6 +1497,22 @@ config SERIAL_FSL_LPUART_CONSOLE
If you have enabled the lpuart serial port on the Freescale SoCs,
you can make it the console by answering Y to this option.
+config SERIAL_ST_ASC
+ tristate ST ASC serial port support
+ select SERIAL_CORE
+ help
+ This driver is for the on-chip Asychronous Serial Controller on
+ STMicroelectronics STi SoCs.
+ ASC is embedded in ST COMMS IP block. It supports Rx Tx
functionality.
+ It support all industry standard baud rates.
+
+ If unsure, say N.
+
+config SERIAL_ST_ASC_CONSOLE
+ bool Support for console on ST ASC
+ depends on SERIAL_ST_ASC=y
+ select SERIAL_CORE_CONSOLE
+
endmenu
endif # TTY
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index cf650f0..47b679c 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_SERIAL_KGDB_NMI) += kgdb_nmi.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
+obj-$(CONFIG_SERIAL_ST_ASC) += st-asc.o
obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
obj-$(CONFIG_SERIAL_TIMBERDALE)+= timbuart.o
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
new file mode 100644
index 000..5edf82f
--- /dev/null
+++ b/drivers/tty/serial/st-asc.c
@@ -0,0 +1,939 @@
+/*
+ * st-asc.c: ST Asynchronous serial controller (ASC) driver
+ *
+ * Copyright (C) 2003-2013 STMicroelectronics (RD) Limited
+ *
+ * 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.
+ *
+ */
+
+#if defined(CONFIG_SERIAL_ST_ASC_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include linux/module.h
+#include linux/serial.h
+#include linux/console.h
+#include
Re: [PATCHv2 11/11] ARM: OMAP4: register DT clocks and remove old data
* Tero Kristo t-kri...@ti.com [130624 00:51]: On 06/21/2013 10:25 AM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [130619 06:25]: Now that the OMAP4 PRCM clock data has been converted to device tree representation, it is no longer needed as static clock data. OMAP4 clock init routine is also changed to register DT clocks first. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 1674 + 1 file changed, 38 insertions(+), 1636 deletions(-) This is nice, thanks for working on this. While at it, can you also keep your eyes open for the register defines in the header files we can also drop? Some of those headers are quite huge.. and should eventually be private to the related drivers if needed at all with DT. Yeah, I can take a look at this after this set is done. It seems like large portion of the headers can be dropped completely once this exercise is done. OK great, thanks. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC v3] media: OF: add video sync endpoint property
Hi Prabhakar,
On Sat June 22 2013 17:03:03 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch adds video sync properties as part of endpoint
properties and also support to parse them in the parser.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans Verkuil hans.verk...@cisco.com
FYI: using my private email when CC-ing me generally works better.
I often skip v4l2-related emails to my work address since I assume those
have either been CC-ed to my private email and/or linux-media.
I wondered why I never saw RFC v1/2, now I know :-)
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
---
This patch has 10 warnings for line over 80 characters
for which I think can be ignored.
RFC v2 https://patchwork.kernel.org/patch/2578091/
RFC V1 https://patchwork.kernel.org/patch/2572341/
Changes for v3:
1: Fixed review comments pointed by Laurent and Sylwester.
.../devicetree/bindings/media/video-interfaces.txt |1 +
drivers/media/v4l2-core/v4l2-of.c | 20 ++
include/dt-bindings/media/video-interfaces.h | 17 +++
include/media/v4l2-mediabus.h | 22
+++-
4 files changed, 50 insertions(+), 10 deletions(-)
create mode 100644 include/dt-bindings/media/video-interfaces.h
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index e022d2d..2081278 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -101,6 +101,7 @@ Optional endpoint properties
array contains only one entry.
- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
clock mode.
+- video-sync: property indicating to sync the video on a signal in RGB.
Please document what the various syncs actually mean.
Example
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..1a54530 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -100,6 +100,26 @@ 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, video-sync, v)) {
+ switch (v) {
+ case V4L2_MBUS_VIDEO_SEPARATE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_SEPARATE_SYNC;
+ break;
+ case V4L2_MBUS_VIDEO_COMPOSITE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_COMPOSITE_SYNC;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_GREEN:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_GREEN;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE;
+ break;
+ }
+ }
+
bus-flags = flags;
}
diff --git a/include/dt-bindings/media/video-interfaces.h
b/include/dt-bindings/media/video-interfaces.h
new file mode 100644
index 000..1a083dd
--- /dev/null
+++ b/include/dt-bindings/media/video-interfaces.h
@@ -0,0 +1,17 @@
+/*
+ * This header provides constants for video interface.
+ *
+ */
+
+#ifndef _DT_BINDINGS_VIDEO_INTERFACES_H
+#define _DT_BINDINGS_VIDEO_INTERFACES_H
+
+#define V4L2_MBUS_VIDEO_SEPARATE_SYNC(1 2)
+#define V4L2_MBUS_VIDEO_COMPOSITE_SYNC (1 3)
+#define V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE(1 4)
What on earth is the difference between COMPOSITE_SYNC and
SYNC_ON_COMPOSITE?!
+#define V4L2_MBUS_VIDEO_SYNC_ON_GREEN(1 5)
+#define V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE(1 6)
+
+#define V4L2_MBUS_VIDEO_INTERFACES_END 6
+
+#endif
Why would this be here? It isn't Device Tree specific, the same defines can
be used without DT as well.
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 83ae07e..a4676dd 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -11,6 +11,8 @@
#ifndef V4L2_MEDIABUS_H
#define V4L2_MEDIABUS_H
+#include
Re: [PATCH v4] clocksource:arm_global_timer: Add ARM global timer support.
Thankyou for the comments.
On 21/06/13 16:56, Thomas Gleixner wrote:
On Fri, 21 Jun 2013, Srinivas KANDAGATLA wrote:
+static void gt_clockevent_set_mode(enum clock_event_mode mode,
+ struct clock_event_device *clk)
+{
+unsigned long ctrl;
+
+ctrl = readl(gt_base + GT_CONTROL);
+switch (mode) {
+case CLOCK_EVT_MODE_PERIODIC:
+gt_compare_set(DIV_ROUND_CLOSEST(gt_clk_rate, HZ), 1);
+break;
+case CLOCK_EVT_MODE_ONESHOT:
+ctrl = ~(GT_CONTROL_AUTO_INC);
You should probably clear the irq enable bit as well. The core will
program the next event right away.
Yep, it makes sense to clear the irq enable and comp enable in this case.
+static irqreturn_t gt_clockevent_interrupt(int irq, void *dev_id)
+{
+struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
What kind of construct is this?
You are using request_percpu_irq() and the device id is pointing to
per cpu memory. Why do you need this horrible pointer indirection?
Because a lot of other ARM code uses the same broken construct?
As Stephen already pointed out,
The reason for such a construct is ARM LOCAL TIMER apis, as ARM local
timer apis allocate struct clock_event_device. If the driver want to
reuse this clock event stucture it needs this double pointer. Which is
why we end up with this code.
On the other hand, The driver can ignore the struct clock_event_device
allocated by the local_timer code, and just use its own per cpu
clock_event which will remove this type of constructs. We do this for
boot cpu. I will go ahead doing this way because local_timer apis are
anyway going to be removed in near future (by Stephen's patch) and its
neat and obvious to manage allocations of clock_event structure with in
the driver.
+static struct clock_event_device __percpu **gt_evt;
+static DEFINE_PER_CPU(struct clock_event_device, gt_clockevent);
So you have compile time allocated clock event device structures and
then you allocate a percpu pointer area which holds pointers to the
static area. Whatfor?
Why not doing the obvious?
static struct clock_event_device __percpu *gt_evt;
gt_evt = alloc_percpu(struct clock_event_device):
request_percpu_irq(.., gt_evt);
And in the interrupt handler
struct clock_event_device *evt = dev_id;
+static int __cpuinit gt_clockevents_init(struct clock_event_device *clk)
+{
+struct clock_event_device **this_cpu_clk;
+int cpu = smp_processor_id();
+
+clk-name = ARM global timer clock event;
No spaces in the names please
Yep, replaced by arm_global_timer
+static int __cpuinit gt_clockevents_setup(struct clock_event_device *clk)
+{
+/* Use existing clock_event for boot cpu */
That comment is telling me what?
Will re-comment it in more detail.
+if (per_cpu(percpu_init_called, smp_processor_id()))
+return 0;
And why do you need another percpu variable, if you can deduce the
same information from clk as well.
return clk-name ? 0 : gt_clockevents_init(clk);
As it get rid of a percpu variable I will change it.
Hmm?
+/* already enabled in gt_clocksource_init. */
Huch?
There is only one enable bit for all the cores in the global_timer IP.
I will add more comments here for clarity.
+return gt_clockevents_init(clk);
+}
+static void __init global_timer_of_register(struct device_node *np)
+{
+gt_clk = of_clk_get(np, 0);
+if (!IS_ERR(gt_clk)) {
+err = clk_prepare_enable(gt_clk);
If that fails, you happily proceed, right?
I think there is a check missing here.
+} else {
+pr_warn(global-timer: clk not found\n);
+err = -EINVAL;
+goto out_unmap;
+}
+
+gt_evt = alloc_percpu(struct clock_event_device *);
+if (!gt_evt) {
+pr_warn(global-timer: can't allocate memory\n);
+err = -ENOMEM;
+goto out_unmap;
Leaves the clock enabled and prepared.
Yes I will fix it by adding new label
out_clk:
clk_disable_unprepare(clk);
+
+gt_clk_rate = clk_get_rate(gt_clk);
+gt_clocksource_init();
+gt_clockevents_init(evt);
+#ifdef CONFIG_LOCAL_TIMERS
+err = local_timer_register(gt_lt_ops);
+if (err) {
+pr_warn(global-timer: unable to register local timer.\n);
+free_percpu_irq(gt_ppi, gt_evt);
+goto out_free;
So that frees your magic pointers, but you still have the clockevent
registered for the boot cpu. The interrupt handler of that device is
happily dereferencing the freed percpu memory.
Yes I agree, there is a error handling issue.
I think, not doing anything in error-case seems to be best option and
most of the drivers do this way. This will at-least leave the clockevent
on boot cpu unaffected and let the system boot. I will with this
approach as it will let the system boot with some
Re: [RFC] pinctrl: generic: Add DT bindings
On Wed, Jun 19, 2013 at 11:58 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/11/2013 04:03 PM, Laurent Pinchart wrote: +- tristate: A boolean, put the pin into high impedance state when set. The other patch defines bias-high-impedance which is more likely to be the string used. Anyway: I don't think that a Boolean is appropriate here; it's really a tri-state: * Nothing is specified about the tristate value; don't touch that aspect of HW. * Turn tristate on. * Turn tristate off. I was thinking more about using bias-disable; to explicitly turn that off. But maybe a specific disable option is needed, like for schmitt-trigger (see below). This can be a meaningful distinction when relying on e.g. the bootloader having already set up the appropriate tristate value, or when dynamically switching between different pinctrl states and not wanting to affect tristate, or when piecing together multiple DT nodes that describe part of a state, where one node covers just muxing and the other just pin config (e.g. where the mux and pin config configuration registers in HW affect different overlapping groups). OK point taken... although when we're dealing with generic pin config the idea is not to cover everything but the majority of not-so-complicated cases. +- schmitt: An integer, enable or disable Schmitt trigger mode for the pins. + Valid values are +0: Schmitt trigger disabled (no hysteresis) +1: Schmitt trigger enabled A similar comment applies here. The other patch adds: input-schmitt-enable; input-schmitt-disable; So this is covered. +- slew-rate: An integer controlling the pin slew rate. Values are device- + dependent. + +- drive-strength: An integer representing the drive strength of pins in mA. + Valid values are device-dependent. I'm still not convinced that requiring this to be in mA is a good idea. Different HW will use different units for documentation, or even specify no units at all, so it might not always be possible to represent this in terms of mA. Asking for the documentation to be re-written simply to support the DT binding just isn't going to happen. We can add custom DT bindings for these. This is to cover those where we know enough about it to actually use this generic binding. If we don't really know what is happening we may as well call it vendor,foo = ?; Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/1] of/documentation: Update s5m8767-regulator bindings document
s5m8767 regulator is used on Exynos platforms which use pin controller to configure GPIOs. Update the example accordingly. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- .../bindings/regulator/s5m8767-regulator.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt index a35ff99..7364f71 100644 --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt @@ -103,13 +103,13 @@ Example: s5m8767,pmic-buck-default-dvs-idx = 0; - s5m8767,pmic-buck-dvs-gpios = gpx0 0 1 0 0, /* DVS1 */ -gpx0 1 1 0 0, /* DVS2 */ -gpx0 2 1 0 0; /* DVS3 */ + s5m8767,pmic-buck-dvs-gpios = gpx0 0 0, /* DVS1 */ +gpx0 1 0, /* DVS2 */ +gpx0 2 0; /* DVS3 */ - s5m8767,pmic-buck-ds-gpios = gpx2 3 1 0 0, /* SET1 */ - gpx2 4 1 0 0, /* SET2 */ - gpx2 5 1 0 0; /* SET3 */ + s5m8767,pmic-buck-ds-gpios = gpx2 3 0, /* SET1 */ + gpx2 4 0, /* SET2 */ + gpx2 5 0; /* SET3 */ s5m8767,pmic-buck2-dvs-voltage = 135, 130, 125, 120, -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/5] pinctrl: clarify some dt pinconfig options
On Thu, Jun 20, 2013 at 12:10 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/14/2013 09:42 AM, Heiko Stübner wrote: diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt -low-power-mode - low power mode +low-power-enable - enable low power mode +low-power-disable- disable low power mode Hmmm. That's changing the binding definition. What if somebody already wrote their device tree according previous definition? It's not merged so see it as alterations to a WIP in the turners workshop or something. It seems to be that tri-states are preferable for pinctrl DT: no entry: do nothing = 0: disable = 1: enable Better with explict enable/disable strings instead of 0 or 1 I think, but the semantic effect would be the same I guess, the upside with *enable/*disable strings is that we do not have to handle cases like tristate = 2; ... +Arguments for parameters: + +- bias-pull-up, -down and -pin-default take as optional argument 0 to disable + the pull, on hardware supporting it the pull strength in Ohm. bias-disable + will also disable any active pull. Does this agree with the latest definition of the kernel-internal meaning of 0 for pull-up/down? No that is wrong. Heiko, care to fix this binding doc? +- input-schmitt takes as argument the adjustable hysteresis in a + driver-specific format + +- input-debounce takes the debounce time as argument or 0 to disable debouncing + +- power-source argument is the custom value describing the source to select + +- slew-rate takes as argument the target rate in a driver-specific format If those things have driver-specific (note: should be DT-binding-specific, not driver-specific) values, then I'm not convinced that having a generic parameter name for them is a good idea; it makes things look the same when they aren't. By forcing each binding to include the vendor prefix on those properties and hence define a custom property name, you're making it clear that the semantics may be different. Hmmm I don't think they're used right now, let's deal with them when we have something to showcase them with. Patches to delete the unclear bindings will be considered... Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] GPIO: Add support for dual channel in gpio-xilinx.c
On Thu, Jun 20, 2013 at 2:12 PM, Michal Simek mon...@monstr.eu wrote: xlnx,is-dual is always present in the HW and in all DTSes and it is generated for several years Based on my experience with hardware guys what happen when they add new channel is that they will use xlnx,is-dual = 2 for 3 channels, xlnx,is-dual = 3 for 4 channels, etc. They won't care about names but they are working like that. It means for me is really problematic it try to work with this value as boolean even that name is confusing. OK I will have to live with this. The problem with reviewing DT bindings is that for me as a subsystem maintainer I'm interacting with a quite complex universe: 1. Bindings from people like the MIPS camp where some people obviously sat down in a committee meeting and tried to define a binding in advance, which is then deployed and we have to support. Sometimes a real nice piece of work such as the PCI hose mappings. 2. Bindings that we need to evolve as part of this community review process, where the judgement of a mapping's applicability and sanity is very much up to the subsystem maintainer. (This is the vast class of bindings.) 3. Bindings that John Doe from Idaho came up with in his basement and then deployed to the entire world, so that we cannot review or amend it but just have to support as they are because they are already live in numerous systems. This would be a case of (3) whereas I'm mostly used to a binding discussion of type (2) and that is why this gets so locked up. That's why it is much easier for me to start to use new property which will describe number of channels but this value is not used in design tools. Let's say number-of-channels = 1 or 2 in DT binding which will describe number channels in this IP. Is this acceptable for you? This is much nicer and readable. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe
Hi! On 05/28/2013 05:08 PM, ext Jean-Christophe PLAGNIOL-VILLARD wrote: Today in the current of implementation we populate all the ressources at of_platform_populate time. But this leed to a chicken-egg dilemat some the irq present in DT are from platform_device too. And you can not resolve them as of_platform_populate. So delay the populate of irq at platform_drv_probe. And if the irq_domain is not yet present just defer the probe (GPIO as example) Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Tested-by: Alexander Sverdlin alexander.sverd...@nsn.com Tested the whole series. This is definitely a necessary feature. I've tested it on MIPS64 system with merge-able device-subtrees. If you would come with the new patch series, please put me on CC, I'll test it again. Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: Arnd Bergmann a...@arndb.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Ralf Baechle r...@linux-mips.org Cc: Nicolas Ferre nicolas.fe...@atmel.com --- drivers/base/platform.c |5 + drivers/of/platform.c | 29 +++-- include/linux/of_platform.h |7 +++ 3 files changed, 39 insertions(+), 2 deletions(-) ... -- Best regards, Alexander Sverdlin. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v13] ARM: edma: Add DT and runtime PM support to the private EDMA API
On 6/21/2013 3:23 PM, Sekhar Nori wrote:
From: Matt Porter mpor...@ti.com
Adds support for parsing the TI EDMA DT data into the required EDMA
private API platform data. Enables runtime PM support to initialize
the EDMA hwmod. Enables build on OMAP.
Changes by Joel:
* Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in [1].
* Split out xbar stuff to separate patch. [1]
* Dropped unused DT helper to convert to array
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter mpor...@ti.com
[nsek...@ti.com: fix checkpatch errors, build breakages. Introduce
edma_setup_info_from_dt() as part of that effort]
Signed-off-by: Joel A Fernandes joelag...@ti.com
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Sekhar Nori nsek...@ti.com
So here is an updated version of this patch after merging your
fix sent over the weekend . I tested the on AM335x, DA850 and
DM644x boards using MMC/SD as the DMA client. With that I think
this has gotten enough testing now and I plan to send a pull
request for this later today and hope we make it in time.
Thanks,
Sekhar
---8---
From 6cba4355066bda19f14d4da66b8abbca0ffdfd59 Mon Sep 17 00:00:00 2001
From: Matt Porter mpor...@ti.com
Date: Thu, 20 Jun 2013 16:06:38 -0500
Subject: [PATCH 3/4] ARM: edma: Add DT and runtime PM support to the private
EDMA API
Adds support for parsing the TI EDMA DT data into the required EDMA
private API platform data. Enables runtime PM support to initialize
the EDMA hwmod. Enables build on OMAP.
Changes by Joel:
* Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in [1].
* Split out xbar stuff to separate patch. [1]
* Dropped unused DT helper to convert to array
* Fixed dangling pointer issue with Sekhar's changes
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter mpor...@ti.com
[nsek...@ti.com: fix checkpatch errors, build breakages. Introduce
edma_setup_info_from_dt() as part of that effort]
Signed-off-by: Joel A Fernandes joelag...@ti.com
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/common/edma.c| 186 +++--
arch/arm/mach-davinci/devices-da8xx.c |8 +-
arch/arm/mach-davinci/devices-tnetv107x.c |4 +-
arch/arm/mach-davinci/dm355.c |4 +-
arch/arm/mach-davinci/dm365.c |4 +-
arch/arm/mach-davinci/dm644x.c|4 +-
arch/arm/mach-davinci/dm646x.c|4 +-
include/linux/platform_data/edma.h|4 +-
8 files changed, 189 insertions(+), 29 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 7658874..5183a31 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -25,6 +25,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -1369,13 +1376,110 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
-/*---*/
+#if IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_DMADEVICES)
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0, i;
+ u32 value;
+ struct edma_rsv_info *rsv_info;
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, dma-channels, value);
+ if (ret 0)
+ return ret;
+ pdata-n_channel = value;
+
+ ret = of_property_read_u32(node, ti,edma-regions, value);
+ if (ret 0)
+ return ret;
+ pdata-n_region = value;
+
+ ret = of_property_read_u32(node, ti,edma-slots, value);
+ if (ret 0)
+ return ret;
+ pdata-n_slot = value;
+
+ pdata-n_cc = 1;
+
+ rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata-rsv = rsv_info;
+
+ queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i 3; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata-queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i 3; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
Re: [PATCH v12 04/11] dmaengine: edma: enable build for AM33XX
* Sekhar Nori nsek...@ti.com [130621 03:21]: On 6/21/2013 2:36 AM, Joel A Fernandes wrote: From: Matt Porter mpor...@ti.com Enable TI EDMA option on OMAP and TI_PRIV_EDMA Signed-off-by: Matt Porter mpor...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com This will have to be taken by Tony. Sekhar, please go ahead and take this one. I'll reply to the header email of this series how it should be queued. For the mach-omap2/Kconfig change: Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |1 + drivers/dma/Kconfig |2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..f91b07f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS select PROC_DEVICETREE if PROC_FS select SOC_BUS select SPARSE_IRQ + select TI_PRIV_EDMA select USE_OF help Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e992489..3215a3c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -213,7 +213,7 @@ config SIRF_DMA config TI_EDMA tristate TI EDMA support - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
Hi, For merging this series, I suggest the following sets: * Joel A Fernandes joelag...@ti.com [130620 14:13]: Joel A Fernandes (3): edma: config: Enable config options for EDMA da8xx: config: Enable MMC and FS options ARM: davinci: Fix compiler warnings in devices-da8xx Matt Porter (8): dmaengine: edma: Add TI EDMA device tree binding ARM: edma: Add DT and runtime PM support to the private EDMA API ARM: edma: Add EDMA crossbar event mux support dmaengine: edma: enable build for AM33XX Sekhar should queue the above patches, I've acked the mach-omap2/Kconfig change. spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support Benoit should queue the .dts changes. Documentation/devicetree/bindings/dma/ti-edma.txt | 34 +++ Documentation/devicetree/bindings/spi/omap-spi.txt | 27 ++- arch/arm/Kconfig |1 + arch/arm/boot/dts/am33xx.dtsi | 22 ++ arch/arm/common/edma.c | 242 ++-- arch/arm/configs/da8xx_omapl_defconfig |3 + arch/arm/mach-davinci/devices-da8xx.c |8 +- arch/arm/mach-omap2/Kconfig|2 + drivers/dma/Kconfig|4 +- drivers/spi/spi-omap2-mcspi.c | 64 -- include/linux/platform_data/edma.h |5 +- 11 files changed, 369 insertions(+), 43 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 04/11] dmaengine: edma: enable build for AM33XX
On 6/24/2013 3:47 PM, Tony Lindgren wrote: * Sekhar Nori nsek...@ti.com [130621 03:21]: On 6/21/2013 2:36 AM, Joel A Fernandes wrote: From: Matt Porter mpor...@ti.com Enable TI EDMA option on OMAP and TI_PRIV_EDMA Signed-off-by: Matt Porter mpor...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com This will have to be taken by Tony. Sekhar, please go ahead and take this one. I'll reply to the header email of this series how it should be queued. For the mach-omap2/Kconfig change: Acked-by: Tony Lindgren t...@atomide.com Thanks Tony. Added to v3.11/soc-2 branch with your and Arnd's acks included. Vinod, it will be nice to get your ack too for the drivers/dma/Kconfig change. Regards, Sekhar --- arch/arm/mach-omap2/Kconfig |1 + drivers/dma/Kconfig |2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..f91b07f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS select PROC_DEVICETREE if PROC_FS select SOC_BUS select SPARSE_IRQ + select TI_PRIV_EDMA select USE_OF help Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e992489..3215a3c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -213,7 +213,7 @@ config SIRF_DMA config TI_EDMA tristate TI EDMA support - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] usb: dwc3: use extcon fwrk to receive connect/disconnect
On 06/21/2013 08:58 PM, Kishon Vijay Abraham I wrote:
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Chanwoo Choi cw00.c...@samsung.com
---
This patch should be applied after all of the extcon patchset will be applied
because this patch has dependency of extcon patch related to DT.
http://goo.gl/Tu3qW
Changes from v4:
* checked the return values of extcon_register_interest and print an error
message. Note that I dint do return since there might be cases where
one of USB (device mode) or USB-HOST (host mode) might succeed.
* Added depends on of EXTCON in usb_dwc3. Only some platforms might
be using EXTCON, but inorder to avoid compilation errors, added
depends on
Changes from v3:
* did #include of of_extcon.h after Chanwoo resent the patch separating
extcon-class.c from of_extcon.c
Changes from v2:
* updated the Documentation with dwc3 dt binding information.
* used of_extcon_get_extcon_dev to get extcon device from device tree data.
Changes from v1:
* regulator enable/disable is now done here instead of palmas-usb as some
users
of palmas-usb wont need regulator.
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/dwc3-omap.c | 125
+---
include/linux/usb/dwc3-omap.h | 30 -
4 files changed, 112 insertions(+), 49 deletions(-)
delete mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..f1c15f3 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -53,6 +53,11 @@ OMAP DWC3 GLUE
It should be set to 1 for HW mode and 2 for SW mode.
- ranges: the child address space are mapped 1:1 onto the parent address
space
+Optional Properties:
+ - extcon : phandle for the extcon device omap dwc3 uses to detect
+ connect/disconnect events.
+ - vbus-supply : phandle to the regulator device tree node if needed.
+
Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 757aa18..08a9fab 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,7 @@
config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) GENERIC_HARDIRQS
+ depends on EXTCON
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f8f76e6..80b5780 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,13 +43,15 @@
#include linux/spinlock.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-omap.h
-#include linux/usb/dwc3-omap.h
#include linux/pm_runtime.h
#include linux/dma-mapping.h
#include linux/ioport.h
#include linux/io.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/extcon.h
+#include linux/extcon/of_extcon.h
+#include linux/regulator/consumer.h
#include linux/usb/otg.h
@@ -124,9 +126,21 @@ struct dwc3_omap {
u32 utmi_otg_status;
u32 dma_status:1;
+
+ struct extcon_specific_cable_nb extcon_vbus_dev;
+ struct extcon_specific_cable_nb extcon_id_dev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+
+ struct regulator*vbus_reg;
};
-static struct dwc3_omap *_omap;
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_VBUS_OFF,
+ OMAP_DWC3_VBUS_VALID,
+};
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
@@ -138,18 +152,23 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
-int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
+ enum omap_dwc3_vbus_id_status status)
{
- u32 val;
- struct dwc3_omap*omap = _omap;
-
- if (!omap)
- return -EPROBE_DEFER;
+ int ret;
+ u32 val;
switch (status) {
case OMAP_DWC3_ID_GROUND:
dev_dbg(omap-dev, ID GND\n);
+ if (omap-vbus_reg) {
+ ret = regulator_enable(omap-vbus_reg);
+ if (ret) {
+ dev_dbg(omap-dev, regulator enable
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On 6/22/2013 3:23 AM, Joel A Fernandes wrote: Hi Arnd, On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 21 June 2013, Joel A Fernandes wrote: I think we are talking about different things, I agree the 'select DMADEVICES' can be dropped but lets please keep the default y option (not adding new select statements, just saying that if someone select DMADEVICES in menuconfig and if they're ARCH_OMAP=1 , then default to EDMA). This will simply allow people to have a default. Thanks. Yes, that's ok. Ok, thanks. I will follow up with a patch in my next submissions that builds it. Perhaps a: default y if 'ARCH_OMAP2PLUS' and leave the existing as it is... default n if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2' would make most sense to me. Basically EDMA is seen on current and all new OMAP2PLUS. OMAP2PLUS devices like OMAP3/4 do not have EDMA so this is not really true. config TI_EDMA tristate TI EDMA support default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2 select DMA_ENGINE select DMA_VIRTUAL_CHANNELS MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The 'm' option will require some initramfs to load the module when needing to MMC boot, I suggest lets leave it as y. But there is no reason why it cannot work with PIO, right? Sounds like the right fix is in driver. Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On 6/24/2013 4:53 PM, Sekhar Nori wrote: On 6/22/2013 3:23 AM, Joel A Fernandes wrote: Hi Arnd, On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 21 June 2013, Joel A Fernandes wrote: I think we are talking about different things, I agree the 'select DMADEVICES' can be dropped but lets please keep the default y option (not adding new select statements, just saying that if someone select DMADEVICES in menuconfig and if they're ARCH_OMAP=1 , then default to EDMA). This will simply allow people to have a default. Thanks. Yes, that's ok. Ok, thanks. I will follow up with a patch in my next submissions that builds it. Perhaps a: default y if 'ARCH_OMAP2PLUS' and leave the existing as it is... default n if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2' would make most sense to me. Basically EDMA is seen on current and all new OMAP2PLUS. OMAP2PLUS devices like OMAP3/4 do not have EDMA so this is not really true. More accurately, there is EDMA hardware on these devices, but its usage is limited to DSP. ARM uses SDMA instead. Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
Sourav, On 6/24/2013 3:49 PM, Tony Lindgren wrote: Hi, For merging this series, I suggest the following sets: * Joel A Fernandes joelag...@ti.com [130620 14:13]: spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. Can you please send just the DT binding patch above to Mark's correct address with the relevant lists copied. Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] MFD: Palmas: Add TPS659038 PMIC support
Hi, On Thu, Jun 20, 2013 at 04:35:16PM +0530, J Keerthy wrote: The Patch adds TPS659038 PMIC support in the palmas mfd driver. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/palmas.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 3/3] ARM: davinci: da850: adopt to pinctrl-single driver to configure multiple pins
Hi Sekhar,
On Tue, May 21, 2013 at 19:38:02, Manjunathappa, Prakash wrote:
function-mask property is a mask for a pin at each pin configure offset
in a pincontrol register.
Got 1/3 and 2/3 accepted, I do not know if this gets merged via DaVinci tree or
pincontrol tree. Could you please takecare of this?
Thanks,
Prakash
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
---
arch/arm/boot/dts/da850.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4d43046..9bec36c 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -37,7 +37,7 @@
#size-cells = 0;
pinctrl-single,bit-per-mux;
pinctrl-single,register-width = 32;
- pinctrl-single,function-mask = 0x;
+ pinctrl-single,function-mask = 0xf;
status = disabled;
nand_cs3_pins: pinmux_nand_pins {
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
On Monday 24 June 2013 05:09 PM, Sekhar Nori wrote: Sourav, On 6/24/2013 3:49 PM, Tony Lindgren wrote: Hi, For merging this series, I suggest the following sets: * Joel A Fernandesjoelag...@ti.com [130620 14:13]: spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. Can you please send just the DT binding patch above to Mark's correct address with the relevant lists copied. Thanks, Sekhar Sure. Will send that. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On 6/22/2013 8:23 AM, Joel A Fernandes wrote:
config TI_EDMA
tristate TI EDMA support
default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
'm' option will require some initramfs to load the module when needing
to MMC boot, I suggest lets leave it as y.
Ah, right: you still export a filter function from the edma driver
and use it in slave drivers:
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_rx = dma_request_channel(mask,
edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_tx = dma_request_channel(mask,
edma_filter_fn,
As long as this is the case, you have to be careful with the dependencies
to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or
edma_filter_fn gets defined to NULL when you are building for a DT-only
platform.
Yes sure, right now they are defined as follows in include/linux/edma.h:
#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
bool edma_filter_fn(struct dma_chan *, void *);
#else
static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
{
return false;
}
#endif
This also has the side effect of causing DMA requests to fail if
TI_EDMA is not built, causing frustration for a lot of people some of
whom don't want to deal with DMA so I think it is OK to build the
driver in by default as it is (and will be) used by a lot of
OMAP2PLUS.
Solution for this is to enable TI_EDMA in relevant defconfigs. Most
folks who would get frustrated by such issues would be using defconfigs
and for those who are building their configuration from scratch this
will be pretty low in their list of worries.
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 6/6] DT: Add documentation for gpio-xilinx
Hi Linus, On 06/17/2013 11:13 AM, Linus Walleij wrote: On Mon, Jun 17, 2013 at 8:21 AM, Michal Simek mon...@monstr.eu wrote: On 06/17/2013 07:50 AM, Linus Walleij wrote: On Mon, Jun 3, 2013 at 2:31 PM, Michal Simek michal.si...@xilinx.com wrote: +- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode +- xlnx,is-dual : if 1, controller also uses the second channel If is present, xlnx,is-dual; + xlnx,is-dual = 0x1; xlnx,is-dual; I'm not giving up on this suggestion. I have commented this in the v1. I commented your comment on v1, and said I think you can support both bindings. in 2/6 you have applied that dual support for this driver and that's why please add this binding description to your repo because it reflects actual binding for this driver. As I wrote you I am working on interrupt support for this IP and in connection to this I will introduce new binding as we discussed in v1. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 03/10] pinctrl:st: Add pinctrl and pinconf support.
On Fri, Jun 21, 2013 at 3:41 PM, Srinivas KANDAGATLA srinivas.kandaga...@st.com wrote: Hi Linus W, If its not too late can this patch be considered for 3.11 via pinctrl tree? There is a build dependecy with regmap_field apis pulled by Mark Brown in regmap repository. This seems fairly complete, but I cannot have such a basic dependency onto the regmap tree this late in the merge window, i.e. I'm not ready to pull all of regmap into the pinctrl tree. I'd consider this for merging for the next kernel cycle so it's more orthogonal. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv12] spi: omap2-mcspi: add generic DMA request support to the DT binding
From: Matt Porter mpor...@ti.com
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas. The string naming
+ is to be rxN and txN for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = 1;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = 4;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = ti,omap4-mcspi;
+ti,hwmods = mcspi1;
+ti,spi-num-cs = 2;
+dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+dma-names = tx0, rx0, tx1, rx1;
+};
--
1.7.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/7] of: introduce of_parse_phandle_with_fixed_args
On Sat, Jun 22, 2013 at 12:44 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 06/13/2013 02:59 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This is identical to of_parse_phandle_with_args(), except that the number of argument cells is fixed, rather than being parsed out of the node referenced by each phandle. Rob, Grant, are you OK with these two DT patches? LinusW would like an ack so he can take the series, which implements gpio-ranges property parsing cleanup, through the GPIO tree. Thanks. Yeah ping on this, it's a real nice cleanup. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/8] ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
Hi Tomasz,
Thanks for the review.
On 06/23/2013 12:12 PM, Tomasz Figa wrote:
On Friday 21 of June 2013 14:50:17 Sylwester Nawrocki wrote:
Add separate nodes for the CAMCLK pin and turn off pull-up on camera
ports A, B. The video bus pins and the clock output (CAMCLK) pin need
separate nodes since full camera port is not used in some
configurations, e.g. for MIPI CSI-2 bus only CAMCLK is required and
data/clock signal use separate dedicated pins.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 40
- 1 file changed, 33 insertions(+), 7
deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi index 704290f..50eaa95
100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,13 +401,26 @@
samsung,pin-drv = 0;
};
-cam_port_a: cam-port-a {
+cam_port_a_io: cam-port-a-io {
samsung,pins = gpj0-0, gpj0-1, gpj0-2,
gpj0-3,
gpj0-4, gpj0-5, gpj0-6,
gpj0-7,
-gpj1-0, gpj1-1, gpj1-2,
gpj1-3,
-gpj1-4;
+gpj1-0, gpj1-1, gpj1-2,
gpj1-4;
samsung,pin-function = 2;
-samsung,pin-pud = 3;
+samsung,pin-pud = 0;
+samsung,pin-drv = 0;
+};
+
+cam_port_a_clk_active: cam-port-a-clk-active {
+samsung,pins = gpj1-3;
+samsung,pin-function = 2;
+samsung,pin-pud = 0;
+samsung,pin-drv = 3;
+};
+
+cam_port_a_clk_idle: cam-port-a-clk-idle {
+samsung,pins = gpj1-3;
+samsung,pin-function = 0;
+samsung,pin-pud = 0;
samsung,pin-drv = 0;
Who is driving the clock line in this configuration? Idle would suggest
that neither the camera nor the camif, so I think some pull should be
enabled to avoid floating pin. (Or is there an external pulling resistor
for this line in most common setups?)
In normal operation it is the AP SoC that feeds the clock to an external
image sensor. And the 'idle' pinctrl state is meant for a state where
the sensor is powered down completely or is in a suspend state that does
not require the sensor's master clock to be provided.
I took this configuration directly from the SoC vendor kernels, but it
indeed seems more appropriate to enable pull down on these pins in idle
state to avoid floating pins. If anything else is needed relevant
pinctrl nodes could be overridden in a board dts file.
I will update this and resend with pull down enabled.
Thanks,
Sylwester
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 03/10] pinctrl:st: Add pinctrl and pinconf support.
On 24/06/13 12:57, Linus Walleij wrote: On Fri, Jun 21, 2013 at 3:41 PM, Srinivas KANDAGATLA srinivas.kandaga...@st.com wrote: Hi Linus W, If its not too late can this patch be considered for 3.11 via pinctrl tree? There is a build dependecy with regmap_field apis pulled by Mark Brown in regmap repository. This seems fairly complete, but I cannot have such a basic dependency onto the regmap tree this late in the merge window, i.e. I'm not ready to pull all of regmap into the pinctrl tree. I'd consider this for merging for the next kernel cycle so it's more orthogonal. Hmmm.. You mean 3.12* Am not sure, But.. Is it possible to make just regmap field api patch go via pinctrl tree, as Mark Brow has already accepted it. Ideally, It would be nice this patch to be part of 3.11-* as, Arnd already pushed SOC support changes to his next branch. thanks, srini Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: imx27: Fix documentation for SPLL clock
On Sun, Jun 23, 2013 at 10:51:10AM +0200, Markus Pargmann wrote: spll_gate was added with commit b7eed2076183994dbda2c19bc7fba99b65a135e3 ARM: imx27: add a clock gate to activate SPLL clock. spll_gate is missing in the devicetree clock documentation for imx27. This patch adds it to the list of clocks in the documentation. Signed-off-by: Markus Pargmann m...@pengutronix.de Applied, thanks. Shawn --- Documentation/devicetree/bindings/clock/imx27-clock.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt index ab1a56e..7a20703 100644 --- a/Documentation/devicetree/bindings/clock/imx27-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt @@ -98,6 +98,7 @@ clocks and IDs. fpm 83 mpll_osc_sel 84 mpll_sel 85 + spll_gate86 Examples: -- 1.8.2.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/4] gpio-tz1090: add TZ1090 gpio driver
On Thu, 20 Jun 2013 10:26:28 +0100, James Hogan james.ho...@imgtec.com wrote:
Add a GPIO driver for the main GPIOs found in the TZ1090 (Comet) SoC.
This doesn't include low-power GPIOs as they're controlled separately
via the Powerdown Controller (PDC) registers.
The driver is instantiated by device tree and supports interrupts for
all GPIOs.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
---
Changes in v3:
- separated from irq-imgpdc and removed arch/metag changes to allow
these patches to go upstream separately via the pinctrl[/gpio] trees
(particularly the pinctrl drivers depend on the new pinconf DT
bindings).
- some s/unsigned/unsigned int/.
- some s/unsigned int/bool/ and use of BIT().
- gpio-tz1090*: refer to dt-bindings/gpio/gpio.h and
dt-bindings/interrupt-controller/irq.h flags in bindings.
- gpio-tz1090*: move initcall from postcore to subsys.
- gpio-tz1090: add REG_ prefix to some constants for consistency.
- gpio-tz1090: add comment to explain tz1090_gpio_irq_next_edge
cunningness.
Changes in v2:
- gpio-tz1090: remove references to Linux flags in dt bindings
- gpio-tz1090: make use of BIT() from linux/bitops.h
- gpio-tz1090: make register accessors inline to match pinctrl
- gpio-tz1090: update gpio-ranges to use 3 cells after recent ABI
breakage
.../devicetree/bindings/gpio/gpio-tz1090.txt | 87 +++
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-tz1090.c | 633
+
4 files changed, 728 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tz1090.txt
create mode 100644 drivers/gpio/gpio-tz1090.c
diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt
b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt
new file mode 100644
index 000..e017d4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt
@@ -0,0 +1,87 @@
+ImgTec TZ1090 GPIO Controller
+
+Required properties:
+- compatible: Compatible property value should be img,tz1090-gpio.
typo at end of line
+
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+
+- #address-cells: Should be 1 (for bank subnodes)
+
+- #size-cells: Should be 0 (for bank subnodes)
+
+- Each bank of GPIOs should have a subnode to represent it.
+
+ Bank subnode required properties:
+ - reg: Index of bank in the range 0 to 2.
+
+ - gpio-controller: Specifies that the node is a gpio controller.
+
+ - #gpio-cells: Should be 2. The syntax of the gpio specifier used by client
+nodes should have the following values.
+ [phandle of the gpio controller node]
+[gpio number within the gpio bank]
+[gpio flags]
+
+Values for gpio specifier:
+- GPIO number: a value in the range 0 to 29.
+- GPIO flags: bit field of flags, as defined in
dt-bindings/gpio/gpio.h.
+ Only the following flags are supported:
+GPIO_ACTIVE_HIGH
+GPIO_ACTIVE_LOW
+
+ Bank subnode optional properties:
+ - gpio-ranges: Mapping to pin controller pins
This is specific to this binding. To avoid namespace colisions, add a
img, prefix to the property name.
+
+ - interrupts: Interrupt for the entire bank
+
+ - interrupt-controller: Specifies that the node is an interrupt controller
+
+ - #interrupt-cells: Should be 2. The syntax of the interrupt specifier
used by
+client nodes should have the following values.
+ [phandle of the interurupt controller]
+[gpio number within the gpio bank]
+[irq flags]
+
+Values for irq specifier:
+- GPIO number: a value in the range 0 to 29
+- IRQ flags: value to describe edge and level triggering, as defined in
+ dt-bindings/interrupt-controller/irq.h. Only the following flags are
+ supported:
+IRQ_TYPE_EDGE_RISING
+IRQ_TYPE_EDGE_FALLING
+IRQ_TYPE_EDGE_BOTH
+IRQ_TYPE_LEVEL_HIGH
+IRQ_TYPE_LEVEL_LOW
+
+
+
+Example:
+
+ gpios: gpio-controller@02005800 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = img,tz1090-gpio;
+ reg = 0x02005800 0x90;
+
+ /* bank 0 with an interrupt */
+ gpios0: bank@0 {
+ #gpio-cells = 2;
+ #interrupt-cells = 2;
+ reg = 0;
+ interrupts = 13 IRQ_TYPE_LEVEL_HIGH;
+ gpio-controller;
+ gpio-ranges = pinctrl 0 30;
+ interrupt-controller;
+ };
+
+
Re: [PATCH v3 03/10] pinctrl:st: Add pinctrl and pinconf support.
On Mon, Jun 24, 2013 at 01:57:56PM +0200, Linus Walleij wrote: This seems fairly complete, but I cannot have such a basic dependency onto the regmap tree this late in the merge window, i.e. I'm not ready to pull all of regmap into the pinctrl tree. I'd consider this for merging for the next kernel cycle so it's more orthogonal. I've got the patch on a topic branch in regmap to allow for this sort of stuff - I can readily provide a signed tag for you to get just that patch if that'd help? Alternatively I'm happy to carry the pinctrl patch in regmap? signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/4] gpio-tz1090: add TZ1090 gpio driver
On 24/06/13 14:34, Grant Likely wrote:
On Thu, 20 Jun 2013 10:26:28 +0100, James Hogan james.ho...@imgtec.com
wrote:
diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt
b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt
new file mode 100644
index 000..e017d4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt
@@ -0,0 +1,87 @@
+ImgTec TZ1090 GPIO Controller
+
+Required properties:
+- compatible: Compatible property value should be img,tz1090-gpio.
typo at end of line
Yes, I'll fix in gpio-tz1090-pdc driver bindings too
+ Bank subnode optional properties:
+ - gpio-ranges: Mapping to pin controller pins
This is specific to this binding. To avoid namespace colisions, add a
img, prefix to the property name.
This property is described in
Documentation/devicetree/bindings/gpio/gpio.txt... (and my examples are
out of date from when the gpio offset cell was added in v3.10). I'll add
a reference to that Document.
+/* GPIO chip callbacks */
+
+static int tz1090_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+struct tz1090_gpio_bank *bank = to_bank(chip);
+tz1090_gpio_set_bit(bank, REG_GPIO_DIR, offset);
+
+return 0;
+}
+
+static int tz1090_gpio_direction_output(struct gpio_chip *chip,
+unsigned int offset, int output_value)
+{
+struct tz1090_gpio_bank *bank = to_bank(chip);
+int lstat;
+
+__global_lock2(lstat);
+_tz1090_gpio_mod_bit(bank, REG_GPIO_DOUT, offset, output_value);
+_tz1090_gpio_clear_bit(bank, REG_GPIO_DIR, offset);
+__global_unlock2(lstat);
+
+return 0;
+}
+
+/*
+ * Return GPIO level
+ */
+static int tz1090_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+struct tz1090_gpio_bank *bank = to_bank(chip);
+
+return tz1090_gpio_read_bit(bank, REG_GPIO_DIN, offset);
+}
+
+/*
+ * Set output GPIO level
+ */
+static void tz1090_gpio_set(struct gpio_chip *chip, unsigned int offset,
+int output_value)
+{
+struct tz1090_gpio_bank *bank = to_bank(chip);
+
+tz1090_gpio_mod_bit(bank, REG_GPIO_DOUT, offset, output_value);
+}
+
+static int tz1090_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+struct tz1090_gpio_bank *bank = to_bank(chip);
+int ret;
+
+ret = pinctrl_request_gpio(chip-base + offset);
+if (ret)
+return ret;
+
+tz1090_gpio_set_bit(bank, REG_GPIO_DIR, offset);
+tz1090_gpio_set_bit(bank, REG_GPIO_BIT_EN, offset);
+
+return 0;
+}
Is it possible to use the gpio-generic.c hooks for manipulating the
gpio bits?
Due to the unfortunate necessity to use the __global_lock2 functions
(for atomic accesses between different non-linux threads/cores) I don't
think this is possible.
+/* IRQ chip handlers */
+
+/* Get TZ1090 GPIO chip from irq data provided to generic IRQ callbacks */
+static inline struct tz1090_gpio_bank *irqd_to_gpio_bank(struct irq_data
*data)
+{
+return (struct tz1090_gpio_bank *)data-domain-host_data;
+}
+
+static void tz1090_gpio_irq_clear(struct tz1090_gpio_bank *bank,
+ unsigned int offset)
+{
+tz1090_gpio_clear_bit(bank, REG_GPIO_IRQ_STS, offset);
+}
+
+static void tz1090_gpio_irq_enable(struct tz1090_gpio_bank *bank,
+ unsigned int offset, bool enable)
+{
+tz1090_gpio_mod_bit(bank, REG_GPIO_IRQ_EN, offset, enable);
+}
+
+static void tz1090_gpio_irq_polarity(struct tz1090_gpio_bank *bank,
+ unsigned int offset, unsigned int polarity)
+{
+tz1090_gpio_mod_bit(bank, REG_GPIO_IRQ_PLRT, offset, polarity);
+}
+
+static int tz1090_gpio_valid_handler(struct irq_desc *desc)
+{
+return desc-handle_irq == handle_level_irq ||
+desc-handle_irq == handle_edge_irq;
+}
+
+static void tz1090_gpio_irq_type(struct tz1090_gpio_bank *bank,
+ unsigned int offset, unsigned int type)
+{
+tz1090_gpio_mod_bit(bank, REG_GPIO_IRQ_TYPE, offset, type);
+}
+
+/* set polarity to trigger on next edge, whether rising or falling */
+static void tz1090_gpio_irq_next_edge(struct tz1090_gpio_bank *bank,
+ unsigned int offset)
+{
+unsigned int value_p, value_i;
+int lstat;
+
+/*
+ * Set the GPIO's interrupt polarity to the opposite of the current
+ * input value so that the next edge triggers an interrupt.
+ */
+__global_lock2(lstat);
+value_i = ~tz1090_gpio_read(bank, REG_GPIO_DIN);
+value_p = tz1090_gpio_read(bank, REG_GPIO_IRQ_PLRT);
+value_p = ~BIT(offset);
+value_p |= value_i BIT(offset);
+tz1090_gpio_write(bank, REG_GPIO_IRQ_PLRT, value_p);
+__global_unlock2(lstat);
+}
+
+static void gpio_ack_irq(struct irq_data *data)
+{
+struct tz1090_gpio_bank *bank
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Mon, Jun 24, 2013 at 6:53 AM, Sekhar Nori nsek...@ti.com wrote:
On 6/22/2013 8:23 AM, Joel A Fernandes wrote:
config TI_EDMA
tristate TI EDMA support
default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
'm' option will require some initramfs to load the module when needing
to MMC boot, I suggest lets leave it as y.
Ah, right: you still export a filter function from the edma driver
and use it in slave drivers:
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_rx = dma_request_channel(mask,
edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_tx = dma_request_channel(mask,
edma_filter_fn,
As long as this is the case, you have to be careful with the dependencies
to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or
edma_filter_fn gets defined to NULL when you are building for a DT-only
platform.
Yes sure, right now they are defined as follows in include/linux/edma.h:
#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
bool edma_filter_fn(struct dma_chan *, void *);
#else
static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
{
return false;
}
#endif
This also has the side effect of causing DMA requests to fail if
TI_EDMA is not built, causing frustration for a lot of people some of
whom don't want to deal with DMA so I think it is OK to build the
driver in by default as it is (and will be) used by a lot of
OMAP2PLUS.
Solution for this is to enable TI_EDMA in relevant defconfigs. Most
folks who would get frustrated by such issues would be using defconfigs
and for those who are building their configuration from scratch this
will be pretty low in their list of worries.
Yes, it is not in omap2plus_defconfig either. I will post a patch to
add it to the same, and we can ignore the Kconfig defaults and select
patches.
Thanks,
Joel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/4] pinctrl-tz1090: add TZ1090 pinctrl driver
On Thu, Jun 20, 2013 at 11:26 AM, James Hogan james.ho...@imgtec.com wrote: Add a pin control driver for the main pins on the TZ1090 SoC. This doesn't include the low-power pins as they're controlled separately via the Powerdown Controller (PDC) registers. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-...@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org --- Changes in v3: - separated from irq-imgpdc and removed arch/metag changes to allow these patches to go upstream separately via the pinctrl[/gpio] trees (particularly the pinctrl drivers depend on the new pinconf DT bindings). - some s/unsigned/unsigned int/. - some s/unsigned int/bool/ and use of BIT(). - pinctrl-tz1090*: switch to generic pinconfig DT bindings and pinconf_generic_dump_config. - pinctrl-tz1090*: use tz1090, prefix for pins and function in DT bindings. - pinctrl-tz1090*: make internal functions static. - pinctrl-tz1090*: move initcall from postcore to arch. Thanks James, patch applied. Also thanks for helping out in getting the generic pinconf in place for some three different drivers for this merge window, this was very good for pinctrl at large. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 3/4] pinctrl-tz1090-pdc: add TZ1090 PDC pinctrl driver
On Thu, Jun 20, 2013 at 11:26 AM, James Hogan james.ho...@imgtec.com wrote: Add a pin control driver for the TZ1090's low power pins via the powerdown controller SOC_GPIO_CONTROL registers. These pins have individually controlled pull-up, and group controlled schmitt, slew-rate, drive-strength, and power-on-start (pos). The pdc_gpio0 and pdc_gpio1 pins can also be muxed onto the ir_mod_stable_out and ir_mod_power_out functions respectively. If no function is set they remain in GPIO mode. These muxes can be overridden by requesting them as GPIOs. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-...@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org --- Changes in v3: - separated from irq-imgpdc and removed arch/metag changes to allow these patches to go upstream separately via the pinctrl[/gpio] trees (particularly the pinctrl drivers depend on the new pinconf DT bindings). - some s/unsigned/unsigned int/. - pinctrl-tz1090*: switch to generic pinconfig DT bindings and pinconf_generic_dump_config. - pinctrl-tz1090*: use tz1090, prefix for pins and function in DT bindings. - pinctrl-tz1090*: make internal functions static. - pinctrl-tz1090*: move initcall from postcore to arch. Thanks, patch applied as well. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv12] spi: omap2-mcspi: add generic DMA request support to the DT binding
On Mon, Jun 24, 2013 at 05:31:59PM +0530, Sourav Poddar wrote: The binding definition is based on the generic DMA request binding 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 4/4] gpio-tz1090-pdc: add TZ1090 PDC gpio driver
On Thu, Jun 20, 2013 at 11:26 AM, James Hogan james.ho...@imgtec.com wrote: Add a GPIO driver for the low-power Powerdown Controller GPIOs in the TZ1090 SoC. The driver is instantiated by device tree and supports interrupts for the SysWake GPIOs only. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-...@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org --- Changes in v3: - separated from irq-imgpdc and removed arch/metag changes to allow these patches to go upstream separately via the pinctrl[/gpio] trees (particularly the pinctrl drivers depend on the new pinconf DT bindings). - some s/unsigned/unsigned int/. - gpio-tz1090*: refer to dt-bindings/gpio/gpio.h and dt-bindings/interrupt-controller/irq.h flags in bindings. - gpio-tz1090*: move initcall from postcore to subsys. I'll be happy to apply the GPIO patches to the pinctrl tree as well once you fixed the comments on patch 2 from Grant. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/documentation: Update s5m8767-regulator bindings document
On Mon, Jun 24, 2013 at 03:06:57PM +0530, Sachin Kamat wrote: s5m8767 regulator is used on Exynos platforms which use pin controller to configure GPIOs. Update the example accordingly. This smells bad, why does a driver using GPIOs through the GPIO API see a change in the binding? signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/4] gpio-tz1090: add TZ1090 gpio driver
On 24/06/13 15:48, James Hogan wrote: On 24/06/13 14:34, Grant Likely wrote: Similarly, can this driver use the generic irq chip to eliminate the above hooks? hmm, I could probably get away with it for irq callbacks since a bank's IRQ cannot be shared with non-Linux threads/cores. I just remembered, the commits that make the generic irqchip work with linear irq domains are in tip/irq/core so this won't work on pinctrl/devel or gpio/next branches. How would you like that handled? I'm happy to write a patch to convert to generic irqchip ready to be applied later (e.g. for v3.12). Cheers James ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/4] pinctrl-tz1090: add TZ1090 pinctrl driver
On 24/06/13 16:04, Linus Walleij wrote: On Thu, Jun 20, 2013 at 11:26 AM, James Hogan james.ho...@imgtec.com wrote: Add a pin control driver for the main pins on the TZ1090 SoC. This doesn't include the low-power pins as they're controlled separately via the Powerdown Controller (PDC) registers. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-...@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org --- Changes in v3: - separated from irq-imgpdc and removed arch/metag changes to allow these patches to go upstream separately via the pinctrl[/gpio] trees (particularly the pinctrl drivers depend on the new pinconf DT bindings). - some s/unsigned/unsigned int/. - some s/unsigned int/bool/ and use of BIT(). - pinctrl-tz1090*: switch to generic pinconfig DT bindings and pinconf_generic_dump_config. - pinctrl-tz1090*: use tz1090, prefix for pins and function in DT bindings. - pinctrl-tz1090*: make internal functions static. - pinctrl-tz1090*: move initcall from postcore to arch. Thanks James, patch applied. Also thanks for helping out in getting the generic pinconf in place for some three different drivers for this merge window, this was very good for pinctrl at large. Thanks Linus, and no problem! Cheers James ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5] clocksource:arm_global_timer: Add ARM global timer support.
From: Stuart Menefy stuart.men...@st.com
This is a simple driver for the global timer module found in the Cortex
A9-MP cores from revision r1p0 onwards. This should be able to perform
the functions of the system timer and the local timer in an SMP system.
The global timer has the following features:
The global timer is a 64-bit incrementing counter with an
auto-incrementing feature. It continues incrementing after sending
interrupts. The global timer is memory mapped in the private memory
region.
The global timer is accessible to all Cortex-A9 processors in the
cluster. Each Cortex-A9 processor has a private 64-bit comparator that
is used to assert a private interrupt when the global timer has reached
the comparator value. All the Cortex-A9 processors in a design use the
banked ID, ID27, for this interrupt. ID27 is sent to the Interrupt
Controller as a Private Peripheral Interrupt. The global timer is
clocked by PERIPHCLK.
Signed-off-by: Stuart Menefy stuart.men...@st.com
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Rob Herring robherri...@gmail.com
CC: Linus Walleij linus.wall...@linaro.org
CC: Will Deacon will.dea...@arm.com
CC: Thomas Gleixner t...@linutronix.de
---
Thankyou for reveiwing the v4 patch.
This patch is split out of the orignal 10 patches submitted for Sti SOC
support to arm-kernel mailing list. This patch has undergone 3 cycles of
reviews in arm-kernel mailing list.
Arnd already picked up SOC support patches [4-10] and merged them via arm-soc
tree for 3.11.
If its not too late can this patch be considered for 3.11 via clocksource tree?
This patch has no build dependencies.
Thanks,
srini
Changes since v4:
All the comments are from Thomas G.
- disabled irq and comp enable bits while setting one-shot mode.
- remove double pointer usage of clock_event_device structure.
- remove spaces from device name.
- remove few un-necessary comments.
- Fix error checks and error case handling in global_timer_of_register
Changes since v3:
- Arnd suggested to replaced all __raw_readl/__raw_writel with
readl/writel or readl_relaxed/writel_relaxed(for optimized path)
as __raw* apis are not Endian safe.
Changes since v2:
- cleaned up arm-global-timer code for non-dt as suggested by Linus W
and
- fixed minmum clock tick setting pointed by Linus W.
Changes since RFC:
Most of the comments are suggested by Linus W.
- moved to drivers/clocksource.
- added revision check in driver.
- removed unused header file.
- moved to u64 from union gt_counter
- comments added in get_counter
- removed leftover debug code.
- moved code to use __raw_readl/writel.
- used DIV_ROUND_CLOSEST
- added check in interrupt handler.
- expanded CE and CS acronyms usage.
- Fixed minimum clock ticks value.
- move to use clocksource_register_hz
- added arch sched_clock support.
- added ERRATA 740657 workaround.
.../devicetree/bindings/arm/global_timer.txt | 21 ++
drivers/clocksource/Kconfig| 13 +
drivers/clocksource/Makefile |1 +
drivers/clocksource/arm_global_timer.c | 320
4 files changed, 355 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/global_timer.txt
create mode 100644 drivers/clocksource/arm_global_timer.c
diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt
b/Documentation/devicetree/bindings/arm/global_timer.txt
new file mode 100644
index 000..b64abac
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
@@ -0,0 +1,21 @@
+
+* ARM Global Timer
+ Cortex-A9 are often associated with a per-core Global timer.
+
+** Timer node required properties:
+
+- compatible : Should be arm,cortex-a9-global-timer
+ Driver supports versions r2p0 and above.
+
+- interrupts : One interrupt to each core
+
+- reg : Specify the base address and the size of the GT timer
+ register window.
+
+Example:
+
+ timer@2c000600 {
+ compatible = arm,cortex-a9-global-timer;
+ reg = 0x2c000600 0x20;
+ interrupts = 1 13 0xf01;
+ };
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5871933..33e4453 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -69,6 +69,19 @@ config ARM_ARCH_TIMER
bool
select CLKSRC_OF if OF
+config ARM_GLOBAL_TIMER
+ bool
+ select CLKSRC_OF if OF
+ help
+ This options enables support for the ARM global timer unit
+
+config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+ bool
+ depends on ARM_GLOBAL_TIMER
+ default y
+ help
+Use ARM global timer clock source as sched_clock
+
config
Re: [PATCH] Bump version number to 1.4.0
On 06/22/2013 12:23 PM, Jon Loeliger wrote: Great! I didn't see any objections, and the week is basically over. Are we good for a release today? Hear Ye! Hear Ye! With a Mandate from the Masses for a tagged release, your wish has finally been granted! Excellent! Thank you very much. I guess I should go file some bugs against distros to get this updated version packaged. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC v3] media: OF: add video sync endpoint property
Hi Hans,
Thanks for the review.
On Mon, Jun 24, 2013 at 1:21 PM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Prabhakar,
On Sat June 22 2013 17:03:03 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch adds video sync properties as part of endpoint
properties and also support to parse them in the parser.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans Verkuil hans.verk...@cisco.com
FYI: using my private email when CC-ing me generally works better.
I often skip v4l2-related emails to my work address since I assume those
have either been CC-ed to my private email and/or linux-media.
OK hence forth I'll take care of it.
I wondered why I never saw RFC v1/2, now I know :-)
[Snip]
clock mode.
+- video-sync: property indicating to sync the video on a signal in RGB.
Please document what the various syncs actually mean.
OK
Example
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..1a54530 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -100,6 +100,26 @@ 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, video-sync, v)) {
+ switch (v) {
+ case V4L2_MBUS_VIDEO_SEPARATE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_SEPARATE_SYNC;
+ break;
+ case V4L2_MBUS_VIDEO_COMPOSITE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_COMPOSITE_SYNC;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_GREEN:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_GREEN;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE;
+ break;
+ }
+ }
+
bus-flags = flags;
}
diff --git a/include/dt-bindings/media/video-interfaces.h
b/include/dt-bindings/media/video-interfaces.h
new file mode 100644
index 000..1a083dd
--- /dev/null
+++ b/include/dt-bindings/media/video-interfaces.h
@@ -0,0 +1,17 @@
+/*
+ * This header provides constants for video interface.
+ *
+ */
+
+#ifndef _DT_BINDINGS_VIDEO_INTERFACES_H
+#define _DT_BINDINGS_VIDEO_INTERFACES_H
+
+#define V4L2_MBUS_VIDEO_SEPARATE_SYNC(1 2)
+#define V4L2_MBUS_VIDEO_COMPOSITE_SYNC (1 3)
+#define V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE(1 4)
What on earth is the difference between COMPOSITE_SYNC and
SYNC_ON_COMPOSITE?!
Ahh my bad.
+#define V4L2_MBUS_VIDEO_SYNC_ON_GREEN(1 5)
+#define V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE(1 6)
+
+#define V4L2_MBUS_VIDEO_INTERFACES_END 6
+
+#endif
Why would this be here? It isn't Device Tree specific, the same defines can
be used without DT as well.
This is in here because we cannot include header files from other folder in
device tree files.
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 83ae07e..a4676dd 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -11,6 +11,8 @@
#ifndef V4L2_MEDIABUS_H
#define V4L2_MEDIABUS_H
+#include dt-bindings/media/video-interfaces.h
+
#include linux/v4l2-mediabus.h
/* Parallel flags */
@@ -28,18 +30,18 @@
* V4L2_MBUS_[HV]SYNC* flags should be also used for specifying
* configuration of hardware that uses [HV]REF signals
*/
-#define V4L2_MBUS_HSYNC_ACTIVE_HIGH (1 2)
-#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3)
-#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 4)
-#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 5)
-#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 6)
-#define V4L2_MBUS_PCLK_SAMPLE_FALLING(1 7)
-#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 8)
-#define V4L2_MBUS_DATA_ACTIVE_LOW(1 9)
+#define V4L2_MBUS_HSYNC_ACTIVE_HIGH (1
(V4L2_MBUS_VIDEO_INTERFACES_END + 1))
+#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1
(V4L2_MBUS_VIDEO_INTERFACES_END + 2))
+#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1
(V4L2_MBUS_VIDEO_INTERFACES_END + 3))
+#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1
(V4L2_MBUS_VIDEO_INTERFACES_END + 4))
+#define V4L2_MBUS_PCLK_SAMPLE_RISING (1
(V4L2_MBUS_VIDEO_INTERFACES_END + 5))
+#define V4L2_MBUS_PCLK_SAMPLE_FALLING(1
(V4L2_MBUS_VIDEO_INTERFACES_END + 6))
+#define V4L2_MBUS_DATA_ACTIVE_HIGH (1
(V4L2_MBUS_VIDEO_INTERFACES_END + 7))
+#define V4L2_MBUS_DATA_ACTIVE_LOW(1
(V4L2_MBUS_VIDEO_INTERFACES_END + 8))
/* FIELD = 0/1 - Field1 (odd)/Field2 (even) */
-#define
Re: [PATCH] dmaengine: Add hisilicon k3 DMA engine driver
On Monday 24 June 2013 16:49:08 zhangfei gao wrote: Dear Arnd Vinod The suggestion of using dma_get_slave_channel instead of filter works here. Dma driver should modify accordingly. The changes all look good to me, thanks a lot for following up! However, you should really follow the procedure for posting patches even if it's just for the sake of discussion: * always provide a signed-off-by and a patch description * use an email client that doesn't break whitespace * I would have split this up into two separate patches, one for the subsystem and one for the new driver. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC] early init and DT platform devices allocation/registration
Hi all, I am dealing with a lingering problem related to init and probing of platform devices early (before initcalls) in the kernel boot process. The problem, which is nothing new, is related to how platform devices are created in the kernel from DT and when they become available. Platform devices are created through (assuming any legacy static initialization is removed from the kernel) of_platform_populate() at arch_initcall time on ARM. This is a problem for drivers that need to be probed and initialized before arch_initcall (ie early_initcall) because the corresponding platform_device has not been created yet. To work around this awkward situation, a driver, instead of relying on platform driver probing mechanism, can get initialized using early_initcall mechanism and rely on DT helpers (ie of_iomap() and company) to initialize resources. The problem comes when the driver functions must rely on an API (eg regmap) that requires a struct device to function properly; since the platform_device has not been created yet at early_initcall time, the driver cannot rely on it. The only solution consists in allocating a platform_device on the fly at driver init through of_platform_device_create() and use that device to initialize the (eg regmap) API. There is an issue with this solution, basically a platform device is allocated twice for a given device node - compatible property (because of_platform_populate() allocates a platform device for a node containing a compatible string even if a platform device has already been allocated for that device node). The second solution relies on early platform devices. Early platform devices are added by mach code and driver probing is carried out using the early platform device probing mechanism early_platform_driver_probe() The drawback with this solution is, AFAIK, it does not play well with DT, since the platform device duplication issue is still there (ie of_platform_populate() will allocate a platform device which is a duplicate of the one allocated at early boot to make the early platform device initialization possible). Please correct me if I am wrong, just trying to untangle a problem that does not look easy to solve. How this problem is supposed to be solved in the kernel ? 1- drivers that are to be up and running at early_initcall time must not rely on the device/driver model (but then they cannot use any API that requires a struct device to function (eg regmap)) 2- the driver should allocate a platform device at early initcall from a DT compatible node. Do not know how to deal with platform device duplication though, since of_platform_populate() will create another platform device when the node is parsed 3- driver should rely on early platform device/driver, but this does not solve (?) the platform device duplication problem either, it will happen when of_platform_populate() parses the DT and creates devices on the fly In theory there are other solutions such as: (a) declaring the platform device statically in arm/mach-* code and do not define the device node in dts, basically going back in time to ARM legacy kernel mechanism for this kind of devices (b) add a way to of_platform_populate() to exclude some compatible strings from being matched Honestly there is not a solution I can say I like and maybe I am trying to solve a problem that has already been solved, apologies if so, that's why I am asking on the list to people with more knowledge than me on the subject. Comments are really really welcome, thank you ! Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/3] iio: Add Nuvoton NAU7802 ADC driver
On 06/24/2013 12:37 PM, Alexandre Belloni wrote:
On 24/06/2013 08:41, Lars-Peter Clausen wrote:
On 06/20/2013 08:57 PM, Alexandre Belloni wrote:
The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
gain and sampling rates.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
.../bindings/iio/adc/nuvoton-nau7802.txt | 17 +
drivers/iio/adc/Kconfig| 9 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/nau7802.c | 603
+
4 files changed, 630 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
create mode 100644 drivers/iio/adc/nau7802.c
diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
new file mode 100644
index 000..9bc4218
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
@@ -0,0 +1,17 @@
+* Nuvoton NAU7802 Analog to Digital Converter (ADC)use
+
+Required properties:
+ - compatible: Should be nuvoton,nau7802
+ - reg: Should contain the ADC I2C address
+
+Optional properties:
+ - nuvoton,vldo: Reference voltage in millivolts (integer)
+ - interrupts: IRQ line for the ADC. If not used the driver will use
+polling.
+
+Example:
+adc2: nau7802@2a {
+ compatible = nuvoton,nau7802;
+ reg = 0x2a;
+ nuvoton,vldo = 3000;
We usually use the regulator framework for specifying the reference voltage.
I followed what Jonathan said in his review of my first patch. Do we
want to use the regulator framework to set the internal reference
voltage of the ADC ? I agree that if you supply an external voltage, it
will be necessary to use the regulator framework. Unfortunately, I can't
test that here.
Ah, ok I missed that it is an internally generated voltage. It might makes
sense to add that to the properties documentation.
I guess ideally you'd also register a regulator for the internal regulator
and then use that. But I think that will unnecessarily complicate the code,
so I guess the current solution is fine.
There is one bug in probe though, if nuvoton,vldo is not set tmp will remain
uninitialized.
+};
[...]
diff --git a/drivers/iio/adc/nau7802.c b/drivers/iio/adc/nau7802.c
new file mode 100644
index 000..e1b6981
--- /dev/null
+++ b/drivers/iio/adc/nau7802.c
@@ -0,0 +1,603 @@
[...]
+static int nau7802_set_gain(struct nau7802_state *st, int gain)
+{
+ u8 data;
+ int ret;
+
+ mutex_lock(st-lock);
+ st-conversion_count = 0;
+
+ data = i2c_smbus_read_byte_data(st-client, NAU7802_REG_CTRL1);
+ if (data 0)
+ goto nau7802_sysfs_set_gain_out;
ret will be uninitialized if the goto above is taken
Right, bigger issue, data is u8 so it will never be negative. I'm fixing
that !
+ ret = i2c_smbus_write_byte_data(st-client, NAU7802_REG_CTRL1,
+ (data (~NAU7802_CTRL1_GAINS_BITS)) |
+ gain);
+
+nau7802_sysfs_set_gain_out:
+ mutex_unlock(st-lock);
+
+ return ret ? ret : 0;
+}
[...]
+static int nau7802_read_irq(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val)
+{
+ struct nau7802_state *st = iio_priv(indio_dev);
+ int ret;
+
+ INIT_COMPLETION(st-value_ok);
+ enable_irq(st-client-irq);
Is it really necessary to enable/disable the IRQ or could you keep it
enabled all the time?
Fact is that the ADC doesn't really care if you are reading data or not
so you will probably endd up in a situation were you will get 320 IRQ
per second but not caring about the result. We have 3 ADCs on the board.
so that amounts to 960 IRQ per second when we are only reading like once
par second !
Ah, ok, makes sense.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/8] ARM: dts: Add camera and magnetometer support for TRATS2 board
This patch series includes some fixes and extensions to the Exynos
dts files to add the camera and magnetometer sensor support for TRATS2
board. It depends on a patch from Tomasz adding initial TRATS2 board
dts file [1].
Changes since v1 (are also listed at individual patches, if any):
- enabled pull down in cam-port-{a, b}-clk-idle nodes (1/8)
- added node alias for i2c-gpio@0 I2C controller node (7/8).
[1] http://www.spinics.net/lists/arm-kernel/msg253184.html
Jacek Anaszewski (1):
ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board
Sylwester Nawrocki (7):
ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
ARM: dts: Add ISP power domain node for Exynos4x12
ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
ARM: dts: Add camera nodes for Exynos4 SoCs
ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
arch/arm/boot/dts/exynos4.dtsi| 80 +--
arch/arm/boot/dts/exynos4412-trats2.dts | 110 ++
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 61 --
arch/arm/boot/dts/exynos4x12.dtsi | 123 +
4 files changed, 361 insertions(+), 13 deletions(-)
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/8] ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
Add separate nodes for the CAMCLK pin and turn off pull-up on camera
ports A, B. The video bus pins and the clock output (CAMCLK) pin need
separate nodes since full camera port is not used in some configurations,
e.g. for MIPI CSI-2 bus only CAMCLK is required and data/clock signal
use separate dedicated pins.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
- enabled pull down in cam-port-{a, b}-clk-idle nodes.
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 40 -
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 704290f..55ff73b 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,13 +401,26 @@
samsung,pin-drv = 0;
};
- cam_port_a: cam-port-a {
+ cam_port_a_io: cam-port-a-io {
samsung,pins = gpj0-0, gpj0-1, gpj0-2, gpj0-3,
gpj0-4, gpj0-5, gpj0-6, gpj0-7,
- gpj1-0, gpj1-1, gpj1-2, gpj1-3,
- gpj1-4;
+ gpj1-0, gpj1-1, gpj1-2, gpj1-4;
samsung,pin-function = 2;
- samsung,pin-pud = 3;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = gpj1-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ cam_port_a_clk_idle: cam-port-a-clk-idle {
+ samsung,pins = gpj1-3;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
samsung,pin-drv = 0;
};
};
@@ -778,16 +791,29 @@
samsung,pin-drv = 3;
};
- cam_port_b: cam-port-b {
+ cam_port_b_io: cam-port-b-io {
samsung,pins = gpm0-0, gpm0-1, gpm0-2, gpm0-3,
gpm0-4, gpm0-5, gpm0-6, gpm0-7,
- gpm1-0, gpm1-1, gpm2-0, gpm2-1,
- gpm2-2;
+ gpm1-0, gpm1-1, gpm2-0, gpm2-1;
samsung,pin-function = 3;
samsung,pin-pud = 3;
samsung,pin-drv = 0;
};
+ cam_port_b_clk_active: cam-port-b-clk-active {
+ samsung,pins = gpm2-2;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ cam_port_b_clk_idle: cam-port-b-clk-idle {
+ samsung,pins = gpm2-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
eint0: ext-int0 {
samsung,pins = gpx0-0;
samsung,pin-function = 0xf;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/8] ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
The Exynos4 SPI controller uses the PL330 DMA controller which has migrated to the generic DMA bindings since commit b5be04d35dbb2e00 spi: s3c64xx: Modify SPI driver to use generic DMA DT support. Use the generic bindings to specify the corresponding DMA to make the SPI usable again on Exynos4x12 SOCs. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 3f94fe8..bce2254 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -297,8 +297,8 @@ compatible = samsung,exynos4210-spi; reg = 0x1392 0x100; interrupts = 0 66 0; - tx-dma-channel = pdma0 7; /* preliminary */ - rx-dma-channel = pdma0 6; /* preliminary */ + dmas = pdma0 7, pdma0 6; + dma-names = tx, rx; #address-cells = 1; #size-cells = 0; clocks = clock 327, clock 159; @@ -312,8 +312,8 @@ compatible = samsung,exynos4210-spi; reg = 0x1393 0x100; interrupts = 0 67 0; - tx-dma-channel = pdma1 7; /* preliminary */ - rx-dma-channel = pdma1 6; /* preliminary */ + dmas = pdma1 7, pdma1 6; + dma-names = tx, rx; #address-cells = 1; #size-cells = 0; clocks = clock 328, clock 160; @@ -327,8 +327,8 @@ compatible = samsung,exynos4210-spi; reg = 0x1394 0x100; interrupts = 0 68 0; - tx-dma-channel = pdma0 9; /* preliminary */ - rx-dma-channel = pdma0 8; /* preliminary */ + dmas = pdma0 9, pdma0 8; + dma-names = tx, rx; #address-cells = 1; #size-cells = 0; clocks = clock 329, clock 161; -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 5/8] ARM: dts: Add camera nodes for Exynos4 SoCs
This patch adds common FIMC and MIPI CSIS device nodes for Exynos4 SoCs.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 68
1 file changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index bce2254..4d61120 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -36,6 +36,12 @@
i2c5 = i2c_5;
i2c6 = i2c_6;
i2c7 = i2c_7;
+ csis0 = csis_0;
+ csis1 = csis_1;
+ fimc0 = fimc_0;
+ fimc1 = fimc_1;
+ fimc2 = fimc_2;
+ fimc3 = fimc_3;
};
chipid@1000 {
@@ -92,6 +98,68 @@
reg = 0x1001 0x400;
};
+ camera {
+ compatible = samsung,fimc, simple-bus;
+ status = disabled;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ fimc_0: fimc@1180 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1180 0x1000;
+ interrupts = 0 84 0;
+ samsung,power-domain = pd_cam;
+ samsung,sysreg = sys_reg;
+ status = disabled;
+ };
+
+ fimc_1: fimc@1181 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1181 0x1000;
+ interrupts = 0 85 0;
+ samsung,power-domain = pd_cam;
+ samsung,sysreg = sys_reg;
+ status = disabled;
+ };
+
+ fimc_2: fimc@1182 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1182 0x1000;
+ interrupts = 0 86 0;
+ samsung,power-domain = pd_cam;
+ samsung,sysreg = sys_reg;
+ status = disabled;
+ };
+
+ fimc_3: fimc@1183 {
+ compatible = samsung,exynos4210-fimc;
+ reg = 0x1183 0x1000;
+ interrupts = 0 87 0;
+ samsung,power-domain = pd_cam;
+ samsung,sysreg = sys_reg;
+ status = disabled;
+ };
+
+ csis_0: csis@1188 {
+ compatible = samsung,exynos4210-csis;
+ reg = 0x1188 0x4000;
+ interrupts = 0 78 0;
+ bus-width = 4;
+ samsung,power-domain = pd_cam;
+ status = disabled;
+ };
+
+ csis_1: csis@1189 {
+ compatible = samsung,exynos4210-csis;
+ reg = 0x1189 0x4000;
+ interrupts = 0 80 0;
+ bus-width = 2;
+ samsung,power-domain = pd_cam;
+ status = disabled;
+ };
+ };
+
watchdog@1006 {
compatible = samsung,s3c2410-wdt;
reg = 0x1006 0x100;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 8/8] ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
This patch enables the front camera using the internal
camera ISP (FIMC-IS).
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts | 91 +++
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index b9de3b5..e9fb3de 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -62,6 +62,15 @@
enable-active-high;
};
+ cam_io_reg: voltage-regulator@3 {
+ compatible = regulator-fixed;
+ regulator-name = CAM_SENSOR_A;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ gpio = gpm0 2 0;
+ enable-active-high;
+ };
+
/* More to come */
};
@@ -472,4 +481,86 @@
gpios = gpj0 7 0;
};
};
+
+ camera {
+ pinctrl-names = default;
+ pinctrl-0 = cam_port_b_clk_active;
+ status = okay;
+
+ fimc_0: fimc@1180 {
+ clock-frequency = 16000;
+ status = okay;
+ };
+
+ fimc_1: fimc@1181 {
+ clock-frequency = 16000;
+ status = okay;
+ };
+
+ fimc_2: fimc@1182 {
+ clock-frequency = 16000;
+ status = okay;
+ };
+
+ fimc_3: fimc@1183 {
+ clock-frequency = 16000;
+ status = okay;
+ };
+
+ csis_1: csis@1189 {
+ vddcore-supply = ldo8_reg;
+ vddio-supply = ldo10_reg;
+ clock-frequency = 16000;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = okay;
+
+ /* Camera D (4) MIPI CSI-2 (CSIS1) */
+ port@4 {
+ reg = 4;
+ csis1_ep: endpoint {
+ remote-endpoint = is_s5k6a3_ep;
+ data-lanes = 1;
+ samsung,csis-hs-settle = 18;
+ samsung,csis-wclk;
+ };
+ };
+ };
+
+ fimc_lite_0: fimc-lite@1239 {
+ status = okay;
+ };
+
+ fimc_lite_1: fimc-lite@123A {
+ status = okay;
+ };
+
+ fimc-is@1200 {
+ pinctrl-0 = fimc_is_uart;
+ pinctrl-names = default;
+ status = okay;
+
+ i2c1_isp: i2c-isp@1214 {
+ pinctrl-0 = fimc_is_i2c1;
+ pinctrl-names = default;
+
+ s5k6a3@10 {
+ compatible = samsung,s5k6a3;
+ reg = 0x10;
+ svdda-supply = cam_io_reg;
+ svddio-supply = ldo19_reg;
+ clock-frequency = 2400;
+ samsung,camclk-out = 1;
+ gpios = gpm1 6 0;
+
+ port {
+ is_s5k6a3_ep: endpoint {
+ remote-endpoint =
csis1_ep;
+ data-lanes = 1;
+ };
+ };
+ };
+ };
+ };
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 7/8] ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board
From: Jacek Anaszewski j.anaszew...@samsung.com
This patch adds AK8975 magnetometer node and corresponding
i2c-gpio bus node for TRATS2 board.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v1:
- added node alias for i2c-gpio@0 I2C controller node.
---
arch/arm/boot/dts/exynos4412-trats2.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 056b835..b9de3b5 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -19,6 +19,10 @@
model = Samsung Trats 2 based on Exynos4412;
compatible = samsung,trats2, samsung,exynos4412;
+ aliases {
+ i2c8 = i2c_ak8975;
+ };
+
memory {
reg = 0x4000 0x4000;
};
@@ -453,4 +457,19 @@
serial@1383 {
status = okay;
};
+
+ i2c_ak8975: i2c-gpio@0 {
+ compatible = i2c-gpio;
+ gpios = gpy2 4 0, gpy2 5 0;
+ i2c-gpio,delay-us = 2;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = okay;
+
+ ak8975@0c {
+ compatible = asahi-kasei,ak8975;
+ reg = 0x0c;
+ gpios = gpj0 7 0;
+ };
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 0/9] Generic PHY Framework
Hi, On 06/18/2013 11:49 AM, Felipe Balbi wrote: On Mon, Jun 17, 2013 at 12:16:35PM +0200, Sylwester Nawrocki wrote: I have already used this API for our MIPI CSI-2/DSIM DPHYs driver, the RFC patch series can be found at [1]. Thanks, Sylwester [1] http://www.spinics.net/lists/arm-kernel/msg251666.html one comment to that series: let's make the phy names standardized, how about phy-exynos-video-mipi.c or phy-mipi-csi-dsim.c ? Yes, I have been thinking about that, wasn't sure exactly what pattern to chose. I would make it phy-exynos-mipi-video.c, phy-exynos-dsim-csis.c feels a bit odd. phy-mipi-csis-dsim.c might be to generic as MIPI CSIS stands for MIPI CSI Slave and MIPI DSIM - MIPI DSI Master. And there might be (actually are) IP blocks in an SoC that use the other MIPI Aliance standards. For the HDMI PHY I guess just phy-exynos-hdmi.c could be used. Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] clocksource:arm_global_timer: Add ARM global timer support.
On Mon, 24 Jun 2013, Srinivas KANDAGATLA wrote: From: Stuart Menefy stuart.men...@st.com This is a simple driver for the global timer module found in the Cortex A9-MP cores from revision r1p0 onwards. This should be able to perform the functions of the system timer and the local timer in an SMP system. The global timer has the following features: The global timer is a 64-bit incrementing counter with an auto-incrementing feature. It continues incrementing after sending interrupts. The global timer is memory mapped in the private memory region. The global timer is accessible to all Cortex-A9 processors in the cluster. Each Cortex-A9 processor has a private 64-bit comparator that is used to assert a private interrupt when the global timer has reached the comparator value. All the Cortex-A9 processors in a design use the banked ID, ID27, for this interrupt. ID27 is sent to the Interrupt Controller as a Private Peripheral Interrupt. The global timer is clocked by PERIPHCLK. Signed-off-by: Stuart Menefy stuart.men...@st.com Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Arnd Bergmann a...@arndb.de CC: Rob Herring robherri...@gmail.com CC: Linus Walleij linus.wall...@linaro.org CC: Will Deacon will.dea...@arm.com CC: Thomas Gleixner t...@linutronix.de Reviewed-by: Thomas Gleixner t...@linutronix.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] clocksource:arm_global_timer: Add ARM global timer support.
On 06/24/13 08:53, Srinivas KANDAGATLA wrote:
+
+static void gt_clockevents_stop(struct clock_event_device *clk)
+{
+ gt_clockevent_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
+ disable_percpu_irq(clk-irq);
+}
+
+static int __cpuinit gt_clockevents_setup(struct clock_event_device *clk)
+{
+ struct clock_event_device *evt = this_cpu_ptr(gt_evt);
+ return evt-name ? 0 : gt_clockevents_init(evt);
+}
How does this work? gt_clockevents_stop() is using the
clock_event_device struct from the ARM local timer layer whereas
gt_clockevents_setup() is using a driver private allocation. Please just
don't use the local timer API at all and use cpu notifiers instead.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Mon, Jun 24, 2013 at 6:23 AM, Sekhar Nori nsek...@ti.com wrote: On 6/22/2013 3:23 AM, Joel A Fernandes wrote: Hi Arnd, On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 21 June 2013, Joel A Fernandes wrote: I think we are talking about different things, I agree the 'select DMADEVICES' can be dropped but lets please keep the default y option (not adding new select statements, just saying that if someone select DMADEVICES in menuconfig and if they're ARCH_OMAP=1 , then default to EDMA). This will simply allow people to have a default. Thanks. Yes, that's ok. Ok, thanks. I will follow up with a patch in my next submissions that builds it. Perhaps a: default y if 'ARCH_OMAP2PLUS' and leave the existing as it is... default n if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2' would make most sense to me. Basically EDMA is seen on current and all new OMAP2PLUS. OMAP2PLUS devices like OMAP3/4 do not have EDMA so this is not really true. Sure. Right now though, and from what I've seen, all future SoCs are supporting EDMA. config TI_EDMA tristate TI EDMA support default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2 select DMA_ENGINE select DMA_VIRTUAL_CHANNELS MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The 'm' option will require some initramfs to load the module when needing to MMC boot, I suggest lets leave it as y. But there is no reason why it cannot work with PIO, right? Sounds like the right fix is in driver. I am not sure about this. I agree no reason it cannot do PIO. I will check. But even if it did, loading EDMA as a module will require omap_hsmmc to switch to DMA mode which I am sure the driver doesn't support today. Thanks, Joel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Saturday 22 June 2013, Joel A Fernandes wrote:
config TI_EDMA
tristate TI EDMA support
default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
'm' option will require some initramfs to load the module when needing
to MMC boot, I suggest lets leave it as y.
Ah, right: you still export a filter function from the edma driver
and use it in slave drivers:
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_rx = dma_request_channel(mask,
edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_tx = dma_request_channel(mask,
edma_filter_fn,
As long as this is the case, you have to be careful with the dependencies
to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or
edma_filter_fn gets defined to NULL when you are building for a DT-only
platform.
Yes sure, right now they are defined as follows in include/linux/edma.h:
#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
bool edma_filter_fn(struct dma_chan *, void *);
#else
static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
{
return false;
}
#endif
It's best to just define the filter function in the platform
code and pass a pointer to it through platform data. The way you do
it above makes the slave drivers inherently nonportable.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Mon, Jun 24, 2013 at 3:28 PM, Arnd Bergmann a...@arndb.de wrote:
On Saturday 22 June 2013, Joel A Fernandes wrote:
config TI_EDMA
tristate TI EDMA support
default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
'm' option will require some initramfs to load the module when needing
to MMC boot, I suggest lets leave it as y.
Ah, right: you still export a filter function from the edma driver
and use it in slave drivers:
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/mmc/host/davinci_mmc.c:
dma_request_slave_channel_compat(mask, edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_rx = dma_request_channel(mask,
edma_filter_fn,
drivers/spi/spi-davinci.c: dspi-dma_tx = dma_request_channel(mask,
edma_filter_fn,
As long as this is the case, you have to be careful with the dependencies
to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or
edma_filter_fn gets defined to NULL when you are building for a DT-only
platform.
Yes sure, right now they are defined as follows in include/linux/edma.h:
#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
bool edma_filter_fn(struct dma_chan *, void *);
#else
static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
{
return false;
}
#endif
It's best to just define the filter function in the platform
code and pass a pointer to it through platform data. The way you do
it above makes the slave drivers inherently nonportable.
But with DT-only platforms, can you really do that?
Thanks,
Joel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Monday 24 June 2013, Joel A Fernandes wrote:
Yes sure, right now they are defined as follows in include/linux/edma.h:
#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
bool edma_filter_fn(struct dma_chan *, void *);
#else
static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
{
return false;
}
#endif
It's best to just define the filter function in the platform
code and pass a pointer to it through platform data. The way you do
it above makes the slave drivers inherently nonportable.
But with DT-only platforms, can you really do that?
The nice thing about this is that with a DT-only platform, the
filter function will automatically go away: you have no
platform_data, which means that if you are using
dma_request_slave_channel_compat, you just pass NULL as the
filter and the filter-data, same as just calling
dma_request_slave_channel.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] clocksource:arm_global_timer: Add ARM global timer support.
On 24/06/13 21:06, Stephen Boyd wrote:
On 06/24/13 08:53, Srinivas KANDAGATLA wrote:
+
+static void gt_clockevents_stop(struct clock_event_device *clk)
+{
+gt_clockevent_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
+disable_percpu_irq(clk-irq);
+}
+
+static int __cpuinit gt_clockevents_setup(struct clock_event_device *clk)
+{
+struct clock_event_device *evt = this_cpu_ptr(gt_evt);
+return evt-name ? 0 : gt_clockevents_init(evt);
+}
How does this work? gt_clockevents_stop() is using the
clock_event_device struct from the ARM local timer layer whereas
gt_clockevents_setup() is using a driver private allocation.
Thanks for pointing this..
This should fix it.
static void gt_clockevents_stop(struct clock_event_device *clk)
{
struct clock_event_device *evt = this_cpu_ptr(gt_evt);
gt_clockevent_set_mode(CLOCK_EVT_MODE_UNUSED, evt);
disable_percpu_irq(evt-irq);
}
Please just
don't use the local timer API at all and use cpu notifiers instead.
Last time when I did try using cpu notifiers like arm_arch_timer, the
broadcast dummy timer did kick off and took over the local timer on the
secondary cpus. Resulting in lot of broadcast IPI's.
If I use cpu notifiers I will end up two clk events on a each core (one
dummy from arm/kernel/smp.c and other gt clk_evt). I think I can only
use cpu notifiers in my case once your patches are in.
Also I cant disable LOCAL_TIMERS as it y by default.
Am I missing something?
Am happy to move to cpu notifiers if it works, else the driver will be
broken.
Thanks,
srini
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] clocksource:arm_global_timer: Add ARM global timer support.
On 24/06/13 21:01, Thomas Gleixner wrote: On Mon, 24 Jun 2013, Srinivas KANDAGATLA wrote: From: Stuart Menefy stuart.men...@st.com This is a simple driver for the global timer module found in the Cortex A9-MP cores from revision r1p0 onwards. This should be able to perform the functions of the system timer and the local timer in an SMP system. The global timer has the following features: The global timer is a 64-bit incrementing counter with an auto-incrementing feature. It continues incrementing after sending interrupts. The global timer is memory mapped in the private memory region. The global timer is accessible to all Cortex-A9 processors in the cluster. Each Cortex-A9 processor has a private 64-bit comparator that is used to assert a private interrupt when the global timer has reached the comparator value. All the Cortex-A9 processors in a design use the banked ID, ID27, for this interrupt. ID27 is sent to the Interrupt Controller as a Private Peripheral Interrupt. The global timer is clocked by PERIPHCLK. Signed-off-by: Stuart Menefy stuart.men...@st.com Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Arnd Bergmann a...@arndb.de CC: Rob Herring robherri...@gmail.com CC: Linus Walleij linus.wall...@linaro.org CC: Will Deacon will.dea...@arm.com CC: Thomas Gleixner t...@linutronix.de Reviewed-by: Thomas Gleixner t...@linutronix.de Thanks Thomas, I will fix Stephen's comment in next spin. Thanks, srini ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] clocksource:arm_global_timer: Add ARM global timer support.
On 06/24/13 14:08, Srinivas KANDAGATLA wrote:
On 24/06/13 21:06, Stephen Boyd wrote:
On 06/24/13 08:53, Srinivas KANDAGATLA wrote:
+
+static void gt_clockevents_stop(struct clock_event_device *clk)
+{
+ gt_clockevent_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
+ disable_percpu_irq(clk-irq);
+}
+
+static int __cpuinit gt_clockevents_setup(struct clock_event_device *clk)
+{
+ struct clock_event_device *evt = this_cpu_ptr(gt_evt);
+ return evt-name ? 0 : gt_clockevents_init(evt);
+}
How does this work? gt_clockevents_stop() is using the
clock_event_device struct from the ARM local timer layer whereas
gt_clockevents_setup() is using a driver private allocation.
Thanks for pointing this..
This should fix it.
static void gt_clockevents_stop(struct clock_event_device *clk)
{
struct clock_event_device *evt = this_cpu_ptr(gt_evt);
gt_clockevent_set_mode(CLOCK_EVT_MODE_UNUSED, evt);
disable_percpu_irq(evt-irq);
}
Looks good, but even better would be to not use the local timer API.
Please just
don't use the local timer API at all and use cpu notifiers instead.
Last time when I did try using cpu notifiers like arm_arch_timer, the
broadcast dummy timer did kick off and took over the local timer on the
secondary cpus. Resulting in lot of broadcast IPI's.
If I use cpu notifiers I will end up two clk events on a each core (one
dummy from arm/kernel/smp.c and other gt clk_evt). I think I can only
use cpu notifiers in my case once your patches are in.
Also I cant disable LOCAL_TIMERS as it y by default.
Am I missing something?
Am happy to move to cpu notifiers if it works, else the driver will be
broken.
I think the problem is your clockevent has no rating. Please give it a
rating (300?) so that it prevents the dummy from taking over. You don't
need to worry about disabling the local timer API, it will register a
harmless clockevent with a low rating (100) that should be ignored.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 01/12] input: matrix-keypad: update devicetree binding doc
On 06/22/2013 03:23 AM, Gerhard Sittig wrote: ... On Fri, Jun 21, 2013 at 15:31 -0600, Stephen Warren wrote: On 06/21/2013 12:09 PM, Gerhard Sittig wrote: update the device tree binding documentation for the GPIO matrix keypad driver: mention the driver's selecting all columns at once, reword the delay descriptions, add the missing active low GPIO pin level property diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt ... +Simple keypad matrix layouts just connect GPIO lines to mechanical +switches, with no other active components involved. Although due to the I don't think that's always true. On some Tegra boards for example, multiple processes can press certain switches, so we actually have a wired-OR feed into a transistor which then connects a particular (column, row) combination. We do this e.g. for remote-control USB over the power button for example. I believe the effect is the same, but it does mean that statement above isn't quite true. That's why I wrote about simple ... layouts, but couldn't tell exactly when it was appropriate to discuss the more advanced setups as well, and in how much depth to do that in the device tree binding. So is there a better way of putting this? Is the simple or the mechanical the issue in the description? I think both simple and mechanical should be removed. My reasoning: At the level of connection between rows/columns, aren't all matrix keypads set up such that something connects a row to a column to signify a keypress, not just simple layouts. Similarly, mechanical should be removed since it's not always true, and even if it were, it would be irrelevant to anything outside the keyboard, perhaps aside from the need to debounce. In fact, thinking about this more, I think all four paragraphs of text that this patch adds would be better in Documentation/input/, as you mentioned elsewhere. When introducing any extra properties, you could mention their potential use by a driver, as explanation for why they're useful, but there's probably no need to describe the complete operation of the driver in the DT binding. +- gpio-activelow: row pins as well as column pins are active low That one change is definitely wrong. Each entry in row-gpios and col-gpios should include GPIO flags (in a format defined by the binding for the DT node providing the GPIO). Those flags include an active-high vs. active-low bit. In Linux, you can use of_get_gpio_flags() to retrieve a standardized representation of the flags. See my introduction above. This isn't a change, it's just catching up in the documentation and adding what was omitted before. Oh dear, that's quite unfortunate. I see that even though that property wasn't documented in the binding doc, arch/powerpc/boot/dts/ac14xx.dts has still already used it, so we probably can't fix it. I suppose we must simply document it, and ignore the shortcomings of that binding:-( And I can see another issue here (maybe shadowed by the wording I used, referring to row pins): The fact that a pin may be inverted (within the SoC), and the fact that an externally connected component might require low active stimulus over otherwise high active pins/connections, might need to get reflected well. Or am I too picky here? Are there other cases to learn from, where non-inverted physical pins get attached to components which require inverted logical information? Do we combine the overall polarity within the GPIO pin's abstraction, or do logical drivers above GPIO handle the inversion? In general, I would expect the binding to represent the overall effective polarity of the signal that must be programmed into the relevant GPIO controller. SW doesn't really care how/why the signal is inverted, simply that it needs to (or doesn't) invert the signal when it programs the GPIO controller. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Re: [PATCH] gpio MIPS/OCTEON: Add a driver for OCTEON's on-chip GPIO pins.
On Thu, Jun 20, 2013 at 8:10 PM, David Daney ddaney.c...@gmail.com wrote:
On 06/17/2013 01:51 AM, Linus Walleij wrote:
+#include asm/octeon/octeon.h
+#include asm/octeon/cvmx-gpio-defs.h
I cannot find this in my tree.
Weird, I see them here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/asm/octeon/cvmx-gpio-defs.h
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/asm/octeon/octeon.h
Do you not have these?
Yeah no problem, I must have misgrepped.
Sorry for the fuzz...
depend on OF as well right? Or does the CAVIUM_OCTEON_SOC already
imply that?
We already have 'select USE_OF', so I think adding OF here would be
redundant.
OK.
+/*
+ * The address offset of the GPIO configuration register for a given
+ * line.
+ */
+static unsigned int bit_cfg_reg(unsigned int gpio)
Maybe the passed variable shall be named offset here, as it is named
offset on all call sites, and it surely local for this instance?
Well it is the gpio line, so perhaps it should universally be change to
line or pin
We use offset to signify line enumerators in drivers/gpio/*
well atleaste if they are local to a piece of hardware.
(Check the GPIO siblings.)
+{
+ if (gpio 16)
+ return 8 * gpio;
+ else
+ return 8 * (gpio - 16) + 0x100;
Put this 0x100 in the #defines above with the name something like
STRIDE.
But it is not a 'STRIDE', it is a discontinuity compensation and used in
exactly one place.
OK what about a comment or something, because it isn't
exactly intuitive right?
+struct octeon_gpio {
+ struct gpio_chip chip;
+ u64 register_base;
+};
OMG everything is 64 bit. Well has to come to this I guess.
Not everything. This is custom logic in an SoC with 64-bit wide internal
address buses, what would you suggest?
Yep that's what I meant, no big deal. Just first time
I really see it in driver bases.
I'm not a fan of packed bitfields like this, I prefer if you just
OR | and AND the bits together in the driver.
I see you disregarded this comment, and looking at the header
files it seems the MIPS arch is a big fan if packed bitfields so
will live with it for this arch...
+static int octeon_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct octeon_gpio *gpio = container_of(chip, struct octeon_gpio,
chip);
+ u64 read_bits = cvmx_read_csr(gpio-register_base + RX_DAT);
+
+ return ((1ull offset) read_bits) != 0;
A common idiom we use for this is:
return !!(read_bits (1ull offset));
I hate that idiom, but if its use is a condition of accepting the patch, I
will change it.
Nah. If a good rational reason like hate is given for not using a coding
idiom I will accept it as it stands ;-)
+ dev_info(pdev-dev, OCTEON GPIO\n);
This is like shouting REAL MADRID! in the bootlog, be a bit more
precise: octeon GPIO driver probed\n or something so we know what
is happening.
No, more akin to 'Real Madrid', as 'OCTEON' is the correct spelling of its
given name.
I will happily add driver probed, and grudgingly switch to lower case if
it is a necessary condition of patch acceptance.
I don't know, does this rest of the MIPS drivers emit similar messages
such that the bootlog will say
OCTEON clocks
OCTEON irqchip
OCTEON I2C
OCTEON GPIO
then I guess it's convention and it can stay like this.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] clocksource:arm_global_timer: Add ARM global timer support.
On 06/24/13 08:53, Srinivas KANDAGATLA wrote:
+#include linux/clkdev.h
Why do you need this include?
+#include asm/mach/irq.h
And this one?
+static u64 gt_counter_read(void)
+{
+ u64 counter;
+ u32 lower;
+ u32 upper, old_upper;
+
+ upper = readl_relaxed(gt_base + GT_COUNTER1);
+ do {
+ old_upper = upper;
+ lower = readl_relaxed(gt_base + GT_COUNTER0);
+ upper = readl_relaxed(gt_base + GT_COUNTER1);
[snip]
+static void gt_compare_set(unsigned long delta, int periodic)
+{
+ u64 counter = gt_counter_read();
+ unsigned long ctrl = readl(gt_base + GT_CONTROL);
+
+ counter += delta;
+ ctrl = ~(GT_CONTROL_COMP_ENABLE | GT_CONTROL_IRQ_ENABLE);
+
+ writel(ctrl, gt_base + GT_CONTROL);
+ writel(lower_32_bits(counter), gt_base + GT_COMP0);
+ writel(upper_32_bits(counter), gt_base + GT_COMP1);
+
+ if (periodic) {
+ writel(delta, gt_base + GT_AUTO_INC);
+ ctrl |= GT_CONTROL_AUTO_INC;
+ }
+
+ ctrl |= GT_CONTROL_COMP_ENABLE | GT_CONTROL_IRQ_ENABLE;
+ writel(ctrl, gt_base + GT_CONTROL);
+}
Why is there a mix of the relaxed and non-relaxed io accessors?
+#ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+static u32 gt_sched_clock_read(void)
notrace
+{
+ if (!gt_base)
+ return 0;
Seems impossible? Remove this check?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 04/12] input: matrix-keypad: push/pull, separate polarity
On 06/22/2013 03:36 AM, Gerhard Sittig wrote: On Fri, Jun 21, 2013 at 15:34 -0600, Stephen Warren wrote: On 06/21/2013 12:09 PM, Gerhard Sittig wrote: extend the device tree adjustable hardware configuration: - allow for differing polarity of the row and column GPIO pins - optionally fully drive column output pins instead of the former unconditional open collector emulation approach diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt +- row-gpios-activelow: row GPIO pins are active low +- col-gpios-activelow: column GPIO pins are active low - gpio-activelow: row pins as well as column pins are active low + (provided for backward compatibility, and useful + for matrix layouts of identical polarity for + rows and columns) Those should all come from the existing GPIO flags, and may even differ for each GPIO. +- col-gpios-pushpull: fully drive the column selection pins in either + direction (high and low signals), the default + behaviour is to actively drive low signals and + be passive otherwise (emulates an open collector + output driver) We don't actually have GPIO flags defined for pushpull-vs-open-collector etc. Perhaps we should do so. Then, we wouldn't need to invent custom properties to represent that in this binding. I see your concerns and understand, but chose the above way to just extend the existing implementation in the least intrusive way without changing its nature. See the reply on the first patch for more details on the motivation. Of course I agree that pin properties belong to the GPIO layer and that application drivers on top should not worry about that. Were I allowed to break backwards compatibility, then I could have done more shuffling. But lacking the capability to test the affected setups puts more burdon on others, which I wanted to avoid. Can't you add this enhancement as follows: Update the driver to look at the per-pin GPIO flags in all cases. Presumably in any existing cases, those flags all say active high anyway, since specifying anything else was useless. In the very unlikely case this isn't true, one could always add a quirk based on the HW-specific compatible value. If gpio-activelow is set, mark all pins as active-low. This way, any future extensions (i.e. what this patch implements: just rows active low, just columns active low) can be implemented using purely the standard GPIO flags, but the existing behaviour of the existing gpio-activelow property is maintained. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 07/12] input: keypad-matrix: introduce polling support
On 06/22/2013 03:50 AM, Gerhard Sittig wrote: ... The patch set doesn't introduce that behaviour, but merely describes it in more detail. It doesn't even introduce the interrupt discussion into the binding document in a strict sense, but expands on it in the hope for improved usability of the binding after the motivation became more obvious. What this part of the series does is to introduce polling mode as an alternative to the interrupt driven detection of changes, to improve reliability of change detection in the presence of multi key presses. To me, this sounds more like something for Documentation/input/ rather than DT binding. ... I suggest to have the meta-discussions on which documentation belongs where and on where to put the GPIO polarity and on whether backward compatibility needs to be kept or may be broken, in a single spot, to not have several parallel discussions in multiple subthreads. Is the cover letter or the first patch the most appropriate message to respond to with this though in mind? Or don't you mind if several replies for different parts of the patch set discuss similar background aspects of the same series? I don't really have a preference myself; feel free to pick whichever patch or response you want to continue discussing, and reply to that; I'll just reply to whatever sub-thread/... you choose:-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 08/12] input: keypad-matrix: tell GPIO pins from matrix lines
On 06/22/2013 04:00 AM, Gerhard Sittig wrote: On Fri, Jun 21, 2013 at 15:41 -0600, Stephen Warren wrote: On 06/21/2013 12:09 PM, Gerhard Sittig wrote: diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt +The driver assumes that all interconnections of the matrix can potentially +contain a button, and will submit scan and key code events to the input +subsystem. By default the keypad matrix dimenstions are automatically +derived from the GPIO pin specifications. Optionally device tree +information can override the keypad matrix dimension data, e.g. when not +all of the potentially available physical connections are used to create +the logical keypad matrix. Ignoring the binary encoding in the next patch, why would someone ever define more row GPIOs that there are rows (or similarly for columns)? On its own, I don't think this patch is needed. Well, the keypad's property (remember the layering between keypad and keymap) has already been there, I just made the matrix keypad driver actually use the keymap's DT parse call. Regarding the usefulness of the patch in the absence of binary encodings which only later get introduced: I can't tell how much of a stretch it's going to get perceived as, but I suggested this: A .dtsi may specify the GPIO pins for a keypad attachment (say, the SoC's or module's potential to drive a matrix, the physical perspective), while boards' .dts files may specify the keymap and its specific layout (the logical matrix description). In this case, I'd say that the row-/column-GPIOs should only be specified by the .dts/.dtsi file for the HW that actually commits the GPIOs to that purpose. So in your example, the .dtsi file shouldn't specify which GPIOs to use, since the SoC (or base-board) doesn't define that; only the HW module which actually contains the keypad does, and hence only the .dts file for that piece of HW should specify the GPIOs. I suppose that approach doesn't handle a board with a generic keypad controller socket though; the user could plug in anything they want, and wouldn't want to have to re-write the board .dts file just to specify their keymap. Looking at this from the approach of the keymap data: Why does the DT need to say these columns are used or these rows are used? That data is already available from a simple search of the keymap for the various row-/column-IDs. Let the driver or keymap parser calculate the set of valid rows/columns when the keymap is installed. With this approach, you could even get far more optimal. On some Tegra boards, there end up being rather tri-angular keymaps, where key positions (0, 0), (0, 1), (0, 2), (1, 1), (1, 2), (2, 2) end up being used. In this scenario, detailed investigation of the keymap would reveal: * Only scan columns 0..2 * For column 0, scan rows 0..2 * For column 1, scan rows 1..2 * For columm 2, scan row 2. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 10/12] input: keypad_matrix: use usleep_range() for scan delay
On 06/22/2013 04:17 AM, Gerhard Sittig wrote:
On Fri, Jun 21, 2013 at 16:00 -0600, Stephen Warren wrote:
On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
querying keyboards isn't a time critical task and does not depend on
exact timing in the microseconds order -- the timeouts and delays are
arbitrary choices or educated guesses at best anyway
diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
@@ -93,7 +93,10 @@ Optional Properties:
a column line and reading back its row status,
such that pin levels can settle after
propagating through the matrix and its
- associated hardware components
+ associated hardware components, can be specified
+ with either one value giving the exact delay, or
+ with two values giving a delay range (allowing
+ for reduced timer management overhead)
- col-switch-delay-ms: columns switch interval in milliseconds instead
of using interrupts to detect key press changes,
enables polling mode when specified
@@ -146,7 +149,7 @@ Examples:
matrix_keypad {
compatible = gpio-matrix-keypad;
debounce-delay-ms = 5;
- col-scan-delay-us = 1;
+ col-scan-delay-us = 2 10;
Is it really useful to change the binding this way?
The values in DT presumably represent the minimum delays that the HW
will tolerate or that are useful. SW is always free to scan more slowly
than that. As such, if you're simply modifying the driver to allow more
flexibility in timing, then I don't think you have to modify the DT
binding to allow for this?
Yes, this puts less burdon on the .dts author. The problem
would be to come up (programmatically, without the user's spec)
with an appropriate upper bound.
One might choose half the col switch delay when available (in
the polling scenario). Or three times the lower bound. Or an
arbitrary upper bound in the 100us order. Or actually with the
minimum of all the above. That should keep the absolute minimum
(user specified) in the loop, and scan the keys fast enough, yet
drastically reduce timer management overhead, and hide all of
this from the .dts author.
I will ponder this for a moment ...
Shouldn't this be driven by whatever key repeat delays the user
configured in SW; scan only fast enough to implement the correct repeat
delay/rate?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] serial:st-asc: Add ST ASC driver.
On Mon, Jun 24, 2013 at 08:21:43AM +0100, Srinivas KANDAGATLA wrote: From: Srinivas Kandagatla srinivas.kandaga...@st.com This patch adds support to ASC (asynchronous serial controller) driver, which is basically a standard serial driver. This IP is common across all the ST parts for settop box platforms. ASC is embedded in ST COMMS IP block. It supports Rx Tx functionality. It support all industry standard baud rates. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Stephen Gallimore stephen.gallim...@st.com CC: Stuart Menefy stuart.men...@st.com CC: Arnd Bergmann a...@arndb.de --- Hi Greg, This patch is the part of the driver support for Sti SOCs. This patch undergone 3-4 cycles of review in arm-kernel mailing list. As Arnd prefered to take only SOC support patches via arm-soc, Am sending this patch seperately. If its not too late, can you consider this patch for 3.11 via tty tree? I would have taken it, but it breaks the build on my machine: drivers/tty/serial/st-asc.c: In function ‘asc_serial_resume’: drivers/tty/serial/st-asc.c:774:15: error: ‘struct device’ has no member named ‘pins’ drivers/tty/serial/st-asc.c:775:3: error: implicit declaration of function ‘pinctrl_select_state’ [-Werror=implicit-function-declaration] drivers/tty/serial/st-asc.c:775:37: error: ‘struct device’ has no member named ‘pins’ drivers/tty/serial/st-asc.c:776:16: error: ‘struct device’ has no member named ‘pins’ Please test your patches out on a normal Linux system. Please feel free to resend this after 3.11-rc1 is out, for inclusion in 3.12, after you have fixed the build problems. greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] gpio MIPS/OCTEON: Add a driver for OCTEON's on-chip GPIO pins.
Thanks for looking at this again.
I will be away from my office until the middle of July, so I will not be
able to generate and test a revised patch until then.
David Daney
On 06/24/2013 03:06 PM, Linus Walleij wrote:
On Thu, Jun 20, 2013 at 8:10 PM, David Daney ddaney.c...@gmail.com wrote:
On 06/17/2013 01:51 AM, Linus Walleij wrote:
+#include asm/octeon/octeon.h
+#include asm/octeon/cvmx-gpio-defs.h
I cannot find this in my tree.
Weird, I see them here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/asm/octeon/cvmx-gpio-defs.h
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/asm/octeon/octeon.h
Do you not have these?
Yeah no problem, I must have misgrepped.
Sorry for the fuzz...
depend on OF as well right? Or does the CAVIUM_OCTEON_SOC already
imply that?
We already have 'select USE_OF', so I think adding OF here would be
redundant.
OK.
+/*
+ * The address offset of the GPIO configuration register for a given
+ * line.
+ */
+static unsigned int bit_cfg_reg(unsigned int gpio)
Maybe the passed variable shall be named offset here, as it is named
offset on all call sites, and it surely local for this instance?
Well it is the gpio line, so perhaps it should universally be change to
line or pin
We use offset to signify line enumerators in drivers/gpio/*
well atleaste if they are local to a piece of hardware.
(Check the GPIO siblings.)
+{
+ if (gpio 16)
+ return 8 * gpio;
+ else
+ return 8 * (gpio - 16) + 0x100;
Put this 0x100 in the #defines above with the name something like
STRIDE.
But it is not a 'STRIDE', it is a discontinuity compensation and used in
exactly one place.
OK what about a comment or something, because it isn't
exactly intuitive right?
+struct octeon_gpio {
+ struct gpio_chip chip;
+ u64 register_base;
+};
OMG everything is 64 bit. Well has to come to this I guess.
Not everything. This is custom logic in an SoC with 64-bit wide internal
address buses, what would you suggest?
Yep that's what I meant, no big deal. Just first time
I really see it in driver bases.
I'm not a fan of packed bitfields like this, I prefer if you just
OR | and AND the bits together in the driver.
I see you disregarded this comment, and looking at the header
files it seems the MIPS arch is a big fan if packed bitfields so
will live with it for this arch...
+static int octeon_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct octeon_gpio *gpio = container_of(chip, struct octeon_gpio,
chip);
+ u64 read_bits = cvmx_read_csr(gpio-register_base + RX_DAT);
+
+ return ((1ull offset) read_bits) != 0;
A common idiom we use for this is:
return !!(read_bits (1ull offset));
I hate that idiom, but if its use is a condition of accepting the patch, I
will change it.
Nah. If a good rational reason like hate is given for not using a coding
idiom I will accept it as it stands ;-)
+ dev_info(pdev-dev, OCTEON GPIO\n);
This is like shouting REAL MADRID! in the bootlog, be a bit more
precise: octeon GPIO driver probed\n or something so we know what
is happening.
No, more akin to 'Real Madrid', as 'OCTEON' is the correct spelling of its
given name.
I will happily add driver probed, and grudgingly switch to lower case if
it is a necessary condition of patch acceptance.
I don't know, does this rest of the MIPS drivers emit similar messages
such that the bootlog will say
OCTEON clocks
OCTEON irqchip
OCTEON I2C
OCTEON GPIO
then I guess it's convention and it can stay like this.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V10 1/4] pci: Add PCIe driver for Samsung Exynos
Bjorn Helgaas wrote: On Fri, Jun 21, 2013 at 04:24:54PM +0900, Jingoo Han wrote: Exynos5440 has a PCIe controller which can be used as Root Complex. This driver supports a PCIe controller as Root Complex mode. Signed-off-by: Surendranath Gurivireddy Balla suren.re...@samsung.com Signed-off-by: Siva Reddy Kallam siva.kal...@samsung.com Signed-off-by: Jingoo Han jg1@samsung.com Acked-by: Arnd Bergmann a...@arndb.de Acked-by: Bjorn Helgaas bhelg...@google.com Please merge this through arm-soc as you discussed. Sounds great. Arnd, please take this series into arm-soc tree directly by yourself with my ack on arch/exynos stuff if you want ;) Thanks, - Kukjin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
