[PATCH v3 0/2] DMM DT adaptation
The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the removal of address and irq data from the omap4 hwmods, the probe of DMM driver fails and omapdrm isn't able to utilize the DMM hardware. Add DMM bindings for omap4 and omap5. Changes in v3: - Fix mistakes in documentation and remove aliases for dmm nodes. Changes in v2: - No changes, split out into a separate series containing only DT related parts. Archit Taneja (2): arm: dts: omap4+: Add DMM bindings drm: omap: Enable DT support for DMM Documentation/devicetree/bindings/arm/omap/dmm.txt | 16 arch/arm/boot/dts/omap4.dtsi | 7 +++ arch/arm/boot/dts/omap5.dtsi | 7 +++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++ 4 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] arm: dts: omap4+: Add DMM bindings
Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.
Add documentation for the DMM bindings.
Originally worked on by Andy Gross andy...@gmail.com
Cc: Andy Gross andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
Documentation/devicetree/bindings/arm/omap/dmm.txt | 16
arch/arm/boot/dts/omap4.dtsi | 7 +++
arch/arm/boot/dts/omap5.dtsi | 7 +++
3 files changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..6fc3d79
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,16 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+Required properties:
+- compatible: Must be ti,omap4-dmm for OMAP4 family
+ Must be ti,omap5-dmm for OMAP5 and DRA7x family
+- reg: Contains timer register address range (base address and length)
+- interrupts: Contains interrupt information (source, etc) for the DMM IRQ
+- ti,hwmods: Name of the hwmod associated to DMM, which is typically dmm
+
+Example:
+
+dmm@4e00 {
+ compatible = ti,omap4-dmm;
+ reg = 0x4e00 0x800;
+ ti,hwmods = dmm;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..b6bf288 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -487,6 +487,13 @@
ti,hwmods = kbd;
};
+ dmm@4e00 {
+ compatible = ti,omap4-dmm;
+ reg = 0x4e00 0x800;
+ interrupts = 0 113 0x4;
+ ti,hwmods = dmm;
+ };
+
emif1: emif@4c00 {
compatible = ti,emif-4d;
reg = 0x4c00 0x100;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..e405458 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,6 +604,13 @@
ti,hwmods = wd_timer2;
};
+ dmm@4e00 {
+ compatible = ti,omap5-dmm;
+ reg = 0x4e00 0x800;
+ interrupts = 0 113 0x4;
+ ti,hwmods = dmm;
+ };
+
emif1: emif@0x4c00 {
compatible = ti,emif-4d5;
ti,hwmods = emif1;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] drm: omap: Enable DT support for DMM
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross andy...@gmail.com
Cc: Andy Gross andy...@gmail.com
Cc: DRI Development dri-de...@lists.freedesktop.org
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..59f17de 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -968,12 +968,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
};
#endif
+#if defined(CONFIG_OF)
+static const struct of_device_id dmm_of_match[] = {
+ { .compatible = ti,omap4-dmm, },
+ { .compatible = ti,omap5-dmm, },
+ {},
+};
+#else
+#define dmm_of_match NULL
+#endif
+
struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+ .of_match_table = dmm_of_match,
#ifdef CONFIG_PM
.pm = omap_dmm_pm_ops,
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On 10/09/2013 09:59 PM, Paul Walmsley wrote: Eh, one correction: On Wed, 9 Oct 2013, Paul Walmsley wrote: We could easily wind up with kernels that won't boot at all when used with newer DT data. This is a misstatement of the issue: the concern here is that newer kernels may not boot at all with older DT data - which could easily be in locked areas of the flash or firmware. I wonder who would be crazy enough to put DT data into a locked area, and to what purpose. If you can update the kernel, there is no point locking down DT data, this will just cause you unnecessary misery. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
From: R Sricharan r.sricha...@ti.com
The realtime counter called master counter, produces the count
used by the private timer peripherals in the MPU_CLUSTER. The
CNTFRQ per cpu register is used to denote the frequency of the counter.
Currently the frequency value is passed from the
DT file, but this is not scalable when we have other non-DT guest
OS. This register must be set to the right value by the
secure rom code. Setting this register helps in propagating the right
frequency value across OSes.
More discussions and the reason for adding this in a non-DT
way can be seen from below.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html
So configuring this secure register for all the cpus here.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Tony Lindgren t...@atomide.com
Tested-by: Nishanth Menon n...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V5] Removed the use of extern variable in omap-smp.c
as per suggestion from Santosh Shilimkar santosh.shilim...@ti.com
arch/arm/mach-omap2/omap-secure.h |4
arch/arm/mach-omap2/omap-smp.c|7 +++
arch/arm/mach-omap2/timer.c | 10 ++
3 files changed, 21 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..a5ee09d 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -42,6 +42,8 @@
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
+#define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX0x109
+
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
@@ -60,5 +62,7 @@ extern int omap_barrier_reserve_memblock(void);
static inline void omap_barrier_reserve_memblock(void)
{ }
#endif
+
+void set_cntfreq(void);
#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 22c3129..b1c6e5d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -78,6 +78,13 @@ static void omap4_secondary_init(unsigned int cpu)
4, 0, 0, 0, 0, 0);
/*
+* Configure the CNTFRQ register for the secondary cpu's which
+* indicates the frequency of the cpu local timers.
+*/
+ if (soc_is_omap54xx() || soc_is_dra7xx())
+ set_cntfreq();
+
+ /*
* Synchronise with the boot thread.
*/
spin_lock(boot_lock);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fa74a06..60df58a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -55,6 +55,7 @@
#include soc.h
#include common.h
#include powerdomain.h
+#include omap-secure.h
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
@@ -65,6 +66,12 @@
static struct omap_dm_timer clkev;
static struct clock_event_device clockevent_gpt;
+static unsigned long arch_timer_freq;
+
+void set_cntfreq(void)
+{
+ omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
+}
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
@@ -542,6 +549,9 @@ static void __init realtime_counter_init(void)
reg |= den;
__raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
+ arch_timer_freq = (rate / den) * num;
+ set_cntfreq();
+
iounmap(base);
}
#else
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DRA: DTS: Remove clock-frequency field for cpu timers
The arm arch timers frequency are now programmed in the CNTFREQ
per-cpu register by the timer code using the secure API [1].
So remove the redundant entry from the dts.
[1] http://marc.info/?l=linux-omapm=138139106312786w=2
Cc: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 37f606b..f25adc5 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -52,7 +52,6 @@
GIC_PPI 14 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 11 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 10 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW);
- clock-frequency = 6144000;
};
gic: interrupt-controller@48211000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: Clear ARDY bit twice
On Mon, Oct 07, 2013 at 01:41:59PM +0300, Taras Kondratiuk wrote: Initially commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac i2c-omap: Double clear of ARDY status in IRQ handler added a workaround for undocumented errata ProDB0017052. But then commit 1d7afc95946487945cc7f5019b41255b72224b70 i2c: omap: ack IRQ in parts refactored code and missed one of ARDY clearings. So current code violates errata. It causes often i2c bus timeouts on my Pandaboard. This patch adds a second clearing in place. Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org Applied to for-current with stable tag, thanks! signature.asc Description: Digital signature
Re: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
Hey Paul, My dibs on this below. On 10/09/2013 09:55 PM, Paul Walmsley wrote: On Mon, 7 Oct 2013, Tony Lindgren wrote: And assuming Paul is OK with these patches in general. Actually, I have several concerns with this series, as you and I discussed. Some of us have been talking them over with other folks for the past few months to try to figure out what to do. Most of the concerns have fairly easy technical solutions, but we shouldn't merge these patches until they're resolved. The issues are: 1. whether the clock data should go into DT 2. what the right place for DT clock data is in the DT 3. whether it makes sense to merge experimental DT bindings in this case 4. where clockdomain data belongs The first issue - and the one I'm least concerned about - is that, in my view, it still does not make technical sense to move this data into DT. This is chip-level hardware data that never needs to be changed by board designers or end users. Adding it to DT is going to result in a boot-time cost (due to DT parse overhead) and additional memory consumption for very little benefit, compared to an implementation that places this data into a dynamically loadable module. For some users, the boot-time bloat is a big deal: the example that's been mentioned to me recently is an automotive back-up camera that needs to cold-boot to complete functionality in a few hundred microseconds. Personally I share the concern, I don't see much point in using the DT for any kind of purpose... it is just another binary compatibility breaker in the picture in addition to boot-loader, and it basically does not solve any _real_ problems either. Boot time issues can be solved by adding alternative clock data sources like Tony pointed out, granted, we don't have support for those yet, but we need to start somewhere. However, according to some other upstream maintainers, Linus's goal is to move most of the device-specific static data out of the kernel tree, into DT files (in the ARM case). If that non-technical constraint is indeed the dominant consideration, then I agree that moving this data to DT is the only viable course of action. Yeah... Personally I can't see any other way forward right now either as I was basically given the option to use DT for this work or not do it at all... ... The second issue concerns where the SoC clock nodes should go in the DT. In these patches, the clock data has been encoded in a large clocks node off the top level. This is almost certainly not the right thing to do from a device hardware point of view. These clocks don't exist as standalone devices with their own address spaces decoded on the interconnect. In all of the SoC cases that I'm aware of, clock control registers are part of larger IP blocks. For example, in the OMAP case, most of the system integration clock control registers are part of the OMAP-specific PRCM block, PRM block, or CM block. Then there are other device-specific clocks, like DSS PLLs or UART dividers. The control registers for these are generally located in the subsystem or device IP block itself, and are inaccessible when the subsystem or IP block is disabled. These device-specific clocks belong to the IP block, not the SoC integration. So, for example, if two SoCs use the same IP block, then the clock registers, and their offsets from the IP block address space base, are likely to be identical. None of the clock registers defined in this set reside outside PRCM / control module, so they are always accessible. IP block internal dividers for UART and like, are defined and used only internally by the device drivers. So in my view, the right things to do here are to: 1. associate SoC DT clock data with the device node that contains the clock control registers So, either cm, prcm, and maybe control_module instead of current clocks. How much do we benefit from this? This would get rid of need to call of_iomap() for each register basically. 2. specify relative offsets for clock registers from the start of the IP block address range, rather than absolute addresses for clock registers 3. place the responsibility for registering clocks into the IP block drivers themselves This naturally separates clocks into per-IP block DT files. It also provides the CCF with an easy way to ensure that the device that encloses the clock is enabled and accessible by the CPU core, before trying to access registers inside. Similarly, non-SoC off-chip clock data (such as for dedicated I2C PLLs) should also be associated with their I2C device node. Making these changes to Tero's existing patches should be relatively straightforward, based on what I've seen. For the set, it doesn't matter where the clock nodes reside, if someone can point me out where to put them, they can be easily moved around. Separating the individual clocks based on their IP mapping can probably just be done by checking their register address.
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi,
On 10/10/13 00:08, Marek Belisko wrote:
For communicating with driver is used gpio bitbanging because TD028 does
not have a standard compliant SPI interface. It is a 3-wire thing with
direction reversal.
Isn't that SPI_3WIRE?
Communication with display is used only during panel enable/disable so it's
not performance issue.
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 537
+
include/video/omap-panel-data.h| 22 +
4 files changed, 566 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index 6c90885..3f86432 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -56,6 +56,11 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config DISPLAY_PANEL_TPO_TD028TTEC1
+tristate TPO TD028TTEC1 LCD Panel
+help
+ LCD panel used by Openmoko.
+
config DISPLAY_PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on SPI
@@ -70,4 +75,5 @@ config DISPLAY_PANEL_NEC_NL8048HL11
This NEC NL8048HL11 panel is TFT LCD used in the
Zoom2/3/3630 sdp boards.
+
Extra change.
endmenu
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..0323a8a 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
new file mode 100644
index 000..b63586e
--- /dev/null
+++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -0,0 +1,537 @@
+/*
+ * Toppoly TD028TTEC1 panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Neo 1973 code (jbt6k74.c):
+ * Copyright (C) 2006-2007 by OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ *
+ * Ported and adapted from Neo 1973 U-Boot by:
+ * H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int data_lines;
+
+ struct omap_video_timings videomode;
+
+ int cs_gpio;
+ int scl_gpio;
+ int din_gpio;
+ int dout_gpio;
Three wires, but four gpios? What am I missing here...
+ u_int16_t tx_buf[4];
Hmm, what's wrong with u16?
+};
+
+static struct omap_video_timings td028ttec1_panel_timings = {
+ .x_res = 480,
+ .y_res = 640,
+ .pixel_clock= 22153,
+ .hfp= 24,
+ .hsw= 8,
+ .hbp= 8,
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+};
+
+#define JBT_COMMAND 0x000
+#define JBT_DATA 0x100
+
+/* 150uS minimum clock cycle, we have two of this plus our other
+ * instructions */
+
+#define SPI_DELAY() udelay(200)
Would
Re: [PATCH v2 5/6] Revert ARM: OMAP2+: Provide alias to USB PHY clock
On 10/09/2013 06:15 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [131009 00:19]: Hi Tony, On 10/08/2013 01:06 PM, Roger Quadros wrote: This reverts commit 741532c4a995be11815cb72d4d7a48f442a22fea. The proper clock reference is provided in device tree so we no longer need this. Could you please Ack this one? I think it is best if it goes through Benoit's tree. I could queue this into my board removal series that will be based on Benoit's branch if that works for you. And this also seems to depend on the omap-for-v3.13/quirk branch that moves all the legacy pdata handling into pdata-quirks.c. OK Tony. Thanks. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/6] mfd: omap-usb: prepare/unprepare clock while enable/disable
Hi Samuel,
Could you please pick this one for 3.13 if OK? Thanks.
cheers,
-roger
On 10/08/2013 01:06 PM, Roger Quadros wrote:
This should fix the following warning at boot on OMAP5 uEVM
[8.783155] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:883
__clk_enable+0x94/0xa4()
CC: Samuel Ortiz sa...@linux.intel.com
CC: Lee Jones lee.jo...@linaro.org
CC: Tero Kristo t-kri...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 16
drivers/mfd/omap-usb-tll.c |4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 29ee54d..a5b91f1 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -328,13 +328,13 @@ static int usbhs_runtime_resume(struct device *dev)
omap_tll_enable(pdata);
if (!IS_ERR(omap-ehci_logic_fck))
- clk_enable(omap-ehci_logic_fck);
+ clk_prepare_enable(omap-ehci_logic_fck);
for (i = 0; i omap-nports; i++) {
switch (pdata-port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
if (!IS_ERR(omap-hsic60m_clk[i])) {
- r = clk_enable(omap-hsic60m_clk[i]);
+ r = clk_prepare_enable(omap-hsic60m_clk[i]);
if (r) {
dev_err(dev,
Can't enable port %d hsic60m
clk:%d\n,
@@ -343,7 +343,7 @@ static int usbhs_runtime_resume(struct device *dev)
}
if (!IS_ERR(omap-hsic480m_clk[i])) {
- r = clk_enable(omap-hsic480m_clk[i]);
+ r = clk_prepare_enable(omap-hsic480m_clk[i]);
if (r) {
dev_err(dev,
Can't enable port %d hsic480m
clk:%d\n,
@@ -354,7 +354,7 @@ static int usbhs_runtime_resume(struct device *dev)
case OMAP_EHCI_PORT_MODE_TLL:
if (!IS_ERR(omap-utmi_clk[i])) {
- r = clk_enable(omap-utmi_clk[i]);
+ r = clk_prepare_enable(omap-utmi_clk[i]);
if (r) {
dev_err(dev,
Can't enable port %d clk : %d\n,
@@ -382,15 +382,15 @@ static int usbhs_runtime_suspend(struct device *dev)
switch (pdata-port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
if (!IS_ERR(omap-hsic60m_clk[i]))
- clk_disable(omap-hsic60m_clk[i]);
+ clk_disable_unprepare(omap-hsic60m_clk[i]);
if (!IS_ERR(omap-hsic480m_clk[i]))
- clk_disable(omap-hsic480m_clk[i]);
+ clk_disable_unprepare(omap-hsic480m_clk[i]);
/* Fall through as utmi_clks were used in HSIC mode */
case OMAP_EHCI_PORT_MODE_TLL:
if (!IS_ERR(omap-utmi_clk[i]))
- clk_disable(omap-utmi_clk[i]);
+ clk_disable_unprepare(omap-utmi_clk[i]);
break;
default:
break;
@@ -398,7 +398,7 @@ static int usbhs_runtime_suspend(struct device *dev)
}
if (!IS_ERR(omap-ehci_logic_fck))
- clk_disable(omap-ehci_logic_fck);
+ clk_disable_unprepare(omap-ehci_logic_fck);
omap_tll_disable(pdata);
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..1e57712 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -429,7 +429,7 @@ int omap_tll_enable(struct usbhs_omap_platform_data
*pdata)
if (IS_ERR(tll-ch_clk[i]))
continue;
- r = clk_enable(tll-ch_clk[i]);
+ r = clk_prepare_enable(tll-ch_clk[i]);
if (r) {
dev_err(tll_dev,
Error enabling ch %d clock: %d\n, i, r);
@@ -460,7 +460,7 @@ int omap_tll_disable(struct usbhs_omap_platform_data
*pdata)
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
if (!IS_ERR(tll-ch_clk[i]))
- clk_disable(tll-ch_clk[i]);
+ clk_disable_unprepare(tll-ch_clk[i]);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi Tomi,
Am 10.10.2013 um 10:19 schrieb Tomi Valkeinen:
Hi,
On 10/10/13 00:08, Marek Belisko wrote:
For communicating with driver is used gpio bitbanging because TD028 does
not have a standard compliant SPI interface. It is a 3-wire thing with
direction reversal.
Isn't that SPI_3WIRE?
Maybe - but we have no complete datasheet and I don't know an official spec of
a 3-wire SPI protocol to compare how 3-wire should work.
And I think (but I may be wrong) that SPI_3WIRE is an optional feature of the
SoC
specific SPI drivers and in my understanding the OMAP has no such driver:
http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L874
And spi-bitbang.c hasn't either.
So I would prefer to leave this as an area for optimizations for future work.
Maybe we can add some more comments on this.
Communication with display is used only during panel enable/disable so it's
not performance issue.
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 537
+
include/video/omap-panel-data.h| 22 +
4 files changed, 566 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index 6c90885..3f86432 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -56,6 +56,11 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config DISPLAY_PANEL_TPO_TD028TTEC1
+tristate TPO TD028TTEC1 LCD Panel
+help
+ LCD panel used by Openmoko.
+
config DISPLAY_PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on SPI
@@ -70,4 +75,5 @@ config DISPLAY_PANEL_NEC_NL8048HL11
This NEC NL8048HL11 panel is TFT LCD used in the
Zoom2/3/3630 sdp boards.
+
Extra change.
endmenu
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..0323a8a 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
new file mode 100644
index 000..b63586e
--- /dev/null
+++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -0,0 +1,537 @@
+/*
+ * Toppoly TD028TTEC1 panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Neo 1973 code (jbt6k74.c):
+ * Copyright (C) 2006-2007 by OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ *
+ * Ported and adapted from Neo 1973 U-Boot by:
+ * H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+struct omap_dss_device dssdev;
+struct omap_dss_device *in;
+
+int data_lines;
+
+struct omap_video_timings videomode;
+
+int cs_gpio;
+int scl_gpio;
+int din_gpio;
+int dout_gpio;
Three wires, but four gpios? What am I missing here...
We have wired up the 3-wire SPI interface of the display
to 4 wires of the McSPI interface because we initially thought
that it could work in 4 wire mode as well.
The next step we did was to port the driver code from the
Openmoko Neo1973 U-Boot which used the gpio-bitbang
mechanism.
Since it
Re: [PATCH v3 1/2] arm: dts: omap4+: Add DMM bindings
On Thu, Oct 10, 2013 at 07:36:33AM +0100, Archit Taneja wrote: Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM only requires address and irq information. Add documentation for the DMM bindings. Originally worked on by Andy Gross andy...@gmail.com Cc: Andy Gross andy...@gmail.com Signed-off-by: Archit Taneja arc...@ti.com --- Documentation/devicetree/bindings/arm/omap/dmm.txt | 16 arch/arm/boot/dts/omap4.dtsi | 7 +++ arch/arm/boot/dts/omap5.dtsi | 7 +++ 3 files changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt b/Documentation/devicetree/bindings/arm/omap/dmm.txt new file mode 100644 index 000..6fc3d79 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt @@ -0,0 +1,16 @@ +OMAP Dynamic Memory Manager (DMM) bindings Is there any documentation? A brief description of what this is would be nice. + +Required properties: +- compatible:Must be ti,omap4-dmm for OMAP4 family + Must be ti,omap5-dmm for OMAP5 and DRA7x family s/must be/should contain/ +- reg: Contains timer register address range (base address and length) Huh? What's a timer got to do with the DMM? +- interrupts:Contains interrupt information (source, etc) for the DMM IRQ Is there a single interrupt? If so: - interrupts: Should contain an interrupt-specifier for the DMM IRQ. Assuming the DMM IRQ is well defined. If there's a name for it in documentation, using that's preferable. If a future revision may have multiple interrupts, please use interrupt-names now to save us endless pain in future. Cheers, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Thursday 12 September 2013 03:57 PM, Vivek Gautam wrote:
On Thu, Sep 12, 2013 at 3:40 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Thursday 12 September 2013 02:57 PM, Vivek Gautam wrote:
Hi Kishon,
On Mon, Sep 2, 2013 at 9:13 PM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
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/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
I have a doubt here.
As i can see in the current phy drivers structuring, for OMAP there
are two phy drivers :
omap phy-omap-usb2 (talking to musb controller)
It talks to dwc3 controller also ;-)
Ok
and phy-omap-usb3(talking to dwc3 controller).
Now dwc3 controller requests both usb2-phy (supported by phy-omap-usb2
?) and usb3-phy (supported by phy-omap-usb3 ?).
But phy-omap-usb2 is not the one designated to talk to DWC3
controller, then why does still DWC3 want to request usb2-phy, which
end of the day will be phy-omap-usb2.
May be i am wrong here since i don't have knowledge about OMAP h/w
architecture.
Is it like phy-omap-usb2 includes UTMI phys for both musb controller
as well as dwc3 controller ?
right. It's needed for dwc3 too. The same USB2 PHY IP is used for both MUSB
in
OMAP2+ platforms and DWC3 in OMAP5.
Ok, but on Samsung's exynos5 series of SoCs, the USB2.0 controller has
a separate USB-PHY interface talking to phy-samsung-usb2 driver;
and DWC3 drd controller has separate USB-PHY interface (including both
UTMI+ and PIPE3 control registers) talking to phy-samsung-usb3 driver.
So in this
Re: [PATCH v3 1/2] arm: dts: omap4+: Add DMM bindings
Hi, On Thursday 10 October 2013 03:38 PM, Mark Rutland wrote: On Thu, Oct 10, 2013 at 07:36:33AM +0100, Archit Taneja wrote: Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM only requires address and irq information. Add documentation for the DMM bindings. Originally worked on by Andy Gross andy...@gmail.com Cc: Andy Gross andy...@gmail.com Signed-off-by: Archit Taneja arc...@ti.com --- Documentation/devicetree/bindings/arm/omap/dmm.txt | 16 arch/arm/boot/dts/omap4.dtsi | 7 +++ arch/arm/boot/dts/omap5.dtsi | 7 +++ 3 files changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt b/Documentation/devicetree/bindings/arm/omap/dmm.txt new file mode 100644 index 000..6fc3d79 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt @@ -0,0 +1,16 @@ +OMAP Dynamic Memory Manager (DMM) bindings Is there any documentation? A brief description of what this is would be nice. I'll do that. + +Required properties: +- compatible: Must be ti,omap4-dmm for OMAP4 family + Must be ti,omap5-dmm for OMAP5 and DRA7x family s/must be/should contain/ +- reg: Contains timer register address range (base address and length) Huh? What's a timer got to do with the DMM? Err, my mistake! +- interrupts: Contains interrupt information (source, etc) for the DMM IRQ Is there a single interrupt? If so: - interrupts: Should contain an interrupt-specifier for the DMM IRQ. Okay. Assuming the DMM IRQ is well defined. If there's a name for it in documentation, using that's preferable. If a future revision may have multiple interrupts, please use interrupt-names now to save us endless pain in future. The IRQ is called DMM_IRQ in the documentation. I don't think there would be more than one interrupt line from this IP. I'll still cross check. Thanks, Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
- regulator-always-on;
- regulator-boot-on;
};
ldo1_reg: ldo1 {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3
From: George Cherian george.cher...@ti.com Added dr_mode property in dwc3 and set its default mode to device. Signed-off-by: George Cherian george.cher...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/boot/dts/omap5.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 6d0a1d5..ef598af 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -652,6 +652,7 @@ reg = 0x4a03 0x1; interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH; usb-phy = usb2_phy, usb3_phy; + dr_mode = peripheral; tx-fifo-resize; }; }; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 10/10/13 12:34, Dr. H. Nikolaus Schaller wrote:
Hi Tomi,
Am 10.10.2013 um 10:19 schrieb Tomi Valkeinen:
Hi,
On 10/10/13 00:08, Marek Belisko wrote:
For communicating with driver is used gpio bitbanging because TD028 does
not have a standard compliant SPI interface. It is a 3-wire thing with
direction reversal.
Isn't that SPI_3WIRE?
Maybe - but we have no complete datasheet and I don't know an official spec of
a 3-wire SPI protocol to compare how 3-wire should work.
Yep, and I know only what I read on wikipedia a few hours ago =).
And I think (but I may be wrong) that SPI_3WIRE is an optional feature of the
SoC
specific SPI drivers and in my understanding the OMAP has no such driver:
http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L874
And spi-bitbang.c hasn't either.
So I would prefer to leave this as an area for optimizations for future work.
Maybe we can add some more comments on this.
Ok. Well, I guess it's not too bad. But it's really not something that
should be in the panel driver (assuming it's standard 3-wire SPI).
Some SoC could support 3-wire SPI, and then it'd be good to use the SoCs
hardware for SPI communication. Having bitbanging hardcoded into the
driver will prevent that.
+ int cs_gpio;
+ int scl_gpio;
+ int din_gpio;
+ int dout_gpio;
Three wires, but four gpios? What am I missing here...
We have wired up the 3-wire SPI interface of the display
to 4 wires of the McSPI interface because we initially thought
that it could work in 4 wire mode as well.
The next step we did was to port the driver code from the
Openmoko Neo1973 U-Boot which used the gpio-bitbang
mechanism.
Since it worked and is used only for enabling/disabling the
display and for no other purpose we never felt it important
to check or modify the code to use SPI.
But you are right - we don't use the din_gpio really since
we never read registers from the chip. So 3 gpios could be
sufficient.
Or we must handle the case that din_gpio == dout_gpio
in panel_probe to avoid duplicate use of the same gpio.
The panel hardware has three wires, so the panel driver (if it does
handle the bus by bitbanging) can only refer to three gpios. So either
the bus details should be hidden by using the normal spi framework, or
if the driver does the bitbanging, use the gpios as specified in the
panel spec. The panel driver cannot contain any board specific stuff.
+static int jbt_spi_xfer(struct panel_drv_data *data, int wordnum, int
bitlen)
Hmm, if it's not SPI, maybe it shouldn't be called SPI?
Yes, we can remove the _spi_ in this name.
Or maybe use spi3w or such, just to make it clear it's not plain
standard spi. Again, presuming it's really 3-wire spi =).
+static int td028ttec1_panel_probe(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata;
+ struct omap_dss_device *dssdev;
+ int r;
+
+ ddata = devm_kzalloc(pdev-dev, sizeof(*ddata), GFP_KERNEL);
+ if (ddata == NULL)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, ddata);
+
+ if (dev_get_platdata(pdev-dev)) {
+ r = td028ttec1_panel_probe_pdata(pdev);
+ if (r)
+ return r;
+ } else {
+ return -ENODEV;
+ }
+
+ if (gpio_is_valid(ddata-cs_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-cs_gpio,
+ GPIOF_OUT_INIT_HIGH, lcd cs);
+ if (r)
+ goto err_gpio;
+ }
+
+ if (gpio_is_valid(ddata-scl_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-scl_gpio,
+ GPIOF_OUT_INIT_HIGH, lcd scl);
+ if (r)
+ goto err_gpio;
+ }
+
+ if (gpio_is_valid(ddata-dout_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-dout_gpio,
+ GPIOF_OUT_INIT_LOW, lcd dout);
+ if (r)
+ goto err_gpio;
+ }
+
+ if (gpio_is_valid(ddata-din_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-din_gpio,
+ GPIOF_IN, lcd din);
+ if (r)
+ goto err_gpio;
+ }
+
+ /* according to data sheet: wait 50ms (Tpos of LCM). However, 50ms
+* seems unreliable with later LCM batches, increasing to 90ms */
+ mdelay(90);
What is this delay for? Usually sleeps/delays should be between two HW
actions. Here there's nothing below this line that would count as such
an action.
I guess that this delay is intended to power on the display first, then wait
some
I'm not very comfortable with merging a driver, when the driver author
guesses what parts of the driver do =).
time and after that delay enable the DSS clocks and signals and make the
controller chip in the panel initialize.
I don't see the code before the delay doing any power up, it just sets
the data bus gpios to certain state. Do those gpio initializations power
up the panel?
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi Tomi,
Am 10.10.2013 um 13:10 schrieb Tomi Valkeinen:
On 10/10/13 12:34, Dr. H. Nikolaus Schaller wrote:
Hi Tomi,
Am 10.10.2013 um 10:19 schrieb Tomi Valkeinen:
Hi,
On 10/10/13 00:08, Marek Belisko wrote:
For communicating with driver is used gpio bitbanging because TD028 does
not have a standard compliant SPI interface. It is a 3-wire thing with
direction reversal.
Isn't that SPI_3WIRE?
Maybe - but we have no complete datasheet and I don't know an official spec
of
a 3-wire SPI protocol to compare how 3-wire should work.
Yep, and I know only what I read on wikipedia a few hours ago =).
And I think (but I may be wrong) that SPI_3WIRE is an optional feature of
the SoC
specific SPI drivers and in my understanding the OMAP has no such driver:
http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L874
And spi-bitbang.c hasn't either.
So I would prefer to leave this as an area for optimizations for future work.
Maybe we can add some more comments on this.
Ok. Well, I guess it's not too bad. But it's really not something that
should be in the panel driver (assuming it's standard 3-wire SPI).
Some SoC could support 3-wire SPI, and then it'd be good to use the SoCs
hardware for SPI communication. Having bitbanging hardcoded into the
driver will prevent that.
Yes, I agree and I am willing to help if someone comes up with such a SoC.
At the moment we have connected it to the OMAP3 only.
I.e. I want not to do a lot of work for others who we just guess about that they
might exist...
+ int cs_gpio;
+ int scl_gpio;
+ int din_gpio;
+ int dout_gpio;
Three wires, but four gpios? What am I missing here...
We have wired up the 3-wire SPI interface of the display
to 4 wires of the McSPI interface because we initially thought
that it could work in 4 wire mode as well.
The next step we did was to port the driver code from the
Openmoko Neo1973 U-Boot which used the gpio-bitbang
mechanism.
Since it worked and is used only for enabling/disabling the
display and for no other purpose we never felt it important
to check or modify the code to use SPI.
But you are right - we don't use the din_gpio really since
we never read registers from the chip. So 3 gpios could be
sufficient.
Or we must handle the case that din_gpio == dout_gpio
in panel_probe to avoid duplicate use of the same gpio.
The panel hardware has three wires, so the panel driver (if it does
handle the bus by bitbanging) can only refer to three gpios.
Hm. The panle hardware has 3 but the SoC (OMAP3) the driver
is running on has 4.
So either
the bus details should be hidden by using the normal spi framework, or
if the driver does the bitbanging, use the gpios as specified in the
panel spec. The panel driver cannot contain any board specific stuff.
The bitbang driver shown below can handle either 3 or 4 gpios (except
for initialization).
+static int jbt_spi_xfer(struct panel_drv_data *data, int wordnum, int
bitlen)
Hmm, if it's not SPI, maybe it shouldn't be called SPI?
Yes, we can remove the _spi_ in this name.
Or maybe use spi3w or such, just to make it clear it's not plain
standard spi. Again, presuming it's really 3-wire spi =).
+static int td028ttec1_panel_probe(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata;
+ struct omap_dss_device *dssdev;
+ int r;
+
+ ddata = devm_kzalloc(pdev-dev, sizeof(*ddata), GFP_KERNEL);
+ if (ddata == NULL)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, ddata);
+
+ if (dev_get_platdata(pdev-dev)) {
+ r = td028ttec1_panel_probe_pdata(pdev);
+ if (r)
+ return r;
+ } else {
+ return -ENODEV;
+ }
+
+ if (gpio_is_valid(ddata-cs_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-cs_gpio,
+ GPIOF_OUT_INIT_HIGH, lcd cs);
+ if (r)
+ goto err_gpio;
+ }
+
+ if (gpio_is_valid(ddata-scl_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-scl_gpio,
+ GPIOF_OUT_INIT_HIGH, lcd scl);
+ if (r)
+ goto err_gpio;
+ }
+
+ if (gpio_is_valid(ddata-dout_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-dout_gpio,
+ GPIOF_OUT_INIT_LOW, lcd dout);
+ if (r)
+ goto err_gpio;
+ }
+
+ if (gpio_is_valid(ddata-din_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-din_gpio,
+ GPIOF_IN, lcd din);
+ if (r)
+ goto err_gpio;
+ }
+
+ /* according to data sheet: wait 50ms (Tpos of LCM). However, 50ms
+ * seems unreliable with later LCM batches, increasing to 90ms */
+ mdelay(90);
What is this delay for? Usually sleeps/delays should be between two HW
actions. Here there's nothing below this line that would count as such
an action.
I guess that this delay is
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 10/10/13 14:52, Dr. H. Nikolaus Schaller wrote: Yes, I agree and I am willing to help if someone comes up with such a SoC. At the moment we have connected it to the OMAP3 only. True, but even without that kind of SoC, SPI bitbanging should be handled by an SPI driver, not by the drivers that use the bus. I.e. I want not to do a lot of work for others who we just guess about that they might exist... Yep. It's fine for me, it's not that much extra code in the panel driver. The panel hardware has three wires, so the panel driver (if it does handle the bus by bitbanging) can only refer to three gpios. Hm. The panle hardware has 3 but the SoC (OMAP3) the driver is running on has 4. Right, but this panel driver is a driver for the panel hardware. Not for the SoC, or the SoC+panel combination. So the panel driver must only use resources as seen by the panel hardware. So either the bus details should be hidden by using the normal spi framework, or if the driver does the bitbanging, use the gpios as specified in the panel spec. The panel driver cannot contain any board specific stuff. The bitbang driver shown below can handle either 3 or 4 gpios (except for initialization). It's not a bitbang driver, it's a panel driver. And anyway, if I understood right, your use of 4 gpios was just a hack to try to make it look like a normal 4-wire SPI bus. What you really have is 3 wires, 3 gpios. I don't see any reason to use 4 gpios, as two of them are the same. Hmm, how does it work anyway. Did I understand it right, the panel's 'DIN' pin is connected to two gpios on the SoC, and one of those gpios is set as output, and the other as input? So the SoC is always pulling that line up or down, and the panel is also pulling it up or down when it's sending data. I'm no HW guy but that sounds quite bad =). I've never written or studied a bitbanging driver, but shouldn't there be just one gpio used on the SoC for DIN, and it would be set to either output or input mode, depending on if we are reading or writing? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 10/10/2013 02:13 PM, Tomi Valkeinen wrote: On 10/10/13 14:52, Dr. H. Nikolaus Schaller wrote: Yes, I agree and I am willing to help if someone comes up with such a SoC. At the moment we have connected it to the OMAP3 only. True, but even without that kind of SoC, SPI bitbanging should be handled by an SPI driver, not by the drivers that use the bus. I.e. I want not to do a lot of work for others who we just guess about that they might exist... Yep. It's fine for me, it's not that much extra code in the panel driver. The panel hardware has three wires, so the panel driver (if it does handle the bus by bitbanging) can only refer to three gpios. Hm. The panle hardware has 3 but the SoC (OMAP3) the driver is running on has 4. Right, but this panel driver is a driver for the panel hardware. Not for the SoC, or the SoC+panel combination. So the panel driver must only use resources as seen by the panel hardware. So either the bus details should be hidden by using the normal spi framework, or if the driver does the bitbanging, use the gpios as specified in the panel spec. The panel driver cannot contain any board specific stuff. The bitbang driver shown below can handle either 3 or 4 gpios (except for initialization). It's not a bitbang driver, it's a panel driver. And anyway, if I understood right, your use of 4 gpios was just a hack to try to make it look like a normal 4-wire SPI bus. What you really have is 3 wires, 3 gpios. I don't see any reason to use 4 gpios, as two of them are the same. Hmm, how does it work anyway. Did I understand it right, the panel's 'DIN' pin is connected to two gpios on the SoC, and one of those gpios is set as output, and the other as input? So the SoC is always pulling that line up or down, and the panel is also pulling it up or down when it's sending data. I'm no HW guy but that sounds quite bad =). I've never written or studied a bitbanging driver, but shouldn't there be just one gpio used on the SoC for DIN, and it would be set to either output or input mode, depending on if we are reading or writing? Back in the OpenMoko days we used the panel in normal 4-wire SPI mode with the GPIO bitbang SPI master. The bitbang code in this driver also looks like normal 4 wire. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
On Thursday 10 October 2013 03:43 AM, Sricharan R wrote: From: R Sricharan r.sricha...@ti.com The realtime counter called master counter, produces the count used by the private timer peripherals in the MPU_CLUSTER. The CNTFRQ per cpu register is used to denote the frequency of the counter. Currently the frequency value is passed from the DT file, but this is not scalable when we have other non-DT guest OS. This register must be set to the right value by the secure rom code. Setting this register helps in propagating the right frequency value across OSes. More discussions and the reason for adding this in a non-DT way can be seen from below. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html So configuring this secure register for all the cpus here. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Nishanth Menon n...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Tony Lindgren t...@atomide.com Tested-by: Nishanth Menon n...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com --- [V5] Removed the use of extern variable in omap-smp.c as per suggestion from Santosh Shilimkar santosh.shilim...@ti.com Thanks for the updates Sricharan. Looks fine now. Tony, Can you apply this version if you are fine with it. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DRA: DTS: Remove clock-frequency field for cpu timers
On Thursday 10 October 2013 03:50 AM, Sricharan R wrote: The arm arch timers frequency are now programmed in the CNTFREQ per-cpu register by the timer code using the secure API [1]. So remove the redundant entry from the dts. [1] http://marc.info/?l=linux-omapm=138139106312786w=2 Cc: Benoit Cousson bcous...@baylibre.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
Hi Tony,
On 10/03/2013 08:42 AM, Tony Lindgren wrote:
The pin control registers can have interrupts for example
for device wake-up. These interrupts can be treated as a
chained interrupt controller as suggested earlier by
Linus Walleij linus.wall...@linaro.org.
This patch adds support for interrupts in a way that
should be pretty generic, and works for the omaps that
support wake-up interrupts. On omaps, there's an
interrupt enable and interrupt status bit for each pin.
The two pinctrl domains on omaps share a single interrupt
from the PRM chained interrupt handler. Support for
other similar hardware should be easy to add.
Note that this patch does not attempt to handle the
wake-up interrupts automatically unlike the earlier
patches. This patch allows the device drivers to do
a request_irq() on the wake-up pins as needed. I'll
try to do also a separate generic patch for handling
the wake-up events automatically.
Also note that as this patch makes the pinctrl-single
an irq controller, the current bindings need some
extra trickery to use interrupts from two different
interrupt controllers for the same driver. So it
might be worth waiting a little on the patches
enabling the wake-up interrupts from drivers as there
should be a generic way to handle it coming. And also
there's been discussion of interrupts-extended binding
for using interrupts from multiple interrupt controllers.
In any case, this patch should be ready to go allowing
handling the wake-up interrupts in a generic way, or
separately from the device drivers.
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Prakash Manjunathappa prakash...@ti.com
Cc: Roger Quadros rog...@ti.com
Cc: Haojian Zhuang haojian.zhu...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: Benoît Cousson bcous...@baylibre.com
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 +
drivers/pinctrl/pinctrl-single.c | 325
2 files changed, 336 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..7069a0b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -72,6 +72,13 @@ Optional properties:
/* pin base, nr pins gpio function */
pinctrl-single,gpio-range = range 0 3 0 range 3 9 1;
+- interrupt-controller : standard interrupt controller binding if using
+ interrupts for wake-up events for example. In this case pinctrl-single
+ is set up as a chained interrupt controller and the wake-up interrupts
+ can be requested by the drivers using request_irq().
+
+- #interrupt-cells : standard interrupt binding if using interrupts
+
This driver assumes that there is only one register for each pin (unless the
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
specified in the pinctrl-bindings.txt document in this directory.
@@ -121,6 +128,8 @@ pmx_core: pinmux@4a100040 {
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x;
};
@@ -131,6 +140,8 @@ pmx_wkup: pinmux@4a31e040 {
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x;
};
diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
index f88d3d1..b4ff055 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -15,10 +15,14 @@
#include linux/slab.h
#include linux/err.h
#include linux/list.h
+#include linux/interrupt.h
+
+#include linux/irqchip/chained_irq.h
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/of_irq.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
@@ -152,9 +156,15 @@ struct pcs_name {
/**
* struct pcs_soc_data - SoC specific settings
* @flags: initial SoC specific PCS_FEAT_xxx values
+ * @irq: optional interrupt for the controller
+ * @irq_enable_mask: optional SoC specific interrupt enable mask
+ * @irq_status_mask: optional SoC specific interrupt status mask
*/
struct pcs_soc_data {
unsigned flags;
+ int irq;
+ unsigned irq_enable_mask;
+ unsigned irq_status_mask;
};
/**
@@ -165,6 +175,7 @@ struct pcs_soc_data {
* @dev: device entry
* @pctl:pin controller device
* @flags: mask of PCS_FEAT_xxx values
+ * @lock:
Re: [PATCH V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
On 00:32-20131010, Joel Fernandes wrote: On 10/09/2013 06:24 PM, Nishanth Menon wrote: Call OMAP2+ generic lateinit hook from AM specific late init hook. This allows the generic late initializations such as cpufreq hooks to be active. Cc: Benoit Cousson bcous...@baylibre.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/board-generic.c |1 + arch/arm/mach-omap2/common.h|1 + arch/arm/mach-omap2/io.c|6 ++ 3 files changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 87162e1..b474498 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -180,6 +180,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree)) .init_irq = omap_intc_of_init, .handle_irq = omap3_intc_handle_irq, .init_machine = omap_generic_init, + .init_late = am33xx_init_late, Instead of adding a new a *_init_late function for every platform, perhaps better to just do: .init_late= omap2_common_pm_late_init; since that's the only function you're calling. Later if more functions are added, then it can be wrapped around. And what benefit would that give us? we break consistency of functions available in io.c, considering the work we have already done in out-of-tree patches on ti-forks, we *do know* that there is more incoming and has to be done anyways, I prefer having symmetric functions and a placeholder that folks can add on to. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
Hi Joel. On Thu, Oct 10, 2013 at 1:32 AM, Joel Fernandes jo...@ti.com wrote: On 10/09/2013 06:24 PM, Nishanth Menon wrote: Call OMAP2+ generic lateinit hook from AM specific late init hook. This allows the generic late initializations such as cpufreq hooks to be active. Cc: Benoit Cousson bcous...@baylibre.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/board-generic.c |1 + arch/arm/mach-omap2/common.h|1 + arch/arm/mach-omap2/io.c|6 ++ 3 files changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 87162e1..b474498 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -180,6 +180,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree)) .init_irq = omap_intc_of_init, .handle_irq = omap3_intc_handle_irq, .init_machine = omap_generic_init, + .init_late = am33xx_init_late, Instead of adding a new a *_init_late function for every platform, perhaps better to just do: .init_late = omap2_common_pm_late_init; since that's the only function you're calling. For now... As the PM support gets added there will be other function calls and that can and is at times soc specific. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Am 10.10.2013 um 14:26 schrieb Lars-Peter Clausen: On 10/10/2013 02:13 PM, Tomi Valkeinen wrote: On 10/10/13 14:52, Dr. H. Nikolaus Schaller wrote: Yes, I agree and I am willing to help if someone comes up with such a SoC. At the moment we have connected it to the OMAP3 only. True, but even without that kind of SoC, SPI bitbanging should be handled by an SPI driver, not by the drivers that use the bus. I.e. I want not to do a lot of work for others who we just guess about that they might exist... Yep. It's fine for me, it's not that much extra code in the panel driver. The panel hardware has three wires, so the panel driver (if it does handle the bus by bitbanging) can only refer to three gpios. Hm. The panle hardware has 3 but the SoC (OMAP3) the driver is running on has 4. Right, but this panel driver is a driver for the panel hardware. Not for the SoC, or the SoC+panel combination. So the panel driver must only use resources as seen by the panel hardware. So either the bus details should be hidden by using the normal spi framework, or if the driver does the bitbanging, use the gpios as specified in the panel spec. The panel driver cannot contain any board specific stuff. The bitbang driver shown below can handle either 3 or 4 gpios (except for initialization). It's not a bitbang driver, it's a panel driver. And anyway, if I understood right, your use of 4 gpios was just a hack to try to make it look like a normal 4-wire SPI bus. What you really have is 3 wires, 3 gpios. I don't see any reason to use 4 gpios, as two of them are the same. There is a protection resistor in the one defined as output so that protocol errors don't have two outputs work against each other. Hmm, how does it work anyway. Did I understand it right, the panel's 'DIN' pin is connected to two gpios on the SoC, and one of those gpios is set as output, and the other as input? Yes. So the SoC is always pulling that line up or down, and the panel is also pulling it up or down when it's sending data. I'm no HW guy but that sounds quite bad =). Yes, that is the strange thing with this protocol. It does a direction reversal after some time. I.e. the panel switches its input to output and the SoC has to be fast enough to do the same. Therefore, we have one output GPIO (protected by a resistor) and a separate input GPIO. Sometimes interfacing hardware is indeed strange. I've never written or studied a bitbanging driver, but shouldn't there be just one gpio used on the SoC for DIN, and it would be set to either output or input mode, depending on if we are reading or writing? Back in the OpenMoko days we used the panel in normal 4-wire SPI mode with the GPIO bitbang SPI master. The bitbang code in this driver also looks like normal 4 wire. Thanks for this hint! Maybe using a standard 4-wire SPI simply works if we only write data and make sure the panel is not sending anything... I still hesitate to break working code because it needs quite some time to debug and we don't even know if it ever works, i.e. sends us to swampy ground... BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Thu, Oct 10, 2013 at 3:24 PM, Roger Quadros rog...@ti.com wrote: I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq. This is where we should be able to change WAKEUP_EN bit of the pad to enable/disable system wakeup for that pad and also call _reconfigure_io_chain(). As an innocent bystander who has no clue what the _reconfigure_io_chain() is about can you tell me what this is all about? Is this another one of the OMAP forked paths where you must call back into the machine with a special callback from each and every driver? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/27] mmc: omap_hsmmc: Move away from using deprecated APIs
On Thursday 26 September 2013 08:24 PM, Ulf Hansson wrote:
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs. Additional cleanup done for keeping track
suspended state.
Cc: Balaji T K balaj...@ti.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 37 +++--
1 file changed, 3 insertions(+), 34 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6ac63df..eb6fb28 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -170,7 +170,6 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char bus_mode;
unsigned char power_mode;
- int suspended;
int irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
@@ -1178,9 +1177,6 @@ static irqreturn_t omap_hsmmc_detect(int irq, void
*dev_id)
struct omap_mmc_slot_data *slot = mmc_slot(host);
int carddetect;
- if (host-suspended)
- return IRQ_HANDLED;
-
sysfs_notify(host-mmc-class_dev.kobj, NULL, cover_switch);
if (slot-card_detect)
@@ -1643,11 +1639,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
seq_printf(s, mmc%d:\n ctx_loss:\t%d:%d\n\nregs:\n,
mmc-index, host-context_loss, context_loss);
- if (host-suspended) {
- seq_printf(s, host suspended, can't read registers\n);
- return 0;
- }
-
pm_runtime_get_sync(host-dev);
seq_printf(s, CON:\t\t0x%08x\n,
@@ -2119,23 +2110,12 @@ static void omap_hsmmc_complete(struct device *dev)
static int omap_hsmmc_suspend(struct device *dev)
{
- int ret = 0;
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
if (!host)
return 0;
- if (host host-suspended)
- return 0;
-
pm_runtime_get_sync(host-dev);
- host-suspended = 1;
- ret = mmc_suspend_host(host-mmc);
-
- if (ret) {
- host-suspended = 0;
- goto err;
- }
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER)) {
omap_hsmmc_disable_irq(host);
@@ -2145,23 +2125,19 @@ static int omap_hsmmc_suspend(struct device *dev)
if (host-dbclk)
clk_disable_unprepare(host-dbclk);
-err:
+
pm_runtime_put_sync(host-dev);
- return ret;
+ return 0;
}
/* Routine to resume the MMC device */
static int omap_hsmmc_resume(struct device *dev)
{
- int ret = 0;
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
if (!host)
return 0;
- if (host !host-suspended)
- return 0;
-
pm_runtime_get_sync(host-dev);
if (host-dbclk)
@@ -2172,16 +2148,9 @@ static int omap_hsmmc_resume(struct device *dev)
omap_hsmmc_protect_card(host);
- /* Notify the core to resume the host */
- ret = mmc_resume_host(host-mmc);
- if (ret == 0)
- host-suspended = 0;
-
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
-
- return ret;
-
+ return 0;
}
#else
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv3 1/7] ARM: OMAP2+: hwmod-data: Add SSI information
On Wed, Oct 09, 2013 at 05:43:13AM +, Paul Walmsley wrote: On Sun, 6 Oct 2013, Sebastian Reichel wrote: This patch adds Synchronous Serial Interface (SSI) hwmod support for OMAP34xx SoCs. Signed-off-by: Sebastian Reichel s...@debian.org Thanks, queued this one for v3.13. You can drop it from any future reposts of this series. Thanks. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On 16:19-20131010, Kishon Vijay Abraham I wrote:
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
- regulator-always-on;
- regulator-boot-on;
};
ldo1_reg: ldo1 {
--
Always good to get rid of regulator-always-on. Thanks for it.
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
Hence Nak.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On 10/10/2013 05:04 PM, Linus Walleij wrote: On Thu, Oct 10, 2013 at 3:24 PM, Roger Quadros rog...@ti.com wrote: I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq. This is where we should be able to change WAKEUP_EN bit of the pad to enable/disable system wakeup for that pad and also call _reconfigure_io_chain(). As an innocent bystander who has no clue what the _reconfigure_io_chain() is about can you tell me what this is all about? The OMAP SoC has a mechanism to monitor and wakeup from a low power state by creating an IO ring of all the pads. But there is one bit in one of the control registers that needs to be toggled each time the pad configuration is changed to re-arm the IO ring. This is exactly what _reconfigure_io_chain() does. Is this another one of the OMAP forked paths where you must call back into the machine with a special callback from each and every driver? _reconfigure_io_chain() is not available for public use and is not called by any driver yet. However, it somehow needs to be called from this pinctrl-single driver each time the wakeup configuration for any pad is changed. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
On 10/10/2013 08:32 AM, Nishanth Menon wrote: On 00:32-20131010, Joel Fernandes wrote: On 10/09/2013 06:24 PM, Nishanth Menon wrote: Call OMAP2+ generic lateinit hook from AM specific late init hook. This allows the generic late initializations such as cpufreq hooks to be active. Cc: Benoit Cousson bcous...@baylibre.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/board-generic.c |1 + arch/arm/mach-omap2/common.h|1 + arch/arm/mach-omap2/io.c|6 ++ 3 files changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 87162e1..b474498 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -180,6 +180,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree)) .init_irq = omap_intc_of_init, .handle_irq = omap3_intc_handle_irq, .init_machine = omap_generic_init, + .init_late = am33xx_init_late, Instead of adding a new a *_init_late function for every platform, perhaps better to just do: .init_late = omap2_common_pm_late_init; since that's the only function you're calling. Later if more functions are added, then it can be wrapped around. And what benefit would that give us? we break consistency of functions available in io.c, considering the work we have already done in out-of-tree patches on ti-forks, we *do know* that there is more incoming and has to be done anyways, I prefer having symmetric functions and a placeholder that folks can add on to. Ok, sure if you think such placeholders are right way and there's more code later to be added to init_late callbacks. Adding 6 lines of identical code for every platform seems redundant, I'd just define an omap_common_late_init for all platforms for now, and then fork off for the future differences. That way we save on LOC and readability in the header as well. Your call. thanks, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
On 10/10/2013 10:20 AM, Joel Fernandes wrote: On 10/10/2013 08:32 AM, Nishanth Menon wrote: On 00:32-20131010, Joel Fernandes wrote: On 10/09/2013 06:24 PM, Nishanth Menon wrote: Call OMAP2+ generic lateinit hook from AM specific late init hook. This allows the generic late initializations such as cpufreq hooks to be active. Cc: Benoit Cousson bcous...@baylibre.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/board-generic.c |1 + arch/arm/mach-omap2/common.h|1 + arch/arm/mach-omap2/io.c|6 ++ 3 files changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 87162e1..b474498 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -180,6 +180,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree)) .init_irq = omap_intc_of_init, .handle_irq = omap3_intc_handle_irq, .init_machine = omap_generic_init, + .init_late = am33xx_init_late, Instead of adding a new a *_init_late function for every platform, perhaps better to just do: .init_late = omap2_common_pm_late_init; since that's the only function you're calling. Later if more functions are added, then it can be wrapped around. And what benefit would that give us? we break consistency of functions available in io.c, considering the work we have already done in out-of-tree patches on ti-forks, we *do know* that there is more incoming and has to be done anyways, I prefer having symmetric functions and a placeholder that folks can add on to. Ok, sure if you think such placeholders are right way and there's more code later to be added to init_late callbacks. Adding 6 lines of identical code for every platform seems redundant, I'd just define an omap_common_late_init for all platforms for now, and then fork off for the future differences. That way we save on LOC and readability in the header as well. Your call. I see a function of that name already exists. I guess you can leave your patch as is then and not have to do this. regards, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Thu, Oct 10, 2013 at 4:35 PM, Roger Quadros rog...@ti.com wrote: On 10/10/2013 05:04 PM, Linus Walleij wrote: As an innocent bystander who has no clue what the _reconfigure_io_chain() is about can you tell me what this is all about? The OMAP SoC has a mechanism to monitor and wakeup from a low power state by creating an IO ring of all the pads. But there is one bit in one of the control registers that needs to be toggled each time the pad configuration is changed to re-arm the IO ring. This is exactly what _reconfigure_io_chain() does. OK I get it, I checked the function in the machone. Is this another one of the OMAP forked paths where you must call back into the machine with a special callback from each and every driver? _reconfigure_io_chain() is not available for public use and is not called by any driver yet. However, it somehow needs to be called from this pinctrl-single driver each time the wakeup configuration for any pad is changed. Actually this is one of those things where the complexity of the platform seems to start to leak into the nice picture of one-register-per-pin. If this was *not* pinctrl-single but pinctrl-omap.c, it would make sense to move this _reconfigure_io code and the PRM registers it is touching down into the pinctrl driver, because it seems like absolutely no-one else is using it. Both the other occurences seem to be in omap_hwmod.c, and seems to be related to pin muxing, which is now supposed to be handled by the pin control driver, right? I think the real solution to this would be something like: - Add the compatible strings pinctrl-single-omap3 and pinctrl-single-omap4 to drivers/pinctrl/pinctrl-single.c, - Pass an additional ampersand resource for the prm thing to the single driver in the OMAP platform. - Move this _reconfigure_io code out of the mach-omap2 machines and hwmod and down into the pinctrl-single driver, it can be #ifdef ARCH_OMAP with stubs or whatever, the important thing is that it lives with the pinctrl driver. This does the right thing and let the pinctrl driver handle the io ring, instead of artificially trying to hide that in the mach-omap2 directory which is only creating a mess of things. I know this is sort of breaking the promise of pinctrl-single.c only handling single registers but we just need to accept the fact that if this idea is not perfect, trying to hide the facts of life isn't any good either. What do you say about this Tony? Good/bad/Linus is a moron? ;-) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-beagle: Adapt USB OTG to generic PHY framework
On Mon, Oct 07, 2013 at 01:46:50PM +0300, Roger Quadros wrote: The generic PHY framewrok expects different properties than the old USB PHY framework. Supply those properties. Fixes USB OTG port on beagle after the Generic PHY framework was merged in greg/usb-next. [1] [1] - https://lkml.org/lkml/2013/9/27/581 Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] ARM: dts: omap3: Adapt USB OTG to generic PHY framework
On Mon, Oct 07, 2013 at 04:28:13PM +0300, Roger Quadros wrote: The generic PHY framewrok expects different properties than the old USB PHY framework. Supply those properties. Fixes USB OTG port on GAT04 and N900 after the Generic PHY framework was merged in greg/usb-next. [1] [1] - https://lkml.org/lkml/2013/9/27/581 Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
On Wed, Oct 9, 2013 at 5:10 PM, Tony Lindgren t...@atomide.com wrote: I was thinking I'll set up an immutable branch for the three pinctrl patches against -rc4 then both you and I can merge them in as needed. Does that work for you? Hm it's fair enough to have them in your tree if they do not collide ... especially if you want to do some of my suggested follow-up moving the ioring handling down into pinctrl-single on top of that. I can also do a test merge with pinctrl/for-next also to make sure there are no conflicts. Sure, as long as that works you should be safe. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
On 10/10/2013 10:45 AM, Nishanth Menon wrote: On Thu, Oct 10, 2013 at 10:23 AM, Joel Fernandes jo...@ti.com wrote: I see a function of that name already exists. I guess you can leave your patch as is then and not have to do this. Can I consider that as an Acked-by :) ? Yes, sure, for this particular patch: Acked-by: Joel Fernandes jo...@ti.com thanks, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
* Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. Now on omap4, I've noticed the wake up interrupts are on all the time based on tests with the serial driver. I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq. This is where we should be able to change WAKEUP_EN bit of the pad to enable/disable system wakeup for that pad and also call _reconfigure_io_chain(). Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM the wake-events should be always enabled by default as pointed out by Alan Stern a while back. This would mean that we don't really need to set WAKEUP_EN for the pads in the DTS file. Well for runtime PM, we should also do the automatic handling if configured. But how to do that best is still open.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
On Thu, Oct 10, 2013 at 10:23 AM, Joel Fernandes jo...@ti.com wrote: I see a function of that name already exists. I guess you can leave your patch as is then and not have to do this. Can I consider that as an Acked-by :) ? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. If the rearm() function is calling this _reconfigure_io_chain my comments on the fact that this is something that should be handled by the pin control driver still apply I think Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
* Linus Walleij linus.wall...@linaro.org [131010 08:40]: On Thu, Oct 10, 2013 at 4:35 PM, Roger Quadros rog...@ti.com wrote: On 10/10/2013 05:04 PM, Linus Walleij wrote: As an innocent bystander who has no clue what the _reconfigure_io_chain() is about can you tell me what this is all about? The OMAP SoC has a mechanism to monitor and wakeup from a low power state by creating an IO ring of all the pads. But there is one bit in one of the control registers that needs to be toggled each time the pad configuration is changed to re-arm the IO ring. This is exactly what _reconfigure_io_chain() does. OK I get it, I checked the function in the machone. Is this another one of the OMAP forked paths where you must call back into the machine with a special callback from each and every driver? _reconfigure_io_chain() is not available for public use and is not called by any driver yet. However, it somehow needs to be called from this pinctrl-single driver each time the wakeup configuration for any pad is changed. Actually this is one of those things where the complexity of the platform seems to start to leak into the nice picture of one-register-per-pin. If this was *not* pinctrl-single but pinctrl-omap.c, it would make sense to move this _reconfigure_io code and the PRM registers it is touching down into the pinctrl driver, because it seems like absolutely no-one else is using it. Both the other occurences seem to be in omap_hwmod.c, and seems to be related to pin muxing, which is now supposed to be handled by the pin control driver, right? Right, that's for the legacy muxing code. With the legacy code we know the device using the pins and it's interrupt in the hwmod code, so transparent handling of the runtime PM wake-up events is easy. But that is at the cost of huge data tables for every SoC variant, which is what we're trying to avoid here. I think the real solution to this would be something like: - Add the compatible strings pinctrl-single-omap3 and pinctrl-single-omap4 to drivers/pinctrl/pinctrl-single.c, - Pass an additional ampersand resource for the prm thing to the single driver in the OMAP platform. - Move this _reconfigure_io code out of the mach-omap2 machines and hwmod and down into the pinctrl-single driver, it can be #ifdef ARCH_OMAP with stubs or whatever, the important thing is that it lives with the pinctrl driver. This does the right thing and let the pinctrl driver handle the io ring, instead of artificially trying to hide that in the mach-omap2 directory which is only creating a mess of things. I know this is sort of breaking the promise of pinctrl-single.c only handling single registers but we just need to accept the fact that if this idea is not perfect, trying to hide the facts of life isn't any good either. What do you say about this Tony? Good/bad/Linus is a moron? ;-) Yes once we have made omap3 to be DT only, a lot of the legacy mux stuff will clear out. And at that point we can start moving things into PRCM drivers to handle the single shared wake-up interrupt that PRM and also pinctrl-single is using. However, the reconfigure_io_chain() registers are in the PRM module, so it still should be the PRM driver managing it rather than pinctrl-single that's in the SCM module as they can at least in theory live a separate power state lifes. But in any case, things will get simpler once the dependencies to the legacy code are cut. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
* Linus Walleij linus.wall...@linaro.org [131010 09:19]: On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. If the rearm() function is calling this _reconfigure_io_chain my comments on the fact that this is something that should be handled by the pin control driver still apply I think Yes, except that the reconfigure_io_chain registers are in the PRM module, not in the SCM module where the pinctrl registers are.. And that shared PRM interrupt is used mostly for the internal domain wake-ups, so we should keep that in the PRM driver. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
* Tony Lindgren t...@atomide.com [131010 09:09]: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. Now on omap4, I've noticed the wake up interrupts are on all the time based on tests with the serial driver. Oh, and if you're runtime suspending EHCI only, and if the EHCI module has wake-up registers, it should be able to wake EHCI from retention on it's own without a need for the io chain at all. At least the serial driver does that if it's internal wake-up registers are configured right. But for off-idle, the serial driver needs the io chain wake-up events. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/11] ARM: OMAP2+: AM43x PRCM basic support
* Rajendra Nayak rna...@ti.com [131009 22:33]: On Tuesday 08 October 2013 11:45 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [131003 23:50]: On Tuesday 01 October 2013 12:34 PM, Afzal Mohammed wrote: Hi Paul, Benoit, Tony, This series adds PRCM support (except clock tree) for AM43x SoC's. Please consider this for inclusion in the coming merge window. Patch 02/11 ARM: OMAP2+: hwmod: AM335x/AM43x: move common data may not reach mailing lists due to bigger size, this series is also present @git://gitorious.org/x0148406-public/linux-kernel.git tags/am43x-prcm-v5 Compared to v4, only change is in fixing the powerdomain data. Major changes compared to rfc v3: 1. All register offsets properly taken care for AM43x (with rfc v3, a couple of issues was detected while testing on pre-silicon) 2. There were two patches for common hwmod data movement (one for interconnect and other for ip block data), both were combined to have a cleaner series that is bisectable. 3. Cleaner seperation of common data Major changes compared to v2 (v3 was only an rfc for current approach): 1. omap_hwmod_33xx_43xx_interconnect_data.c has the common interconnect ocp's structs shared between AM335x and AM43x 2. omap_hwmod_33xx_43xx_ipblock_data.c has the common hwmod structs shared between AM335x and AM43x This split and reuse looks much better and readable now. For the complete series, Acked-by: Rajendra Nayak rna...@ti.com Looks good to me too. I'm assuming that Paul will queue this. And let's everybody make note that this will be the _last_ set of hwmod data we'll _ever_ merge as this all should be replaced with device tree + bus driver based approach for future SoCs. But let's get the common clock framework conversion done first, so this can wait until after that. Tony, I hope you meant the 'hwmod replaced with device tree + bus driver based approach' is what can wait until after the common clock framework DT conversion and not the $subject series itself :) Right, hwmod replaced with device tree + bus driver based approach is what I mean can wait until the clock conversion is done :) Not this patch series. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap4-panda-es: Do not reset gpio1
Do not reset GPIO1 at boot-up because GPIO 7 in GPIO1 block is used on
OMAP4460 PandaBoard-ES to select voltage register in TPS62361 which
supplies VDD_MPU.
Without this, OMAP4460 PandaBoard-ES boards fail to boot-up because
MPU voltage switches over to VSET0 voltage value (boot voltage) which
is not sufficient to operate the device at OPP100.
Signed-off-by: Nishanth Menon n...@ti.com
---
As explained here: http://marc.info/?l=u-bootm=133066647800872w=2
GPIO1 reset causes PandaBoard-ES to stop functioning.
This depends on Patch series from Rajendra:
http://marc.info/?l=linux-docm=138131355520116w=2
Applies on Benoit's for_13/dts branch:
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
Tested on PandaBoard-ES without the u-boot uenv hack
arch/arm/boot/dts/omap4-panda-es.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..816d1c9 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -62,3 +62,7 @@
gpios = gpio1 8 GPIO_ACTIVE_HIGH;
};
};
+
+gpio1 {
+ti,no-reset-on-init;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap4-panda-es: Do not reset gpio1
* Nishanth Menon n...@ti.com [131010 09:53]:
Do not reset GPIO1 at boot-up because GPIO 7 in GPIO1 block is used on
OMAP4460 PandaBoard-ES to select voltage register in TPS62361 which
supplies VDD_MPU.
Without this, OMAP4460 PandaBoard-ES boards fail to boot-up because
MPU voltage switches over to VSET0 voltage value (boot voltage) which
is not sufficient to operate the device at OPP100.
Is this needs as a fix for the -rc series?
Tony
Signed-off-by: Nishanth Menon n...@ti.com
---
As explained here: http://marc.info/?l=u-bootm=133066647800872w=2
GPIO1 reset causes PandaBoard-ES to stop functioning.
This depends on Patch series from Rajendra:
http://marc.info/?l=linux-docm=138131355520116w=2
Applies on Benoit's for_13/dts branch:
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
Tested on PandaBoard-ES without the u-boot uenv hack
arch/arm/boot/dts/omap4-panda-es.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..816d1c9 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -62,3 +62,7 @@
gpios = gpio1 8 GPIO_ACTIVE_HIGH;
};
};
+
+gpio1 {
+ ti,no-reset-on-init;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT
On Tue, Oct 08, 2013 at 01:46:41AM +0100, Mark Brown wrote: On Mon, Oct 07, 2013 at 10:47:18PM +0100, Mark Rutland wrote: On Thu, Sep 26, 2013 at 08:18:28PM +0100, Jyri Sarha wrote: - interrupts : Interrupt number for McASP The device also seems to be able to generate multiple interrupts -- which interrupt does this actually cover? The driver doesn't seem to use it (by a grep of irq|interrupt). Have I missed something? No, they're not actually of much practical use to us at the minute but it was generally felt better to include the information and not use it so that if someone does come up with a use for them then the trees for deployed systems already have the information. Sure, but if this device can generate multiple interrupts, we should make it possible to describe all of them, unambiguously. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
* Santosh Shilimkar santosh.shilim...@ti.com [131010 06:20]: On Thursday 10 October 2013 03:43 AM, Sricharan R wrote: From: R Sricharan r.sricha...@ti.com The realtime counter called master counter, produces the count used by the private timer peripherals in the MPU_CLUSTER. The CNTFRQ per cpu register is used to denote the frequency of the counter. Currently the frequency value is passed from the DT file, but this is not scalable when we have other non-DT guest OS. This register must be set to the right value by the secure rom code. Setting this register helps in propagating the right frequency value across OSes. More discussions and the reason for adding this in a non-DT way can be seen from below. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html So configuring this secure register for all the cpus here. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Nishanth Menon n...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Tony Lindgren t...@atomide.com Tested-by: Nishanth Menon n...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com --- [V5] Removed the use of extern variable in omap-smp.c as per suggestion from Santosh Shilimkar santosh.shilim...@ti.com Thanks for the updates Sricharan. Looks fine now. Tony, Can you apply this version if you are fine with it. Yes thanks looks good to me now. Applying into omap-for-v3.13/soc. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv3 0/7] OMAP SSI driver
Hi, On Tue, Oct 08, 2013 at 10:28:15AM -0700, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131006 13:36]: Here is the third round of the OMAP SSI driver patches. Thanks for updating these, they look good to me now: Acked-by: Tony Lindgren t...@atomide.com Ok. I guess it's time to check how this gets included in the kernel. The first patch has already been queued and the last patch could probably go through Benoît once the DT people have reviewed the updated patches. The other ones would normally go through the hsi tree, but that one was maintained by Carlos Chinea and is now more or less orphaned. My suggestion is: 1. I create another patch, which adds entries for hsi subsystem and ssi driver to MAINTAINERS. It would be nice to have some co-maintainers for the subsystem. Linus Walleij maybe? I think you created the launchpad blueprint [1]? Especially because I have no documentation/specification for HSI, which brings me to my next slightly off topic request. I would like to have access to SSI documentation and HSI specification. Can the guys from Texas Instruments please give me some pointers how I can get access to the NDA'd documentation? I couldn't find any hints on ti.com. 2. I create a patch adding Carlos Chinea to CREDITS 3. I create a git repository and put all of the patches in there, so that they can be pulled into linux-next. 4. I add a gpg/pgp signed tag with the key used to signed this mail. Any issues with this or any other suggestions how to proceed? And if following this - should I request an account on kernel.org to host the repository there, or should I just upload it at a random place? [0] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees [1] https://blueprints.launchpad.net/linux-linaro/+spec/hsi-subsystem-maint -- Sebastian signature.asc Description: Digital signature
Re: [RESEND PATCH v3 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT
On 10/10/2013 07:59 PM, Mark Rutland wrote: No, they're not actually of much practical use to us at the minute but it was generally felt better to include the information and not use it so that if someone does come up with a use for them then the trees for deployed systems already have the information. Sure, but if this device can generate multiple interrupts, we should make it possible to describe all of them, unambiguously. This is why Jyri added them to the DT. They are not used by the Linux driver, but the HW have interrupt lines (two of them: TX and RX). -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv3 0/7] OMAP SSI driver
* Sebastian Reichel s...@debian.org [131010 10:30]: Hi, On Tue, Oct 08, 2013 at 10:28:15AM -0700, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131006 13:36]: Here is the third round of the OMAP SSI driver patches. Thanks for updating these, they look good to me now: Acked-by: Tony Lindgren t...@atomide.com Ok. I guess it's time to check how this gets included in the kernel. The first patch has already been queued and the last patch could probably go through Benoît once the DT people have reviewed the updated patches. The other ones would normally go through the hsi tree, but that one was maintained by Carlos Chinea and is now more or less orphaned. Yes, I suggest you post the .dts changes completely seprately so driver maintainers don't accidentally pick those up. My suggestion is: 1. I create another patch, which adds entries for hsi subsystem and ssi driver to MAINTAINERS. It would be nice to have some co-maintainers for the subsystem. Linus Walleij maybe? I think you created the launchpad blueprint [1]? Especially because I have no documentation/specification for HSI, which brings me to my next slightly off topic request. I would like to have access to SSI documentation and HSI specification. Can the guys from Texas Instruments please give me some pointers how I can get access to the NDA'd documentation? I couldn't find any hints on ti.com. 2. I create a patch adding Carlos Chinea to CREDITS 3. I create a git repository and put all of the patches in there, so that they can be pulled into linux-next. 4. I add a gpg/pgp signed tag with the key used to signed this mail. Any issues with this or any other suggestions how to proceed? And if following this - should I request an account on kernel.org to host the repository there, or should I just upload it at a random place? That all sounds good to me. It is a *good thing* to have a maintainer for a driver subsystem, and if you're willing to pick it up, that's the way to go. Regards, Tony [0] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees [1] https://blueprints.launchpad.net/linux-linaro/+spec/hsi-subsystem-maint -- Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: manual merge of the omap_dss2 tree
Today's linux-next merge of the omap_dss2 tree got conflicts in drivers/video/omap2/dss/hdmi4_core.[ch] caused by ef26958a (omapdss: HDMI: Rename hdmi driver files to nicer names) interacting with a range of commits from Ricardo Neri in the fbdev tree and possibly some other stuff. git is unfortunately not giving me a useful diff right now :/ signature.asc Description: Digital signature
Re: [RFCv3 0/7] OMAP SSI driver
Hi, On Thu, Oct 10, 2013 at 07:21:30PM +0200, Sebastian Reichel wrote: Any issues with this or any other suggestions how to proceed? Maybe you could provide some brief instructions/description of how this was tested? Thanks, A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 10/10/2013 03:42 PM, Dr. H. Nikolaus Schaller wrote: Am 10.10.2013 um 14:26 schrieb Lars-Peter Clausen: On 10/10/2013 02:13 PM, Tomi Valkeinen wrote: On 10/10/13 14:52, Dr. H. Nikolaus Schaller wrote: Yes, I agree and I am willing to help if someone comes up with such a SoC. At the moment we have connected it to the OMAP3 only. True, but even without that kind of SoC, SPI bitbanging should be handled by an SPI driver, not by the drivers that use the bus. I.e. I want not to do a lot of work for others who we just guess about that they might exist... Yep. It's fine for me, it's not that much extra code in the panel driver. The panel hardware has three wires, so the panel driver (if it does handle the bus by bitbanging) can only refer to three gpios. Hm. The panle hardware has 3 but the SoC (OMAP3) the driver is running on has 4. Right, but this panel driver is a driver for the panel hardware. Not for the SoC, or the SoC+panel combination. So the panel driver must only use resources as seen by the panel hardware. So either the bus details should be hidden by using the normal spi framework, or if the driver does the bitbanging, use the gpios as specified in the panel spec. The panel driver cannot contain any board specific stuff. The bitbang driver shown below can handle either 3 or 4 gpios (except for initialization). It's not a bitbang driver, it's a panel driver. And anyway, if I understood right, your use of 4 gpios was just a hack to try to make it look like a normal 4-wire SPI bus. What you really have is 3 wires, 3 gpios. I don't see any reason to use 4 gpios, as two of them are the same. There is a protection resistor in the one defined as output so that protocol errors don't have two outputs work against each other. Hmm, how does it work anyway. Did I understand it right, the panel's 'DIN' pin is connected to two gpios on the SoC, and one of those gpios is set as output, and the other as input? Yes. So the SoC is always pulling that line up or down, and the panel is also pulling it up or down when it's sending data. I'm no HW guy but that sounds quite bad =). Yes, that is the strange thing with this protocol. It does a direction reversal after some time. I.e. the panel switches its input to output and the SoC has to be fast enough to do the same. Therefore, we have one output GPIO (protected by a resistor) and a separate input GPIO. Sometimes interfacing hardware is indeed strange. I've never written or studied a bitbanging driver, but shouldn't there be just one gpio used on the SoC for DIN, and it would be set to either output or input mode, depending on if we are reading or writing? Back in the OpenMoko days we used the panel in normal 4-wire SPI mode with the GPIO bitbang SPI master. The bitbang code in this driver also looks like normal 4 wire. Thanks for this hint! Maybe using a standard 4-wire SPI simply works if we only write data and make sure the panel is not sending anything... According to the datasheet the the panel as a dedicated dout pin. Maybe you did not connect it in your design, which means you won't be able to read any data from the panel at all. Also your custom bitbang code looks a bit strange: gpio_set_value(data-dout_gpio, 1); if (gpio_get_value(data-din_gpio) == 0) return 1; You set the state on the dout pin and then read the din pin, if both do not match you abort with an error. This suggest that, for whatever reason, you feed the dout pin back into the din pin in your design. Btw. this is also the only place where din is used in your driver. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap4-panda-es: Do not reset gpio1
On 10/10/2013 11:47 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [131010 09:53]: Do not reset GPIO1 at boot-up because GPIO 7 in GPIO1 block is used on OMAP4460 PandaBoard-ES to select voltage register in TPS62361 which supplies VDD_MPU. Without this, OMAP4460 PandaBoard-ES boards fail to boot-up because MPU voltage switches over to VSET0 voltage value (boot voltage) which is not sufficient to operate the device at OPP100. Is this needs as a fix for the -rc series? Nope, this is not a regression recently introduced, has been in since day one of Panda-ES support. Further, we still have decision pending on the dependent series from Rajendra[1] - will be good to see it go in along with AM335x-EVM. [1] http://marc.info/?t=13813136835r=1w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: AM4372: Add more nodes
Populate nodes for l2-cache-controller, EDMA, mailbox,
mmc, sham.
And also updating dt properties for epwmss, aes, des.
Few nodes are taken from a different tree that are added by
Suman Anna s-a...@ti.com (Mailbox)
Balaji T K balaj...@ti.com (MMC)
Mugunthan V N mugunthan...@ti.com (Pinmux, Ethernet)
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 210 -
1 file changed, 209 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index a403172..c328d5c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -19,6 +19,8 @@
aliases {
serial0 = uart0;
+ ethernet0 = cpsw_emac0;
+ ethernet1 = cpsw_emac1;
};
cpus {
@@ -39,11 +41,42 @@
0x48240100 0x0100;
};
+ l2-cache-controller@48242000 {
+ compatible = arm,pl310-cache;
+ reg = 0x48242000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ };
+
+ am43xx_pinmux: pinmux@44e10800 {
+ compatible = pinctrl-single;
+ reg = 0x44e10800 0x31c;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x;
+ };
+
ocp {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges;
+ ti,hwmods = l3_main;
+
+ edma: edma@4900 {
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ reg = 0x4900 0x1,
+ 0x44e10f90 0x10;
+ interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ };
uart0: serial@44e09000 {
compatible = ti,am4372-uart,ti,omap2-uart;
@@ -92,6 +125,18 @@
status = disabled;
};
+ mailbox: mailbox@480C8000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x480C8000 0x200;
+ interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 8;
+ ti,mbox-names = wkup_m3;
+ ti,mbox-data = 0 0 0 0;
+ status = disabled;
+ };
+
timer1: timer@44e31000 {
compatible =
ti,am4372-timer-1ms,ti,am335x-timer-1ms;
reg = 0x44e31000 0x400;
@@ -203,7 +248,6 @@
reg = 0x44e35000 0x1000;
interrupts = GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = wd_timer2;
- status = disabled;
};
gpio0: gpio@44e07000 {
@@ -318,6 +362,40 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x4806 0x1000;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ interrupts = GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x481d8000 0x1000;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x4781 0x1000;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ interrupts = GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
spi1: spi@481a {
compatible =
[PATCH 0/2] ARM: dts: AM4372: Add more nodes
This patch series add nodes for l2-cache-controller, EDMA, mailbox, mmc, sham, and updates the properties for cpsw, i2c0, matrix-keypad. These patches are applied on top of Benoit's for_3.13/dts branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.13/dts Testing: Tested EDMA, mmc, sham, aes, des, i2c0, cpsw, matric-keypad on AM4372 EPOS EVM with the addition of following two series: - Tero's V8 of OMAP DT clock conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg96769.html - Afzal's V5 of AM43x PRCM basic support http://www.mail-archive.com/linux-omap@vger.kernel.org/msg96275.html Lokesh Vutla (1): ARM: dts: AM4372: Add more nodes Mugunthan V N (1): ARM: dts: AM4372: Update Support for EPOS EVM arch/arm/boot/dts/am4372.dtsi| 210 +- arch/arm/boot/dts/am43x-epos-evm.dts | 168 +++ include/dt-bindings/pinctrl/am43xx.h | 31 + 3 files changed, 408 insertions(+), 1 deletion(-) create mode 100644 include/dt-bindings/pinctrl/am43xx.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: AM4372: Update Support for EPOS EVM
From: Mugunthan V N mugunthan...@ti.com
- Adding pinmux for cpsw, i2c0.
- Enabling the modules that are present in AM4372 EPOS EVM
These modules are tested on AM4372 EPOS EVM.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 168 ++
include/dt-bindings/pinctrl/am43xx.h | 31 +++
2 files changed, 199 insertions(+)
create mode 100644 include/dt-bindings/pinctrl/am43xx.h
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 74174d4..fbf9c4c 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -11,8 +11,176 @@
/dts-v1/;
#include am4372.dtsi
+#include dt-bindings/pinctrl/am43xx.h
+#include dt-bindings/gpio/gpio.h
/ {
model = TI AM43x EPOS EVM;
compatible = ti,am43x-epos-evm,ti,am4372,ti,am43;
+
+ vmmcsd_fixed: fixedregulator-sd {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ enable-active-high;
+ };
+
+ am43xx_pinmux: pinmux@44e10800 {
+ cpsw_default: cpsw_default {
+ pinctrl-single,pins =
+ /* Slave 1 */
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_crs.rmii1_crs */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxerr.rmii1_rxerr */
+ 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
mii1_txen.rmii1_txen */
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxdv.rmii1_rxdv */
+ 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
mii1_txd1.rmii1_txd1 */
+ 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
mii1_txd0.rmii1_txd0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd1.rmii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd0.rmii1_rxd0 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
rmii1_refclk.rmii1_refclk */
+ ;
+ };
+
+ cpsw_sleep: cpsw_sleep {
+ pinctrl-single,pins =
+ /* Slave 1 reset value */
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
+ davinci_mdio_default: davinci_mdio_default {
+ pinctrl-single,pins =
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0)/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ ;
+ };
+
+ davinci_mdio_sleep: davinci_mdio_sleep {
+ pinctrl-single,pins =
+ /* MDIO reset value */
+ 0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0)/* i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0)/* i2c0_scl.i2c0_scl */
+ ;
+ };
+ };
+
+ matrix_keypad: matrix_keypad@0 {
+ compatible = gpio-matrix-keypad;
+ debounce-delay-ms = 5;
+ col-scan-delay-us = 2;
+
+ row-gpios = gpio0 12 GPIO_ACTIVE_HIGH /*
Bank0, pin12 */
+gpio0 13 GPIO_ACTIVE_HIGH /*
Bank0, pin13 */
+gpio0 14 GPIO_ACTIVE_HIGH /*
Bank0, pin14 */
+gpio0 15 GPIO_ACTIVE_HIGH; /*
Bank0, pin15 */
+
+ col-gpios = gpio3 9
Re: [PATCH 0/2] ARM: dts: AM4372: Add more nodes
Hi, On Fri, Oct 11, 2013 at 12:44:52AM +0530, Lokesh Vutla wrote: This patch series add nodes for l2-cache-controller, EDMA, mailbox, mmc, sham, and updates the properties for cpsw, i2c0, matrix-keypad. These patches are applied on top of Benoit's for_3.13/dts branch git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.13/dts Testing: Tested EDMA, mmc, sham, aes, des, i2c0, cpsw, matric-keypad on AM4372 EPOS EVM with the addition of following two series: - Tero's V8 of OMAP DT clock conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg96769.html - Afzal's V5 of AM43x PRCM basic support http://www.mail-archive.com/linux-omap@vger.kernel.org/msg96275.html one extra piece of info: all these patches are fresh out of Wakeup, tested on top of v3.12-rc3. -- balbi signature.asc Description: Digital signature
Re: [RFCv3 0/7] OMAP SSI driver
On Thu, Oct 10, 2013 at 09:28:01PM +0300, Aaro Koskinen wrote: On Thu, Oct 10, 2013 at 07:21:30PM +0200, Sebastian Reichel wrote: Any issues with this or any other suggestions how to proceed? Maybe you could provide some brief instructions/description of how this was tested? Sure. I used Carlos' original patch, which has been tested to be working. Then I checked with some debug prints and the debugfs support what the registers and resources should look like. Next I updated the patch to use the new kernel frameworks and made sure everything is behaves as before. For actually using the modem of the Nokia N900 three more drivers are needed in the mainline kernel in addtion to this one: 1. cmt This is a small driver handling the modem's reset line, which is connected via a gpio pin to the system. 2. ssi_protocol This is an hsi client driver, which actually talks with the modem and exports an phonet interface for userspace access. It makes use of the cmt driver. I plan on porting these to the new kernel frameworks next. If I'm not mistaken this should be enough to communicate with the modem. 3. cmt_speech This is an hsi client driver, which takes care of interchanging speech data with the modem. This one is needed for calling. I will have a look at it once the basic stuff is working. P.S.: You can get a mainline kernel status matrix for the Nokia N900 on this page: http://elinux.org/N900 -- Sebastian signature.asc Description: Digital signature
Re: [RFCv3 0/7] OMAP SSI driver
On Thu, Oct 10, 2013 at 10:02:36PM +0200, Sebastian Reichel wrote: P.S.: You can get a mainline kernel status matrix for the Nokia N900 on this page: http://elinux.org/N900 Thanks for summary, and the above page looks very useful. I wonder would it make sense to add also N9/N950 there (some functionality is shared)? Also TWL4030 DT status could be updated, e.g. watchdog support was done already last year with 8899b8d93ec64b7a8e54807a68a958e1206535e2. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/9] hwspinlock/omap: add support for dt nodes
Hi Mark, On Fri, Sep 27, 2013 at 05:06:38PM +0100, Kumar Gala wrote: On Sep 17, 2013, at 2:30 PM, Suman Anna wrote: HwSpinlock IP is present only on OMAP4 and other newer SoCs, which are all device-tree boot only. This patch adds the base support for parsing the DT nodes, and removes the code dealing with the traditional platform device instantiation. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 31 +++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/omap_hwspinlock.c | 23 +++-- 4 files changed, 50 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt new file mode 100644 index 000..235b7c5 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt @@ -0,0 +1,31 @@ +OMAP4+ HwSpinlock Driver + + +Required properties: +- compatible:Currently supports only ti,omap4-hwspinlock for + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs Currently supports is not something I expect to see in a binding document. That sounds like a description of the driver rather than the binding. How similar are these hardware modules? What are the differences? The IP is almost the same, they all have the same revision id. The number of locks (each represented by a register) though vary from one SoC to another (OMAP4, OMAP5, DRA7 have same number of locks, and AM33xx/AM43xx have a different number). The number of locks is directly read by the driver from a module register. There is no separate .data associated with the of_device_id table, so I used a single compatible property for all the SoCs. Ok. Probeability is good, it keeps these simpler :) I think This can be reworded to say should contain rather than currently supports only: - compatible: Should contain ti,omap4-hwspinlock for OMAP44xx, OMAP54xx, AM33xx, AM43xx, or DRA7xx SoCs That way the binding allows for a future backwards-compatible variant, and doesn't mention the current level of support in Linux. Yes, that is the change I have made in my current working set as well. +- reg: Contains the hwspinlock register address range (base + address and length) Is there only one register bank for the hwlock module? The lock registers start at a certain offset (0x800) within the module register space, and the offsets for various registers are identical between all SoCs. What are the other registers within the module? Are they shared with other devices, or are they simply unused by the hwspinlock driver? No, they are not shared with other devices. These are like revision register, and a SYSCONFIG register which is used by the OMAP hwmod layer. This register definition is in line with other modules on OMAP. +- ti,hwmods: Name of the hwmod associated with the hwspinlock device + +Common hwlock properties: +The following describes the usage of the common hwlock properties (defined in +Documentation/devicetree/bindings/hwlock/hwlock.txt) on OMAP. + +- hwlock-base-id:There are currently no OMAP SoCs with multiple + hwspinlock devices. The OMAP driver uses a default + base id value of 0 for the locks present within the + single hwspinlock device on all SoCs. Driver details should not leak into bindngs... OK, will remove the info on driver details. As mentioned in the other patch, I don't think this is the way to handle this. I think we need a phandle + args representation. This is an optional parameter for now and I was going to revise the description based on comments from Kumar Gala on this thread, but I will wait and adjust this based on the outcome on the first patch. Ok. I have removed this property altogether in my current working set. Will post the v3 of the series soon. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 4/8] hwspinlock/omap: enable module before reading SYSSTATUS register
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/omap_hwspinlock.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 349c5aa..9495d76 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -100,10 +100,23 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
if (!io_base)
return -ENOMEM;
+ /*
+* make sure the module is enabled and clocked before reading
+* the module SYSSTATUS register
+*/
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
+
/* Determine number of locks */
i = readl(io_base + SYSSTATUS_OFFSET);
i = SPINLOCK_NUMLOCKS_BIT_OFFSET;
+ /*
+* runtime PM will make sure the clock of this module is
+* enabled again iff at least one lock is requested
+*/
+ pm_runtime_put(pdev-dev);
+
/* one of the four lsb's must be set, and nothing else */
if (hweight_long(i 0xf) != 1 || i 8) {
ret = -EINVAL;
@@ -123,12 +136,6 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
for (i = 0, hwlock = bank-lock[0]; i num_locks; i++, hwlock++)
hwlock-priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
- /*
-* runtime PM will make sure the clock of this module is
-* enabled iff at least one lock is requested
-*/
- pm_runtime_enable(pdev-dev);
-
ret = hwspin_lock_register(bank, pdev-dev, omap_hwspinlock_ops,
base_id, num_locks);
if (ret)
@@ -137,9 +144,9 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
return 0;
reg_fail:
- pm_runtime_disable(pdev-dev);
kfree(bank);
iounmap_base:
+ pm_runtime_disable(pdev-dev);
iounmap(io_base);
return ret;
}
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 6/8] ARM: dts: OMAP4: Add hwspinlock node
Add the hwspinlock device tree node for OMAP4 family
of SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 45708e1..74db751 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -248,6 +248,12 @@
clock-frequency = 4800;
};
+ hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+ };
+
i2c1: i2c@4807 {
compatible = ti,omap4-i2c;
reg = 0x4807 0x100;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 7/8] ARM: dts: OMAP5: Add hwspinlock node
Add the hwspinlock device tree node for OMAP5 SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 86295d2..2a98a59 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -275,6 +275,12 @@
ti,hwmods = i2c5;
};
+ hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+ };
+
mcspi1: spi@48098000 {
compatible = ti,omap4-mcspi;
reg = 0x48098000 0x200;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/8] hwspinlock/core: add common dt bindings and OF helpers
This patch adds the necessary documentation and OF helpers to
represent a hwlock device and use/request locks in a device-tree
build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier.
OF helpers have been added to the driver core to read the common
'hwlock-num-locks' property, and to request a specific lock using
the phandle + args specifier. The latter function is different
from the existing non-DT function, in that the specifier is
relative to the hwlock device instead of being a global lock id
registered with the core.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 49 +
drivers/hwspinlock/hwspinlock_core.c | 85 +-
include/linux/hwspinlock.h | 19 -
3 files changed, 148 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 000..3fef8cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,49 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the number
+ of supported locks within a hwlock device cannot be
+ read from a register.
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and a 0-indexed
+relative hwlock number within that hwlock node. Multiple hwlocks can be
+requested using an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting third hwlock in the bank
+defined by the node hwlock1.
+
+ node {
+ ...
+ hwlocks = hwlock1 2;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, third hwlock within
+the hwlock device node 'hwlock1', and the first hwlock within the hwlock
+device node 'hwlock2'.
+
+ node {
+ ...
+ hwlocks = hwlock1 2, hwlock2 0;
+ ...
+ };
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 00c49d3..3f1089a 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -1,7 +1,7 @@
/*
* Hardware spinlock framework
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2013 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Ohad Ben-Cohen o...@wizery.com
*
@@ -27,6 +27,7 @@
#include linux/hwspinlock.h
#include linux/pm_runtime.h
#include linux/mutex.h
+#include linux/of.h
#include hwspinlock_internal.h
@@ -262,6 +263,33 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
}
EXPORT_SYMBOL_GPL(__hwspin_unlock);
+/**
+ * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the number of locks
+ * present within a hwspinlock device instance. The hwlock-num-locks
+ * DT property may be optional for some platforms, while mandatory for
+ * some others, so this function is typically called only by needed
+ * platform-specific implementations.
+ *
+ * Returns a positive number of locks on success, -ENODEV on generic
+ * failure or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_locks(struct device_node *dn)
+{
+ unsigned int val;
+ int ret = -ENODEV;
+
+ ret = of_property_read_u32(dn, hwlock-num-locks, val);
+ if (!ret)
+ ret = val ? val : -ENODEV;
+
+ return ret;
+}
[PATCHv3 8/8] ARM: dts: AM33XX: Add hwspinlock node
Add the hwspinlock device tree node for AM33xx family
of SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8692490..49dfb86 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -285,6 +285,12 @@
status = disabled;
};
+ hwspinlock: spinlock@480ca000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x480ca000 0x1000;
+ ti,hwmods = spinlock;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/8] omap hwspinlock dt support
Hi, This is an updated series addressing the review comments from the v2 series. The hwmod patches have been dropped from the repost as per Paul's request, they have already been queued. The series is tested on top of v3.12-rc4 + Benoit's 3.13 DTS branch and Tero's clock series, along with the queued hwmod patches. Changes in v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document - OMAP AM335 support patches are unchanged from v2. - OMAP DTS patches are unchanged from v2. v2 - Added a new common DT binding documentation and OF helpers (Patch1), addressing the review comments from v1 [2]. The MSM support [1] needs to be reworked on top of this common patch. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node (Patches 4, 5) - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup (Patches 6, 7) - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335 (Patches 8, 9). The sysc patch is not essential for AM335 spinlock functionality, but is needed for smart-idling the IP when the module is enabled. - OMAP4 DT node patch is unchanged (Patch 3) http://marc.info/?l=linux-omapm=137944644112727w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 [1] https://lkml.org/lkml/2013/8/14/528 [2] http://marc.info/?t=13782309035r=1w=2 Suman Anna (8): hwspinlock/core: maintain a list of registered hwspinlock banks hwspinlock/core: add common dt bindings and OF helpers hwspinlock/omap: add support for dt nodes hwspinlock/omap: enable module before reading SYSSTATUS register hwspinlock/omap: support AM33xx ARM: dts: OMAP4: Add hwspinlock node ARM: dts: OMAP5: Add hwspinlock node ARM: dts: AM33XX: Add hwspinlock node .../devicetree/bindings/hwlock/hwlock.txt | 49 .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 19 +++ arch/arm/boot/dts/am33xx.dtsi | 6 + arch/arm/boot/dts/omap4.dtsi | 6 + arch/arm/boot/dts/omap5.dtsi | 6 + arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/Kconfig | 2 +- drivers/hwspinlock/hwspinlock_core.c | 133 - drivers/hwspinlock/hwspinlock_internal.h | 2 + drivers/hwspinlock/omap_hwspinlock.c | 38 -- include/linux/hwspinlock.h | 19 ++- 12 files changed, 263 insertions(+), 80 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/8] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 19 +++
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60 --
drivers/hwspinlock/omap_hwspinlock.c | 17 --
4 files changed, 32 insertions(+), 67 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..8eb6965
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,19 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible: Should be ti,omap4-hwspinlock for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+ (base address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+};
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 020079e..a2312f2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -297,9 +297,6 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que s...@ti.com
- * Hari Kanigeri h-kanige...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/err.h
-#include linux/hwspinlock.h
-
-#include soc.h
-#include omap_hwmod.h
-#include omap_device.h
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = spinlock;
- const char *dev_name = omap_hwspinlock;
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err(Can't build omap_device for %s:%s\n, dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..349c5aa 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
/*
* OMAP hardware spinlock driver
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2013 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Simon Que s...@ti.com
* Hari Kanigeri h-kanige...@ti.com
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/spinlock.h
#include linux/hwspinlock.h
+#include
[PATCHv3 5/8] hwspinlock/omap: support AM33xx
AM33XX device family also supports hwspinlocks. The IP is identical to that of OMAP4/OMAP5, except for the number of locks. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/hwspinlock/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig index 70637d2..34ff9cd 100644 --- a/drivers/hwspinlock/Kconfig +++ b/drivers/hwspinlock/Kconfig @@ -10,7 +10,7 @@ menu Hardware Spinlock drivers config HWSPINLOCK_OMAP tristate OMAP Hardware Spinlock device - depends on ARCH_OMAP4 || SOC_OMAP5 + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_AM33XX select HWSPINLOCK help Say y here to support the OMAP Hardware Spinlock device (firstly -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/8] hwspinlock/core: maintain a list of registered hwspinlock banks
The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.
The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 48
drivers/hwspinlock/hwspinlock_internal.h | 2 ++
2 files changed, 50 insertions(+)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..00c49d3 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
*/
static DEFINE_MUTEX(hwspinlock_tree_lock);
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
/**
* __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
return hwlock;
}
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+ struct list_head *entry = hwspinlock_devices;
+ struct hwspinlock_device *_bank;
+ int ret = 0;
+
+ list_for_each(entry, hwspinlock_devices) {
+ _bank = list_entry(entry, struct hwspinlock_device, list);
+ if (_bank-base_id = bank-base_id + bank-num_locks)
+ break;
+ }
+
+ if (entry != hwspinlock_devices
+ entry-prev != hwspinlock_devices) {
+ _bank = list_entry(entry-prev, struct hwspinlock_device, list);
+ if (_bank-base_id + _bank-num_locks bank-base_id) {
+ dev_err(bank-dev, hwlock space overlap, cannot add
device\n);
+ ret = -EBUSY;
+ }
+ }
+
+ if (!ret)
+ list_add_tail(bank-list, entry);
+
+ return ret;
+}
+
/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
bank-base_id = base_id;
bank-num_locks = num_locks;
+ mutex_lock(hwspinlock_tree_lock);
+ ret = hwspinlock_device_add(bank);
+ mutex_unlock(hwspinlock_tree_lock);
+ if (ret)
+ return ret;
+
for (i = 0; i num_locks; i++) {
hwlock = bank-lock[i];
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
reg_failed:
while (--i = 0)
hwspin_lock_unregister_single(base_id + i);
+ mutex_lock(hwspinlock_tree_lock);
+ list_del(bank-list);
+ mutex_unlock(hwspinlock_tree_lock);
return ret;
}
EXPORT_SYMBOL_GPL(hwspin_lock_register);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h
b/drivers/hwspinlock/hwspinlock_internal.h
index d26f78b..aff560c 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -53,6 +53,7 @@ struct hwspinlock {
/**
* struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
* @dev: underlying device, will be used to invoke runtime PM api
* @ops: platform-specific hwspinlock handlers
* @base_id: id index of the first lock in this device
@@ -60,6 +61,7 @@ struct hwspinlock {
* @lock: dynamically allocated array of 'struct hwspinlock'
*/
struct hwspinlock_device {
+ struct list_head list;
struct device *dev;
const struct hwspinlock_ops *ops;
int base_id;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2
Tony Lindgren t...@atomide.com writes: Here's a respin of the pinctrl-single related patches to use chained irq as suggested by Linus W earlier. This series does not try to provide any generic automated solution yet, but works by doing a request_irq() for the wake-up pin, so it should be flexible enough for both manual control and automated solution. This series removes the last nasty blocker for making omap3 to be device tree only without causing nasty PM regressions. Indeed, I gave this a spin on several OMAP3 platforms with legacy boot and ran through a series of retention and off-mode tests for idle and suspend with both UART and RTC wakeups. No regressions found. So... Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org on 3530/beagle, 3730/beagle-xM, 3530/Overo, 3730/Overo STORM Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Make few omap3 boards device tree only
Hi all, Now that we have the remaining omap3 PM related wake-up events mostly resolved, it's time to start making omap3 to be device tree only. These are the boards that I'm using for testing in my rack setup, so I've verified that the basic features work well enough for me so we can make them device tree only. Patches are welcome to add more features :) Regards, Tony --- Tony Lindgren (8): ARM: OMAP2+: Use pdata quirks for wl12xx for omap3 evm and zoom3 ARM: OMAP2+: Add minimal 8250 support for GPMC ARM: dts: Shared file for omap GPMC connected smsc911x ARM: dts: Add common support for omap3-evm ARM: dts: Add basic support for TMDSEVM3730 (Mistral AM/DM37x EVM) ARM: dts: Add basic support for zoom3 ARM: OMAP2+: Remove legacy booting support for omap3 EVM ARM: OMAP2+: Remove legacy support for zoom platforms arch/arm/boot/dts/Makefile |2 arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi| 52 ++ arch/arm/boot/dts/omap-zoom-common.dtsi | 33 + arch/arm/boot/dts/omap3-evm-37xx.dts | 146 + arch/arm/boot/dts/omap3-evm-common.dtsi | 96 +++ arch/arm/boot/dts/omap3-evm.dts | 58 -- arch/arm/boot/dts/omap3-igep0020.dts | 45 -- arch/arm/boot/dts/omap3-zoom3.dts| 217 +++ arch/arm/mach-omap2/Kconfig | 26 - arch/arm/mach-omap2/Makefile | 10 arch/arm/mach-omap2/board-3630sdp.c | 225 arch/arm/mach-omap2/board-ldp.c |3 arch/arm/mach-omap2/board-omap3evm.c | 756 -- arch/arm/mach-omap2/board-zoom-debugboard.c | 139 - arch/arm/mach-omap2/board-zoom-display.c | 71 -- arch/arm/mach-omap2/board-zoom-peripherals.c | 360 arch/arm/mach-omap2/board-zoom.c | 159 - arch/arm/mach-omap2/board-zoom.h | 10 arch/arm/mach-omap2/gpmc.c | 38 + arch/arm/mach-omap2/pdata-quirks.c | 12 20 files changed, 601 insertions(+), 1857 deletions(-) create mode 100644 arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi create mode 100644 arch/arm/boot/dts/omap-zoom-common.dtsi create mode 100644 arch/arm/boot/dts/omap3-evm-37xx.dts create mode 100644 arch/arm/boot/dts/omap3-evm-common.dtsi create mode 100644 arch/arm/boot/dts/omap3-zoom3.dts delete mode 100644 arch/arm/mach-omap2/board-3630sdp.c delete mode 100644 arch/arm/mach-omap2/board-omap3evm.c delete mode 100644 arch/arm/mach-omap2/board-zoom-debugboard.c delete mode 100644 arch/arm/mach-omap2/board-zoom-display.c delete mode 100644 arch/arm/mach-omap2/board-zoom-peripherals.c delete mode 100644 arch/arm/mach-omap2/board-zoom.c delete mode 100644 arch/arm/mach-omap2/board-zoom.h -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] ARM: dts: Add common support for omap3-evm
Looks like the main difference between the TMDSEVM3530 and
TMDSEVM3730 is just the omap processor:
http://www.ti.com/tool/tmdsevm3530
http://www.ti.com/tool/tmdsevm3730
So let's add a common file for the EVMs, and fix the description
for the omap3-evm.dst as that's clearly for the TMDSEVM3530
since it includes omap34xx.dtsi. It cannot support the TMDSEVM3730
properly, and we need a separate file for that in the following
patch.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-evm-common.dtsi | 60 +++
arch/arm/boot/dts/omap3-evm.dts | 58 +-
2 files changed, 62 insertions(+), 56 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-evm-common.dtsi
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi
b/arch/arm/boot/dts/omap3-evm-common.dtsi
new file mode 100644
index 000..75753bb
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -0,0 +1,60 @@
+/*
+ * Common support for omap3 EVM boards
+ */
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ leds {
+ compatible = gpio-leds;
+ ledb {
+ label = omap3evm::ledb;
+ gpios = twl_gpio 19 GPIO_ACTIVE_HIGH; /* LEDB */
+ linux,default-trigger = default-on;
+ };
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+#include twl4030.dtsi
+#include twl4030_omap3.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+
+ /*
+* TVP5146 Video decoder-in for analog input support.
+*/
+ tvp5146@5c {
+ compatible = ti,tvp5146m2;
+ reg = 0x5c;
+ };
+};
+
+twl_gpio {
+ ti,use-leds;
+};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..e10dcd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -8,68 +8,14 @@
/dts-v1/;
#include omap34xx.dtsi
+#include omap3-evm-common.dtsi
/ {
- model = TI OMAP3 EVM (OMAP3530, AM/DM37x);
+ model = TI OMAP35XX EVM (TMDSEVM3530);
compatible = ti,omap3-evm, ti,omap3;
- cpus {
- cpu@0 {
- cpu0-supply = vcc;
- };
- };
-
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
};
-
- leds {
- compatible = gpio-leds;
- ledb {
- label = omap3evm::ledb;
- gpios = twl_gpio 19 GPIO_ACTIVE_HIGH; /* LEDB */
- linux,default-trigger = default-on;
- };
- };
-};
-
-i2c1 {
- clock-frequency = 260;
-
- twl: twl@48 {
- reg = 0x48;
- interrupts = 7; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = intc;
- };
-};
-
-#include twl4030.dtsi
-#include twl4030_omap3.dtsi
-
-i2c2 {
- clock-frequency = 40;
-};
-
-i2c3 {
- clock-frequency = 40;
-
- /*
-* TVP5146 Video decoder-in for analog input support.
-*/
- tvp5146@5c {
- compatible = ti,tvp5146m2;
- reg = 0x5c;
- };
-};
-
-twl_gpio {
- ti,use-leds;
-};
-
-usb_otg_hs {
- interface-type = 0;
- usb-phy = usb2_phy;
- mode = 3;
- power = 50;
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] ARM: OMAP2+: Remove legacy support for zoom platforms
We now have pretty decent device tree based support for
zoom platforms. It's not complete, but basics work for
me so adding more features should be quite trivial.
Looks like also 3630 sdp is zoom based, and looking
at it's board file should also be trivial to support
with the device tree based booting.
Patches are welcome if people are still using these.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 20 -
arch/arm/mach-omap2/Makefile |9 -
arch/arm/mach-omap2/board-3630sdp.c | 225
arch/arm/mach-omap2/board-ldp.c |3
arch/arm/mach-omap2/board-zoom-debugboard.c | 139 --
arch/arm/mach-omap2/board-zoom-display.c | 71 -
arch/arm/mach-omap2/board-zoom-peripherals.c | 360 --
arch/arm/mach-omap2/board-zoom.c | 159 ---
arch/arm/mach-omap2/board-zoom.h | 10 -
9 files changed, 1 insertion(+), 995 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-3630sdp.c
delete mode 100644 arch/arm/mach-omap2/board-zoom-debugboard.c
delete mode 100644 arch/arm/mach-omap2/board-zoom-display.c
delete mode 100644 arch/arm/mach-omap2/board-zoom-peripherals.c
delete mode 100644 arch/arm/mach-omap2/board-zoom.c
delete mode 100644 arch/arm/mach-omap2/board-zoom.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 91a65b3..216154d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -317,20 +317,6 @@ config MACH_NOKIA_RX51
default y
select OMAP_PACKAGE_CBB
-config MACH_OMAP_ZOOM2
- bool OMAP3 Zoom2 board
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CBB
- select REGULATOR_FIXED_VOLTAGE if REGULATOR
-
-config MACH_OMAP_ZOOM3
- bool OMAP3630 Zoom3 board
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CBP
- select REGULATOR_FIXED_VOLTAGE if REGULATOR
-
config MACH_CM_T35
bool CompuLab CM-T35/CM-T3730 modules
depends on ARCH_OMAP3
@@ -366,12 +352,6 @@ config MACH_SBC3530
default y
select OMAP_PACKAGE_CUS
-config MACH_OMAP_3630SDP
- bool OMAP3630 SDP board
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CBP
-
config MACH_TI8168EVM
bool TI8168 Evaluation Module
depends on SOC_TI81XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7be6e3a..9d78b49 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -249,15 +249,6 @@ obj-$(CONFIG_MACH_NOKIA_RM680) +=
board-rm680.o sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-video.o
-obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o board-zoom-peripherals.o
-obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-display.o
-obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-debugboard.o
-obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o board-zoom-peripherals.o
-obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom-display.o
-obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom-debugboard.o
-obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o
-obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-zoom-peripherals.o
-obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-zoom-display.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o
obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
deleted file mode 100644
index 20d6d81..000
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ /dev/null
@@ -1,225 +0,0 @@
-/*
- * Copyright (C) 2009 Texas Instruments Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/input.h
-#include linux/gpio.h
-#include linux/mtd/nand.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-
-#include common.h
-#include gpmc-smc91x.h
-
-#include board-zoom.h
-
-#include board-flash.h
-#include mux.h
-#include sdram-hynix-h8mbx00u0mer-0em.h
-
-#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
-
-static struct omap_smc91x_platform_data board_smc91x_data = {
- .cs = 3,
- .flags = GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL,
-};
-
-static void __init board_smc91x_init(void)
-{
- board_smc91x_data.gpio_irq = 158;
- gpmc_smc91x_init(board_smc91x_data);
-}
-
-#else
-
-static inline void board_smc91x_init(void)
-{
-}
-
-#endif /*
[PATCH 5/8] ARM: dts: Add basic support for TMDSEVM3730 (Mistral AM/DM37x EVM)
I've tested the serial, MMC, smsc911x, wl12xx, and off-idle support
with the pinctrl patches, so it probably works better than the
board-*.c files ever did. Also the board-omap3evm.c file is broken
for the DSS, and has been for a while. Patches are welcome to fix
it in this .dts file, let's just drop the board-*.c file for this.
Note that off-idle currently requires doing request_irq() on the
wake-up pin from pinctrl-single IRQ domain until we can handle
that in some Linux generic way.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/Makefile |1
arch/arm/boot/dts/omap3-evm-37xx.dts| 146 +++
arch/arm/boot/dts/omap3-evm-common.dtsi | 36
3 files changed, 183 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-evm-37xx.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 802720e..3c4e105 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -172,6 +172,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3-evm-37xx.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts
b/arch/arm/boot/dts/omap3-evm-37xx.dts
new file mode 100644
index 000..d1642f7
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include omap36xx.dtsi
+#include omap3-evm-common.dtsi
+
+
+/ {
+ model = TI OMAP37XX EVM (TMDSEVM3730);
+ compatible = ti,omap3-evm-37xx, ti,omap36xx;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+omap3_pmx_core {
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
sdmmc1_clk.sdmmc1_clk */
+ 0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_cmd.sdmmc1_cmd */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat0.sdmmc1_dat0 */
+ 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat1.sdmmc1_dat1 */
+ 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat2.sdmmc1_dat2 */
+ 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
+ 0x120 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat4.sdmmc1_dat4 */
+ 0x122 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat5.sdmmc1_dat5 */
+ 0x124 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat6.sdmmc1_dat6 */
+ 0x126 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat7.sdmmc1_dat7 */
+ ;
+ };
+
+ /* NOTE: Clocked externally, needs INPUT also for sdmmc2_clk.sdmmc2_clk
*/
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_clk.sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_cmd.sdmmc2_cmd */
+ 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat0.sdmmc2_dat0 */
+ 0x12e (WAKEUP_EN | PIN_INPUT_PULLUP | MUX_MODE0) /*
sdmmc2_dat1.sdmmc2_dat1 */
+ 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat2.sdmmc2_dat2 */
+ 0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_dat3.sdmmc2_dat3 */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e (WAKEUP_EN | PIN_INPUT | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx */
+ ;
+ };
+
+ wl12xx_gpio: pinmux_wl12xx_gpio {
+ pinctrl-single,pins =
+ 0x150 (PIN_OUTPUT | MUX_MODE4) /*
uart1_cts.gpio_150 */
+ 0x14e (PIN_INPUT | MUX_MODE4) /*
uart1_rts.gpio_149 */
+ ;
+ };
+
+ smsc911x_pins: pinmux_smsc911x_pins {
+ pinctrl-single,pins =
+ 0x1a2 (PIN_INPUT | MUX_MODE4) /*
mcspi1_cs2.gpio_176 */
+ ;
+ };
+};
+
+mmc1 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+};
+
+mmc2 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc2_pins;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+uart3 {
+ pinctrl-names = default;
+ pinctrl-0 = uart3_pins;
+};
+
+gpmc {
+
[PATCH 2/8] ARM: OMAP2+: Add minimal 8250 support for GPMC
Just initialize things using the bootloader timings like
we've been doing for the legacy booting too. It should be
possible to patch in the GPMC timings for the based on the
TL16CP743C/TL16C754C manual at:
http://www.ti.com/lit/ds/slls644g/slls644g.pdf
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpmc.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 579697a..51525fa 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1521,6 +1521,42 @@ err:
return ret;
}
+/*
+ * REVISIT: Add timing support from slls644g.pdf
+ */
+static int gpmc_probe_8250(struct platform_device *pdev,
+ struct device_node *child)
+{
+ struct resource res;
+ unsigned long base;
+ int ret, cs;
+
+ if (of_property_read_u32(child, reg, cs) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, res) 0) {
+ dev_err(pdev-dev, %s has malformed 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ ret = gpmc_cs_request(cs, resource_size(res), base);
+ if (ret 0) {
+ dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
+ return ret;
+ }
+
+ if (of_platform_device_create(child, NULL, pdev-dev))
+ return 0;
+
+ dev_err(pdev-dev, failed to create gpmc child %s\n, child-name);
+
+ return -ENODEV;
+}
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1564,6 +1600,8 @@ static int gpmc_probe_dt(struct platform_device *pdev)
else if (of_node_cmp(child-name, ethernet) == 0 ||
of_node_cmp(child-name, nor) == 0)
ret = gpmc_probe_generic_child(pdev, child);
+ else if (of_node_cmp(child-name, 8250) == 0)
+ ret = gpmc_probe_8250(pdev, child);
if (WARN(ret 0, %s: probing gpmc child %s failed\n,
__func__, child-full_name))
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] ARM: dts: Add basic support for zoom3
I've tested serial, MMC, smsc911x and wl12xx on zoom3. As my
omap is an early ES revision, I have not been able to test
off-idle on this one. But anyways, I'd say we have enough
device tree support for the zoom to be able to drop the
board-zoom files. Patches are welcome to add further features
to this .dts file.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/Makefile |1
arch/arm/boot/dts/omap-zoom-common.dtsi | 33 +
arch/arm/boot/dts/omap3-zoom3.dts | 217 +++
3 files changed, 251 insertions(+)
create mode 100644 arch/arm/boot/dts/omap-zoom-common.dtsi
create mode 100644 arch/arm/boot/dts/omap3-zoom3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3c4e105..ce332c8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -176,6 +176,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
+ omap3-zoom3.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap-zoom-common.dtsi
b/arch/arm/boot/dts/omap-zoom-common.dtsi
new file mode 100644
index 000..b0ee342
--- /dev/null
+++ b/arch/arm/boot/dts/omap-zoom-common.dtsi
@@ -0,0 +1,33 @@
+/*
+ * Common features on the Zoom debug board
+ */
+
+#include omap-gpmc-smsc911x.dtsi
+
+gpmc {
+ ranges = 3 0 0x1000 0x0400,
+7 0 0x2c00 0x0100;
+
+ /*
+* Four port TL16CP754C serial port on GPMC,
+* they probably share the same GPIO IRQ
+* REVISIT: Add timing support from slls644g.pdf
+*/
+ 8250@3,0 {
+ compatible = ns16550a;
+ reg = 3 0 0x100;
+ bank-width = 2;
+ reg-shift = 1;
+ reg-io-width = 1;
+ interrupt-parent = gpio4;
+ interrupts = 6 IRQ_TYPE_EDGE_RISING; /* gpio102 */
+ clock-frequency = 1843200;
+ current-speed = 115200;
+ };
+
+ ethernet@gpmc {
+ reg = 7 0 0xff;
+ interrupt-parent = gpio5;
+ interrupts = 30 IRQ_TYPE_LEVEL_LOW; /* gpio158 */
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-zoom3.dts
b/arch/arm/boot/dts/omap3-zoom3.dts
new file mode 100644
index 000..15eb9fe
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-zoom3.dts
@@ -0,0 +1,217 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include omap36xx.dtsi
+#include omap-zoom-common.dtsi
+
+/ {
+ model = TI Zoom3;
+ compatible = ti,omap3-zoom3, ti,omap36xx, ti,omap3;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
+
+ wl12xx_vmmc: wl12xx_vmmc {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_gpio;
+ compatible = regulator-fixed;
+ regulator-name = vwl1271;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio4 5 0;/* gpio101 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+};
+
+omap3_pmx_core {
+ /* REVISIT: twl gpio0 is mmc0_cd */
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
sdmmc1_clk.sdmmc1_clk */
+ 0x116 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
sdmmc1_cmd.sdmmc1_cmd */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat0.sdmmc1_dat0 */
+ 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat1.sdmmc1_dat1 */
+ 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat2.sdmmc1_dat2 */
+ 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
+ ;
+ };
+
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_clk.sdmmc2_clk */
+ 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc2_cmd.sdmmc2_cmd */
+
[PATCH 1/8] ARM: OMAP2+: Use pdata quirks for wl12xx for omap3 evm and zoom3
As the wl12xx bindings are still pending, this way we can
get things working for omap3 evm and zoom platforms.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/pdata-quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 18afbde..10c7145 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -82,6 +82,16 @@ static void __init omap3_igep0020_legacy_init(void)
{
omap3_igep2_display_init_of();
}
+
+static void __init omap3_evm_legacy_init(void)
+{
+ legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
+}
+
+static void __init omap3_zoom_legacy_init(void)
+{
+ legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
+}
#endif /* CONFIG_ARCH_OMAP3 */
#ifdef CONFIG_ARCH_OMAP4
@@ -132,6 +142,8 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ nokia,omap3-n9, hsmmc2_internal_input_clk, },
{ nokia,omap3-n950, hsmmc2_internal_input_clk, },
{ isee,omap3-igep0020, omap3_igep0020_legacy_init, },
+ { ti,omap3-evm-37xx, omap3_evm_legacy_init, },
+ { ti,omap3-zoom3, omap3_zoom_legacy_init, },
#endif
#ifdef CONFIG_ARCH_OMAP4
{ ti,omap4-sdp, omap4_sdp_legacy_init, },
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] ARM: dts: Shared file for omap GPMC connected smsc911x
Looks like at least Igep, Zoom and EVM boards can use a
common file for the GPMC connected smsc911x.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 52 +
arch/arm/boot/dts/omap3-igep0020.dts | 45 +
2 files changed, 54 insertions(+), 43 deletions(-)
create mode 100644 arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
diff --git a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
new file mode 100644
index 000..9c18adf
--- /dev/null
+++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
@@ -0,0 +1,52 @@
+/*
+ * Common file for GPMC connected smsc911x on omaps
+ *
+ * Note that the board specifc DTS file needs to specify
+ * ranges, pinctrl, reg, interrupt parent and interrupts.
+ */
+
+/ {
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
+};
+
+gpmc {
+ ethernet@gpmc {
+ compatible = smsc,lan9221, smsc,lan9115;
+ bank-width = 2;
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 186;
+ gpmc,cs-wr-off-ns = 186;
+ gpmc,adv-on-ns = 12;
+ gpmc,adv-rd-off-ns = 48;
+ gpmc,adv-wr-off-ns = 48;
+ gpmc,oe-on-ns = 54;
+ gpmc,oe-off-ns = 168;
+ gpmc,we-on-ns = 54;
+ gpmc,we-off-ns = 168;
+ gpmc,rd-cycle-ns = 186;
+ gpmc,wr-cycle-ns = 186;
+ gpmc,access-ns = 114;
+ gpmc,page-burst-access-ns = 6;
+ gpmc,bus-turnaround-ns = 12;
+ gpmc,cycle2cycle-delay-ns = 18;
+ gpmc,wr-data-mux-bus-ns = 90;
+ gpmc,wr-access-ns = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 4;
+ smsc,save-mac-address;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..503d928 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -10,6 +10,7 @@
*/
#include omap3-igep.dtsi
+#include omap-gpmc-smsc911x.dtsi
/ {
model = IGEPv2;
@@ -40,18 +41,6 @@
gpios = twl_gpio 19 GPIO_ACTIVE_LOW;
};
};
-
- vddvario: regulator-vddvario {
- compatible = regulator-fixed;
- regulator-name = vddvario;
- regulator-always-on;
- };
-
- vdd33a: regulator-vdd33a {
- compatible = regulator-fixed;
- regulator-name = vdd33a;
- regulator-always-on;
- };
};
i2c3 {
@@ -117,41 +106,11 @@
};
};
- ethernet@5,0 {
+ ethernet@gpmc {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
- compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff;
- bank-width = 2;
-
- gpmc,mux-add-data;
- gpmc,cs-on-ns = 0;
- gpmc,cs-rd-off-ns = 186;
- gpmc,cs-wr-off-ns = 186;
- gpmc,adv-on-ns = 12;
- gpmc,adv-rd-off-ns = 48;
- gpmc,adv-wr-off-ns = 48;
- gpmc,oe-on-ns = 54;
- gpmc,oe-off-ns = 168;
- gpmc,we-on-ns = 54;
- gpmc,we-off-ns = 168;
- gpmc,rd-cycle-ns = 186;
- gpmc,wr-cycle-ns = 186;
- gpmc,access-ns = 114;
- gpmc,page-burst-access-ns = 6;
- gpmc,bus-turnaround-ns = 12;
- gpmc,cycle2cycle-delay-ns = 18;
- gpmc,wr-data-mux-bus-ns = 90;
- gpmc,wr-access-ns = 186;
- gpmc,cycle2cycle-samecsen;
- gpmc,cycle2cycle-diffcsen;
-
interrupt-parent = gpio6;
interrupts = 16 8;
- vmmc-supply = vddvario;
- vmmc_aux-supply = vdd33a;
- reg-io-width = 4;
-
- smsc,save-mac-address;
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] ARM: OMAP2+: Remove legacy booting support for omap3 EVM
We now have pretty decent support with the device tree
based booting. Patches to add more features are welcome.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |6
arch/arm/mach-omap2/Makefile |1
arch/arm/mach-omap2/board-omap3evm.c | 756 --
3 files changed, 763 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-omap3evm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f6a1db1..91a65b3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -256,12 +256,6 @@ config MACH_OVERO
default y
select OMAP_PACKAGE_CBB
-config MACH_OMAP3EVM
- bool OMAP 3530 EVM board
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CBB
-
config MACH_OMAP3517EVM
bool OMAP3517/ AM3517 EVM board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f8d4a1b..7be6e3a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -242,7 +242,6 @@ obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o
obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
-obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
deleted file mode 100644
index 1814387..000
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ /dev/null
@@ -1,756 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-omap3evm.c
- *
- * Copyright (C) 2008 Texas Instruments
- *
- * Modified from mach-omap2/board-3430sdp.c
- *
- * Initial code: Syed Mohammed Khasim
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/gpio.h
-#include linux/input.h
-#include linux/input/matrix_keypad.h
-#include linux/leds.h
-#include linux/interrupt.h
-
-#include linux/mtd/mtd.h
-#include linux/mtd/partitions.h
-#include linux/mtd/nand.h
-
-#include linux/spi/spi.h
-#include linux/spi/ads7846.h
-#include linux/i2c/twl.h
-#include linux/usb/otg.h
-#include linux/usb/musb.h
-#include linux/usb/usb_phy_gen_xceiv.h
-#include linux/smsc911x.h
-
-#include linux/wl12xx.h
-#include linux/regulator/fixed.h
-#include linux/regulator/machine.h
-#include linux/mmc/host.h
-#include linux/export.h
-#include linux/usb/phy.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include linux/platform_data/mtd-nand-omap2.h
-#include common.h
-#include linux/platform_data/spi-omap2-mcspi.h
-#include video/omapdss.h
-#include video/omap-panel-data.h
-
-#include soc.h
-#include mux.h
-#include sdram-micron-mt46h32m32lf-6.h
-#include hsmmc.h
-#include common-board-devices.h
-#include board-flash.h
-
-#defineNAND_CS 0
-
-#define OMAP3_EVM_TS_GPIO 175
-#define OMAP3_EVM_EHCI_VBUS22
-#define OMAP3_EVM_EHCI_SELECT 61
-
-#define OMAP3EVM_ETHR_START0x2c00
-#define OMAP3EVM_ETHR_SIZE 1024
-#define OMAP3EVM_ETHR_ID_REV 0x50
-#define OMAP3EVM_ETHR_GPIO_IRQ 176
-#define OMAP3EVM_SMSC911X_CS 5
-/*
- * Eth Reset signal
- * 64 = Generation 1 (=RevD)
- * 7 = Generation 2 (=RevE)
- */
-#define OMAP3EVM_GEN1_ETHR_GPIO_RST64
-#define OMAP3EVM_GEN2_ETHR_GPIO_RST7
-
-/*
- * OMAP35x EVM revision
- * Run time detection of EVM revision is done by reading Ethernet
- * PHY ID -
- * GEN_1 = 0x0115
- * GEN_2 = 0x9220
- */
-enum {
- OMAP3EVM_BOARD_GEN_1 = 0, /* EVM Rev between A - D */
- OMAP3EVM_BOARD_GEN_2, /* EVM Rev = Rev E */
-};
-
-static u8 omap3_evm_version;
-
-static u8 get_omap3_evm_rev(void)
-{
- return omap3_evm_version;
-}
-
-static void __init omap3_evm_get_revision(void)
-{
- void __iomem *ioaddr;
- unsigned int smsc_id;
-
- /* Ethernet PHY ID is stored at ID_REV register */
- ioaddr = ioremap_nocache(OMAP3EVM_ETHR_START, SZ_1K);
- if (!ioaddr)
- return;
- smsc_id = readl(ioaddr + OMAP3EVM_ETHR_ID_REV) 0x;
- iounmap(ioaddr);
-
- switch (smsc_id) {
- /*SMSC9115 chipset*/
- case 0x0115:
- omap3_evm_version = OMAP3EVM_BOARD_GEN_1;
- break;
- /*SMSC 9220 chipset*/
- case 0x9220:
- default:
- omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
- }
-}
-
-#if
Re: [RFCv3 0/7] OMAP SSI driver
On Thu, Oct 10, 2013 at 11:19:14PM +0300, Aaro Koskinen wrote: On Thu, Oct 10, 2013 at 10:02:36PM +0200, Sebastian Reichel wrote: P.S.: You can get a mainline kernel status matrix for the Nokia N900 on this page: http://elinux.org/N900 Thanks for summary, You're welcome. and the above page looks very useful. I wonder would it make sense to add also N9/N950 there (some functionality is shared)? mh maybe. I haven't looked @ N9/N950 so far, since I don't own them. I would be interested in a N950, but I don't own one and it's almost impossible to get one :( Apart from that I'm not sure if it's a good idea to make the table even more complex. Maybe just add a new page? Also TWL4030 DT status could be updated, e.g. watchdog support was done already last year with 8899b8d93ec64b7a8e54807a68a958e1206535e2. Yes. I only recently added the DT column and have not yet checked all the drivers. Probably it's also a good idea to split this column into driver supports DT and DT file supports it. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
* Linus Walleij linus.wall...@linaro.org [131010 08:43]: On Wed, Oct 9, 2013 at 5:10 PM, Tony Lindgren t...@atomide.com wrote: I was thinking I'll set up an immutable branch for the three pinctrl patches against -rc4 then both you and I can merge them in as needed. Does that work for you? Hm it's fair enough to have them in your tree if they do not collide ... especially if you want to do some of my suggested follow-up moving the ioring handling down into pinctrl-single on top of that. OK, the PRM changes will have to wait until omap3 is DT only, probably not until v3.14. I can also do a test merge with pinctrl/for-next also to make sure there are no conflicts. Sure, as long as that works you should be safe. Seems to merge with no conflicts and build just fine. Here's the signed tag for the three pinctrl-single patches for you to pull in too in case you are planning to make some pinctrl wide changes. Let's consider those commits immutable now, if I need to fix something I will post them as separate patches. Regards, Tony The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/pinctrl-single-for-linus-for-v3.13-signed for you to fetch changes up to dc7743aa3c49fabbc6dc9edbcf7df74d776ac32e: pinctrl: single: Add support for auxdata (2013-10-10 15:30:47 -0700) Changes to pinctrl-single to allow handling the wake-up interrupts that most omaps have in each pinctrl register. As I need these merged also into the omap tree, it was agreed that I set them up into a separate branch for both pinctrl tree and linux-omap tree to merge as needed. Tony Lindgren (3): pinctrl: single: Prepare for supporting SoC specific features pinctrl: single: Add support for wake-up interrupts pinctrl: single: Add support for auxdata .../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 + drivers/pinctrl/pinctrl-single.c | 383 - include/linux/platform_data/pinctrl-single.h | 12 + 3 files changed, 397 insertions(+), 9 deletions(-) create mode 100644 include/linux/platform_data/pinctrl-single.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2
* Kevin Hilman khil...@linaro.org [131010 14:55]: Tony Lindgren t...@atomide.com writes: Here's a respin of the pinctrl-single related patches to use chained irq as suggested by Linus W earlier. This series does not try to provide any generic automated solution yet, but works by doing a request_irq() for the wake-up pin, so it should be flexible enough for both manual control and automated solution. This series removes the last nasty blocker for making omap3 to be device tree only without causing nasty PM regressions. Indeed, I gave this a spin on several OMAP3 platforms with legacy boot and ran through a series of retention and off-mode tests for idle and suspend with both UART and RTC wakeups. No regressions found. So... Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org on 3530/beagle, 3730/beagle-xM, 3530/Overo, 3730/Overo STORM Thanks for testing, applying these into omap-for-v3.13/quirk because of the dependencies. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Minor omap2plus_defconfig updates for v3.13 merge window
Hi all, As it's currently a bit of a pain to patch omap2plus_defconfig, let's run make savedefconfig on it as that also gets rid of about 30 lines from it. And let's add some WLAN modules and support for of_serial. Regards, Tony --- Tony Lindgren (2): ARM: OMAP2+: Run make savedefconfig on omap2plus_defconfig to shrink it ARM: OMAP2+: Add WLAN modules and of_serial to omap2plus_defconfig arch/arm/configs/omap2plus_defconfig | 101 +- 1 file changed, 39 insertions(+), 62 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: Run make savedefconfig on omap2plus_defconfig to shrink it
We can save few tens of lines this way, and it is easier to generate minimal patches against omap2plus_defconfig. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig | 92 +++--- 1 file changed, 30 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 254cf05..9549d6f 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -1,14 +1,13 @@ -CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y -# CONFIG_SYSCTL_SYSCALL is not set -CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y @@ -20,22 +19,21 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_MULTI_V6=y -CONFIG_ARCH_OMAP2PLUS=y +CONFIG_OMAP_RESET_CLOCKS=y +CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARCH_OMAP2=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP4=y +CONFIG_SOC_OMAP5=y CONFIG_SOC_AM33XX=y -CONFIG_OMAP_RESET_CLOCKS=y -CONFIG_OMAP_MUX_DEBUG=y -CONFIG_ARCH_VEXPRESS_CA9X4=y +CONFIG_SOC_DRA7XX=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_NR_CPUS=2 -CONFIG_LEDS=y +CONFIG_CMA=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y @@ -61,8 +59,6 @@ CONFIG_IP_PNP_RARP=y # CONFIG_IPV6 is not set CONFIG_NETFILTER=y CONFIG_CAN=m -CONFIG_CAN_RAW=m -CONFIG_CAN_BCM=m CONFIG_CAN_C_CAN=m CONFIG_CAN_C_CAN_PLATFORM=m CONFIG_BT=m @@ -77,14 +73,12 @@ CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug -CONFIG_CMA=y -CONFIG_DMA_CMA=y -CONFIG_CONNECTOR=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y +CONFIG_DMA_CMA=y +CONFIG_CONNECTOR=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_OOPS=y CONFIG_MTD_CFI=y @@ -98,32 +92,32 @@ CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 -CONFIG_SENSORS_LIS3LV02D=m CONFIG_SENSORS_TSL2550=m -CONFIG_SENSORS_LIS3_I2C=m CONFIG_BMP085_I2C=m +CONFIG_SENSORS_LIS3_I2C=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_MD=y CONFIG_NETDEVICES=y -CONFIG_SMSC_PHY=y -CONFIG_NET_ETHERNET=y -CONFIG_SMC91X=y -CONFIG_SMSC911X=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y -CONFIG_LIBERTAS=m -CONFIG_LIBERTAS_USB=m -CONFIG_LIBERTAS_SDIO=m -CONFIG_LIBERTAS_DEBUG=y +CONFIG_SMC91X=y +CONFIG_SMSC911X=y +CONFIG_TI_CPSW=y +CONFIG_AT803X_PHY=y +CONFIG_SMSC_PHY=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y +CONFIG_LIBERTAS=m +CONFIG_LIBERTAS_USB=m +CONFIG_LIBERTAS_SDIO=m +CONFIG_LIBERTAS_DEBUG=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y @@ -133,7 +127,6 @@ CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y CONFIG_INPUT_MISC=y CONFIG_INPUT_TWL4030_PWRBUTTON=y -CONFIG_VT_HW_CONSOLE_BINDING=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y @@ -143,8 +136,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y -CONFIG_SERIAL_AMBA_PL011=y -CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y CONFIG_HW_RANDOM=y @@ -158,31 +149,29 @@ CONFIG_GPIO_TWL4030=y CONFIG_W1=y CONFIG_POWER_SUPPLY=y CONFIG_SENSORS_LM75=m -CONFIG_WATCHDOG=y CONFIG_THERMAL=y -CONFIG_THERMAL_HWMON=y -CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y CONFIG_THERMAL_GOV_FAIR_SHARE=y -CONFIG_THERMAL_GOV_STEP_WISE=y CONFIG_THERMAL_GOV_USER_SPACE=y -CONFIG_CPU_THERMAL=y +CONFIG_TI_SOC_THERMAL=y +CONFIG_OMAP4_THERMAL=y +CONFIG_OMAP5_THERMAL=y +CONFIG_DRA752_THERMAL=y +CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y -CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS65910=y +CONFIG_REGULATOR_TWL4030=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y -CONFIG_FB_OMAP_LCD_VGA=y CONFIG_OMAP2_DSS=m -CONFIG_OMAP2_DSS_RFBI=y CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y CONFIG_FB_OMAP2=m @@ -194,12 +183,8 @@ CONFIG_DISPLAY_PANEL_DPI=m CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y -CONFIG_DISPLAY_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y -CONFIG_FONTS=y -CONFIG_FONT_8x8=y -CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_SOUND=m CONFIG_SND=m @@ -216,13 +201,10 @@
[PATCH 2/2] ARM: OMAP2+: Add WLAN modules and of_serial to omap2plus_defconfig
Many boards have either WL12XX or MWIFIEX, so let's build modules for those by default. This also makes it easier to test WLAN on pandaboard to avoid regressions like we had with the move to device tree based booting. And at least the zoom boards need the of_serial for the UARTs connected to the GPMC bus. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig |9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 9549d6f..dad6816 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -118,6 +118,14 @@ CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m CONFIG_LIBERTAS_DEBUG=y +CONFIG_WL_TI=y +CONFIG_WL12XX=m +CONFIG_WL18XX=m +CONFIG_WLCORE_SPI=m +CONFIG_WLCORE_SDIO=m +CONFIG_MWIFIEX=m +CONFIG_MWIFIEX_SDIO=m +CONFIG_MWIFIEX_USB=m CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y @@ -136,6 +144,7 @@ CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y +CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y CONFIG_HW_RANDOM=y -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Upgrade Your Web Account
Your mailbox has exceeded the storage limit of 10GB as indicated by the administrator, is currently running on 10.9GB,may not be able to send or receive new messages until when you re-validate your mailbox. To re-validate your voice to welcome all our web mail account. To restore your account access, you must respond immediately Click on the Link Below to Upgrade Your Account Now with A New 10GB. This Link: http://verifyonline.ho6.com/ Thanks Admin Help Desk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Run make savedefconfig on omap2plus_defconfig to shrink it
On Thursday 10 October 2013 06:04 PM, Tony Lindgren wrote: -CONFIG_TI_DAVINCI_MDIO=y -CONFIG_TI_DAVINCI_CPDMA=y -CONFIG_TI_CPSW=y -CONFIG_AT803X_PHY=y Can you keep the above defines as AM335x EVM, Beagle bone, Beagle bone black can use ethernet with omap2plus_defconfig Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Run make savedefconfig on omap2plus_defconfig to shrink it
* Mugunthan V N mugunthan...@ti.com [131010 17:15]: On Thursday 10 October 2013 06:04 PM, Tony Lindgren wrote: -CONFIG_TI_DAVINCI_MDIO=y -CONFIG_TI_DAVINCI_CPDMA=y -CONFIG_TI_CPSW=y -CONFIG_AT803X_PHY=y Can you keep the above defines as AM335x EVM, Beagle bone, Beagle bone black can use ethernet with omap2plus_defconfig I think they should get automatically selected by default with make omap2plus_defconfig, I don't think make savedefconfig removes any selected features. Maybe check it though with this patch? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 10/10/13 21:58, Lars-Peter Clausen wrote: According to the datasheet the the panel as a dedicated dout pin. Maybe you did not connect it in your design, which means you won't be able to read any data from the panel at all. I don't see a dedicated dout in the datasheet... http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf Also your custom bitbang code looks a bit strange: gpio_set_value(data-dout_gpio, 1); if (gpio_get_value(data-din_gpio) == 0) return 1; You set the state on the dout pin and then read the din pin, if both do not match you abort with an error. This suggest that, for whatever reason, you feed the dout pin back into the din pin in your design. Btw. this is also the only place where din is used in your driver. Yes, he said the single Serial interface data input/output pin is connected to both din and dout on the SoC. I guess the purpose of that gpio_get_value() is to ensure that the panel is not pulling the line when the SoC is writing to it. Not that I really understand how that can work, but I'm not a HW guy =). Tomi signature.asc Description: OpenPGP digital signature
Re: linux-next: manual merge of the omap_dss2 tree
Hi Mark, Jean-Christophe, On 10/10/13 20:50, Mark Brown wrote: Today's linux-next merge of the omap_dss2 tree got conflicts in drivers/video/omap2/dss/hdmi4_core.[ch] caused by ef26958a (omapdss: HDMI: Rename hdmi driver files to nicer names) interacting with a range of commits from Ricardo Neri in the fbdev tree and possibly some other stuff. git is unfortunately not giving me a useful diff right now :/ Jean-Christophe has slightly different versions of my patches in his fbdev for-next branch, so they conflict with my updated versions. Jean-Christophe, I expected this to happen with the current way of you having a copy of my for-next branch in yours. Can I now take your atmel_lcdfb patches to my for-next, and you'll remove all patches from your for-next? Tomi signature.asc Description: OpenPGP digital signature
