Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT
On 11.09.2013 09:21, Tomi Valkeinen wrote: On 10/09/13 16:17, Tero Kristo wrote: In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) rate = parent_rate; else rate = parent_rate * 2; + return rate; } Stefan, are you able to test the above? I'd rather have a proper fix for this, than hack omapdss =). Okay, I finally found some time to test this. The patch above generates this warning: arch/arm/mach-omap2/dpll3xxx.c: In function 'omap3_clkoutx2_recalc': arch/arm/mach-omap2/dpll3xxx.c:663:6: warning: passing argument 1 of '__clk_get_rate' from incompatible pointer type [enabled by default] include/linux/clk-provider.h:423:15: note: expected 'struct clk *' but argument is of type 'struct clk_hw_omap *' I then changed it (not 100% sure if correctly) to this version: + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk-hw.clk)) And this seems to work. At least the clock rate mismatch warning does not appear with this patch applied (and without the clk_enable) in the bootlog any more. Thanks, Stefan -- 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/4] arm: omap: display: Create omapdrm inside omap_display_init
Move omapdrm device creation inside the omap_display_init so that we can
correctly create the device based on the presence of omapdss.
Originally worked on by Andy Gross.
Cc: Andy Gross andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/mach-omap2/Makefile | 4 ---
arch/arm/mach-omap2/display.c | 55 +++
arch/arm/mach-omap2/drm.c | 67 ---
3 files changed, 55 insertions(+), 71 deletions(-)
delete mode 100644 arch/arm/mach-omap2/drm.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ff2c162..f73b6a5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -229,10 +229,6 @@ endif
# OMAP2420 MSDI controller integration support (MMC)
obj-$(CONFIG_SOC_OMAP2420) += msdi.o
-ifneq ($(CONFIG_DRM_OMAP),)
-obj-y += drm.o
-endif
-
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 03a0516..d097d23 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -18,11 +18,13 @@
#include linux/string.h
#include linux/kernel.h
#include linux/init.h
+#include linux/dma-mapping.h
#include linux/platform_device.h
#include linux/io.h
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/platform_data/omap_drm.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -102,6 +104,52 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initconst = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+#if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data platform_drm_data;
+
+static struct platform_device drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = platform_drm_data,
+ },
+ .name = omapdrm,
+ .id = 0,
+};
+
+static struct platform_device *omap_drm_device = drm_device;
+#else
+static struct platform_device *omap_drm_device;
+#endif
+
+static int __init omapdrm_init(void)
+{
+ int r = 0;
+
+ /* create DRM and DMM device */
+ if (omap_drm_device != NULL) {
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+
*/
+ oh = omap_hwmod_lookup(dmm);
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0);
+ WARN(IS_ERR(pdev),
+ Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ platform_drm_data.omaprev = GET_OMAP_TYPE;
+
+ r = platform_device_register(omap_drm_device);
+ if (r 0)
+ pr_err(Unable to register omapdrm device\n);
+ }
+
+ return r;
+}
+
static void __init omap4_tpd12s015_mux_pads(void)
{
omap_mux_init_signal(hdmi_cec,
@@ -416,6 +464,13 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
}
}
+ /* create DRM and DMM device */
+ r = omapdrm_init();
+ if (r 0) {
+ pr_err(Unable to register omapdrm device\n);
+ return r;
+ }
+
return 0;
}
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
deleted file mode 100644
index 59a4af7..000
--- a/arch/arm/mach-omap2/drm.c
+++ /dev/null
@@ -1,67 +0,0 @@
-/*
- * DRM/KMS device registration for TI OMAP platforms
- *
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark rob.cl...@linaro.org
- *
- * 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/kernel.h
-#include linux/mm.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/dma-mapping.h
-#include linux/platform_data/omap_drm.h
-
-#include soc.h
-#include omap_device.h
-#include omap_hwmod.h
-
-#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
-
-static struct omap_drm_platform_data platform_data;
-
-static struct platform_device omap_drm_device = {
- .dev = {
- .coherent_dma_mask = DMA_BIT_MASK(32),
-
[PATCH 3/4] drm: omap: Enable DT support for DMM
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross.
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
[PATCH 4/4] arm: omap: display: Don't build device for DMM
DMM exists on omap4+ platforms, these platforms will always boot with DT. Remove
the previous method of searching the dmm hwmod and building the device by
ourselves. Addition of a DMM nodes in DT will ensure a DMM device is built.
For OMAP4, the address and irq data for most hwmods were removed, so the older
method doesn't work anyway.
Cc: Andy Gross andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/mach-omap2/display.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index d097d23..e0642bd 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -126,20 +126,8 @@ static int __init omapdrm_init(void)
{
int r = 0;
- /* create DRM and DMM device */
+ /* create DRM device(DMM device created via DT) */
if (omap_drm_device != NULL) {
- struct omap_hwmod *oh = NULL;
- struct platform_device *pdev;
-
- /* lookup and populate the DMM information, if present - OMAP4+
*/
- oh = omap_hwmod_lookup(dmm);
- if (oh) {
- pdev = omap_device_build(oh-name, -1, oh, NULL, 0);
- WARN(IS_ERR(pdev),
- Could not build omap_device for %s\n,
- oh-name);
- }
-
platform_drm_data.omaprev = GET_OMAP_TYPE;
r = platform_device_register(omap_drm_device);
@@ -464,7 +452,7 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
}
}
- /* create DRM and DMM device */
+ /* create DRM device */
r = omapdrm_init();
if (r 0) {
pr_err(Unable to register omapdrm device\n);
--
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 2/4] 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.
Cc: Andy Gross andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
Documentation/devicetree/bindings/arm/omap/dmm.txt | 17 +
arch/arm/boot/dts/omap4.dtsi | 7 +++
arch/arm/boot/dts/omap5.dtsi | 7 +++
3 files changed, 31 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..237cd83
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,17 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+Required properties:
+- compatible: Must be ti,omap4-dmm for OMAP4 family
+ Must be ti,omap5-dmm for OMAP5 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 the counter, which is typically
+ dmm
+
+Example:
+
+dmm: 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..24f388e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -487,6 +487,13 @@
ti,hwmods = kbd;
};
+ dmm: 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 ac1f1e0..33b4fea 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,6 +604,13 @@
ti,hwmods = wd_timer2;
};
+ dmm: 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 0/4] arm: omap: 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. Also, make sure DRM device is built only when omapdss device is built. Currently, it can register itself even without the presence of omapdss device being built. Archit Taneja (4): arm: omap: display: Create omapdrm inside omap_display_init ARM: dts: OMAP4+: Add DMM bindings drm: omap: Enable DT support for DMM arm: omap: display: Don't build device for DMM Documentation/devicetree/bindings/arm/omap/dmm.txt | 17 ++ arch/arm/boot/dts/omap4.dtsi | 7 +++ arch/arm/boot/dts/omap5.dtsi | 7 +++ arch/arm/mach-omap2/Makefile | 4 -- arch/arm/mach-omap2/display.c | 43 ++ arch/arm/mach-omap2/drm.c | 67 -- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 7 files changed, 85 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt delete mode 100644 arch/arm/mach-omap2/drm.c -- 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: [PATCH v4 0/2] ARM: dts: Beaglebone MMC fixes
Op 13 sep. 2013, om 00:27 heeft Kevin Hilman khil...@linaro.org het volgende geschreven: Koen Kooi k...@dominion.thruhere.net writes: Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline FWIW, tested this branch on BB black/white with MMC rootfs. Tested-by: Kevin Hilman khil...@linaro.org Koen, Thanks for your persistence getting this stuff merged. No problem, with all comments addressed I can safely disappear for 3 weeks to go on honeymoon :) regards, Koen-- 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/4] arm: omap: display: Create omapdrm inside omap_display_init
On 13/09/13 12:14, Archit Taneja wrote: Move omapdrm device creation inside the omap_display_init so that we can correctly create the device based on the presence of omapdss. Originally worked on by Andy Gross. If the dmm device is present in the DT data, there is no need to create the dmm device. It's created automatically. Also, omapfb device is currently created the same way as omapdrm, independently of omapdss. Why is it a problem to have them like that? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/4] arm: omap: display: Don't build device for DMM
On 13/09/13 12:14, Archit Taneja wrote:
DMM exists on omap4+ platforms, these platforms will always boot with DT.
Remove
the previous method of searching the dmm hwmod and building the device by
ourselves. Addition of a DMM nodes in DT will ensure a DMM device is built.
For OMAP4, the address and irq data for most hwmods were removed, so the older
method doesn't work anyway.
Cc: Andy Gross andy...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/mach-omap2/display.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index d097d23..e0642bd 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -126,20 +126,8 @@ static int __init omapdrm_init(void)
{
int r = 0;
- /* create DRM and DMM device */
+ /* create DRM device(DMM device created via DT) */
if (omap_drm_device != NULL) {
- struct omap_hwmod *oh = NULL;
- struct platform_device *pdev;
-
- /* lookup and populate the DMM information, if present - OMAP4+
*/
- oh = omap_hwmod_lookup(dmm);
- if (oh) {
- pdev = omap_device_build(oh-name, -1, oh, NULL, 0);
- WARN(IS_ERR(pdev),
- Could not build omap_device for %s\n,
- oh-name);
- }
-
platform_drm_data.omaprev = GET_OMAP_TYPE;
Ok, so you remove the DMM device creation here. Why not do this as a
first patch, before moving the DMM/DRM code?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/4] arm: omap: display: Create omapdrm inside omap_display_init
On Friday 13 September 2013 02:54 PM, Tomi Valkeinen wrote: On 13/09/13 12:14, Archit Taneja wrote: Move omapdrm device creation inside the omap_display_init so that we can correctly create the device based on the presence of omapdss. Originally worked on by Andy Gross. If the dmm device is present in the DT data, there is no need to create the dmm device. It's created automatically. Yes, that is done in a later patch. Also, omapfb device is currently created the same way as omapdrm, independently of omapdss. Why is it a problem to have them like that? In a multiplatform config, we might have CONFIG_DRM_OMAP and CONFIG_DRM_OMAP_MODULE selected. This would cause the call omap_init_drm() in arch/arm/mach-omap2/drm.c to occur. Creating a platform device for omapdrm is unnecessary here isn't it? Tying it with the initialisation of omapdss devices prevents it. 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
Re: [PATCH 1/4] arm: omap: display: Create omapdrm inside omap_display_init
On Friday 13 September 2013 03:08 PM, Archit Taneja wrote: On Friday 13 September 2013 02:54 PM, Tomi Valkeinen wrote: On 13/09/13 12:14, Archit Taneja wrote: Move omapdrm device creation inside the omap_display_init so that we can correctly create the device based on the presence of omapdss. Originally worked on by Andy Gross. If the dmm device is present in the DT data, there is no need to create the dmm device. It's created automatically. Yes, that is done in a later patch. Also, omapfb device is currently created the same way as omapdrm, independently of omapdss. Why is it a problem to have them like that? In a multiplatform config, we might have CONFIG_DRM_OMAP and CONFIG_DRM_OMAP_MODULE selected. I meant these configs might be selected even if the image is booted on am3xx platform. Archit This would cause the call omap_init_drm() in arch/arm/mach-omap2/drm.c to occur. Creating a platform device for omapdrm is unnecessary here isn't it? Tying it with the initialisation of omapdss devices prevents it. 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 -- 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/4] arm: omap: display: Create omapdrm inside omap_display_init
On 13/09/13 12:38, Archit Taneja wrote: Also, omapfb device is currently created the same way as omapdrm, independently of omapdss. Why is it a problem to have them like that? In a multiplatform config, we might have CONFIG_DRM_OMAP and CONFIG_DRM_OMAP_MODULE selected. This would cause the call omap_init_drm() in arch/arm/mach-omap2/drm.c to occur. Creating a platform device for omapdrm is unnecessary here isn't it? Tying it with the initialisation of omapdss devices prevents it. Well, omapdrm depends on omapdss in Kconfig. So if you have DRM enabled, you also have DSS enabled. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] arm: omap: display: Create omapdrm inside omap_display_init
On 13/09/13 12:39, Archit Taneja wrote: On Friday 13 September 2013 03:08 PM, Archit Taneja wrote: On Friday 13 September 2013 02:54 PM, Tomi Valkeinen wrote: On 13/09/13 12:14, Archit Taneja wrote: Move omapdrm device creation inside the omap_display_init so that we can correctly create the device based on the presence of omapdss. Originally worked on by Andy Gross. If the dmm device is present in the DT data, there is no need to create the dmm device. It's created automatically. Yes, that is done in a later patch. Also, omapfb device is currently created the same way as omapdrm, independently of omapdss. Why is it a problem to have them like that? In a multiplatform config, we might have CONFIG_DRM_OMAP and CONFIG_DRM_OMAP_MODULE selected. I meant these configs might be selected even if the image is booted on am3xx platform. Ah, I see. And the same omap_arch_initcall() is used for am3xxx also, even if the DSS (and thus DRM) doesn't exist in the HW. We have the same problem with omapfb, so it'd be good to include that in the same series. Hmm. If omap_generic_init() is called on am3xxx, it means we try to create the dss stuff there also. It should fail to the DSS version check, printing an error (at least I hope), but we really shouldn't even call the dss init code on am3xxx. I wonder how this should be fixed... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] arm: omap: display: Create omapdrm inside omap_display_init
On Friday 13 September 2013 03:18 PM, Tomi Valkeinen wrote: On 13/09/13 12:39, Archit Taneja wrote: On Friday 13 September 2013 03:08 PM, Archit Taneja wrote: On Friday 13 September 2013 02:54 PM, Tomi Valkeinen wrote: On 13/09/13 12:14, Archit Taneja wrote: Move omapdrm device creation inside the omap_display_init so that we can correctly create the device based on the presence of omapdss. Originally worked on by Andy Gross. If the dmm device is present in the DT data, there is no need to create the dmm device. It's created automatically. Yes, that is done in a later patch. Also, omapfb device is currently created the same way as omapdrm, independently of omapdss. Why is it a problem to have them like that? In a multiplatform config, we might have CONFIG_DRM_OMAP and CONFIG_DRM_OMAP_MODULE selected. I meant these configs might be selected even if the image is booted on am3xx platform. Ah, I see. And the same omap_arch_initcall() is used for am3xxx also, even if the DSS (and thus DRM) doesn't exist in the HW. We have the same problem with omapfb, so it'd be good to include that in the same series. Hmm. If omap_generic_init() is called on am3xxx, it means we try to create the dss stuff there also. It should fail to the DSS version check, printing an error (at least I hope), but we really shouldn't even call the dss init code on am3xxx. I wonder how this should be fixed... The calls in omap_generic_init() check the machine type via of_machine_is_compatible(), even if it's a multiplatform image, the dtb should be only of one platform. So it wouldn't be called at all. 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
Re: [PATCH 1/4] arm: omap: display: Create omapdrm inside omap_display_init
On 13/09/13 12:51, Archit Taneja wrote: The calls in omap_generic_init() check the machine type via of_machine_is_compatible(), even if it's a multiplatform image, the dtb should be only of one platform. So it wouldn't be called at all. Hmm. BeagleBone is ti,am33xx. The Generic AM33XX (Flattened Device Tree) machine definition uses omap_generic_init(). So if I'm not missing something here, omap_generic_init() is called for BeagleBone. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 0/3] mmc: omap_hsmmc: get rid of ti,non-removable
Get rid of TI specific binding ti,non-removable in favour of the generic binding present for the same purpose. This patch set does not support the old binding anymore. So, yes, it does introduce an ABI breakage. IMHO, it is not really worth supporting both bindings ATM since DT-usage in OMAP is still very nascent and almost always DTB and uImage are upgraded together. The series applies to Koen's series titled ARM: dts: Beaglebone MMC fixes The patch set is tested on Bone Black, but I could not get the eMMC to detect on my board with or without this patch set. The removable MMC/SD works though. Sekhar Nori (3): mmc: omap_hsmmc: remove TI specific DT binding for non removable cards ARM: OMAP2+: DT: start using generic binding for non-removable mmc cards ARM: OMAP2+: BBB DT: mark eMMC as non removable Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |5 ++--- arch/arm/boot/dts/am335x-boneblack.dts |1 + arch/arm/boot/dts/omap4-panda-common.dtsi |2 +- arch/arm/boot/dts/omap4-sdp.dts |4 ++-- arch/arm/boot/dts/omap4-var-som.dts |2 +- arch/arm/boot/dts/omap5-uevm.dts|4 ++-- drivers/mmc/host/omap_hsmmc.c |2 +- 7 files changed, 10 insertions(+), 10 deletions(-) -- 1.7.10.1 -- 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/3] mmc: omap_hsmmc: remove TI specific DT binding for non removable cards
Remove the vendor specific ti,non-removable DT binding and
support the generic binding non-removable instead.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |5 ++---
drivers/mmc/host/omap_hsmmc.c |2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..0d463b8 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -17,7 +17,6 @@ Optional properties:
ti,dual-volt: boolean, supports dual voltage cards
supply-name-supply: phandle to the regulator device tree node
supply-name examples are vmmc, vmmc_aux etc
-ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
dmas: List of DMA specifiers with the controller specific format
@@ -38,7 +37,7 @@ Examples:
ti,dual-volt;
bus-width = 4;
vmmc-supply = vmmc; /* phandle to regulator node */
- ti,non-removable;
+ non-removable;
};
[generic DMA request binding]
@@ -50,7 +49,7 @@ Examples:
ti,dual-volt;
bus-width = 4;
vmmc-supply = vmmc; /* phandle to regulator node */
- ti,non-removable;
+ non-removable;
dmas = edma 24
edma 25;
dma-names = tx, rx;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6ac63df..0cb06ff 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1738,7 +1738,7 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
pdata-slots[0].switch_pin = cd_gpio;
pdata-slots[0].gpio_wp = wp_gpio;
- if (of_find_property(np, ti,non-removable, NULL)) {
+ if (of_find_property(np, non-removable, NULL)) {
pdata-slots[0].nonremovable = true;
pdata-slots[0].no_regulator_off_init = true;
}
--
1.7.10.1
--
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/3] ARM: OMAP2+: BBB DT: mark eMMC as non removable
Mark the eMMC module on BeagleBone black as non removable. Signed-off-by: Sekhar Nori nsek...@ti.com --- arch/arm/boot/dts/am335x-boneblack.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts index f4703cf..58515dc 100644 --- a/arch/arm/boot/dts/am335x-boneblack.dts +++ b/arch/arm/boot/dts/am335x-boneblack.dts @@ -25,6 +25,7 @@ pinctrl-names = default; pinctrl-0 = emmc_pins; bus-width = 8; + non-removable; status = okay; ti,vcc-aux-disable-is-sleep; }; -- 1.7.10.1 -- 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/3] ARM: OMAP2+: DT: start using generic binding for non-removable mmc cards
The TI specific binding for non-removable cards is now gone.
The driver supports the generic binding, start using it.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi |2 +-
arch/arm/boot/dts/omap4-sdp.dts |4 ++--
arch/arm/boot/dts/omap4-var-som.dts |2 +-
arch/arm/boot/dts/omap5-uevm.dts |4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..8dcefc0 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -314,7 +314,7 @@
};
mmc5 {
- ti,non-removable;
+ non-removable;
bus-width = 4;
};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..ecce3f5 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -408,7 +408,7 @@
mmc2 {
vmmc-supply = vaux1;
bus-width = 8;
- ti,non-removable;
+ non-removable;
};
mmc3 {
@@ -421,7 +421,7 @@
mmc5 {
bus-width = 4;
- ti,non-removable;
+ non-removable;
};
emif1 {
diff --git a/arch/arm/boot/dts/omap4-var-som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
index b41269e..b25b9ad 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -76,7 +76,7 @@
mmc1 {
vmmc-supply = vmmc;
ti,bus-width = 8;
- ti,non-removable;
+ non-removable;
};
mmc2 {
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..67d6ed7 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -242,12 +242,12 @@
mmc2 {
vmmc-supply = vmmcsd_fixed;
bus-width = 8;
- ti,non-removable;
+ non-removable;
};
mmc3 {
bus-width = 4;
- ti,non-removable;
+ non-removable;
};
mmc4 {
--
1.7.10.1
--
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 3/3] ARM: OMAP2+: BBB DT: mark eMMC as non removable
Op 13 sep. 2013, om 12:09 heeft Sekhar Nori nsek...@ti.com het volgende geschreven: Mark the eMMC module on BeagleBone black as non removable. Signed-off-by: Sekhar Nori nsek...@ti.com Acked-by: Koen Kooi k...@dominion.thruhere.net --- arch/arm/boot/dts/am335x-boneblack.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts index f4703cf..58515dc 100644 --- a/arch/arm/boot/dts/am335x-boneblack.dts +++ b/arch/arm/boot/dts/am335x-boneblack.dts @@ -25,6 +25,7 @@ pinctrl-names = default; pinctrl-0 = emmc_pins; bus-width = 8; + non-removable; status = okay; ti,vcc-aux-disable-is-sleep; }; -- 1.7.10.1 -- 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/4] arm: omap: display: Create omapdrm inside omap_display_init
On Friday 13 September 2013 03:32 PM, Tomi Valkeinen wrote:
On 13/09/13 12:51, Archit Taneja wrote:
The calls in omap_generic_init() check the machine type via
of_machine_is_compatible(), even if it's a multiplatform image, the dtb
should be only of one platform. So it wouldn't be called at all.
Hmm. BeagleBone is ti,am33xx. The Generic AM33XX (Flattened Device
Tree) machine definition uses omap_generic_init(). So if I'm not
missing something here, omap_generic_init() is called for BeagleBone.
I was talking about the calls within omap_generic_init() :
omap_generic_init(void)
{
...
if (of_machine_is_compatible(ti,omap4-panda)) {
omap4_panda_display_init_of();
legacy_init_ehci_clk(auxclk3_ck);
}
}
omap4_panda_display_init_of() would be called only if a panda board dtb
was used. Are you talking about these display calls, or something else?
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
Re: [PATCH 1/4] arm: omap: display: Create omapdrm inside omap_display_init
On 13/09/13 13:17, Archit Taneja wrote:
On Friday 13 September 2013 03:32 PM, Tomi Valkeinen wrote:
On 13/09/13 12:51, Archit Taneja wrote:
The calls in omap_generic_init() check the machine type via
of_machine_is_compatible(), even if it's a multiplatform image, the dtb
should be only of one platform. So it wouldn't be called at all.
Hmm. BeagleBone is ti,am33xx. The Generic AM33XX (Flattened Device
Tree) machine definition uses omap_generic_init(). So if I'm not
missing something here, omap_generic_init() is called for BeagleBone.
I was talking about the calls within omap_generic_init() :
omap_generic_init(void)
{
...
if (of_machine_is_compatible(ti,omap4-panda)) {
omap4_panda_display_init_of();
legacy_init_ehci_clk(auxclk3_ck);
}
}
omap4_panda_display_init_of() would be called only if a panda board dtb
was used. Are you talking about these display calls, or something else?
Ah, right. I was looking at the DSS DT branch. There we have
omapdss_init_of() call from omap_generic_init(). So that is a problem,
but not in the mainline.
You're right, the current mainline doesn't call the DSS init function on
am33xx. But it does create omapfb and omapdrm devices, as you noted.
Well, those devices don't do any actual harm, but I agree that they
shouldn't be there. It's probably best to move the device creation into
display.c, as you did. Just include omapfb also, and maybe remove the
DMM creation as a first patch.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH 0/7] omapdss: HDMI: Fix register definitions and reg dump functions
These patches complete the OMAP4 HDMI register definitions for HDMI submodules and make sure all the corresponding regdump functions dump all the registers. Ricardo Neri (7): OMAPDSS: HDMI: OMAP4: Complete register definitions for wrapper OMAPDSS: HDMI: OMAP4: Complete dumping of wrapper registers OMAPDSS: HDMI: OMAP4: Complete register definitions for DPLL OMAPDSS: HDMI: OMAP4: Complete dumping of DPLL registers OMAPDSS: HDMI: OMAP4: Rename the HDMI_CORE_CTRL1 register OMAPDSS: HDMI: OMAP4: Complete register definitions for core OMAPDSS: HDMI: OMAP4: Complete dumping of core registers drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 70 ++- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 65 2 files changed, 118 insertions(+), 17 deletions(-) -- 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 1/7] OMAPDSS: HDMI: OMAP4: Complete register definitions for wrapper
From: Ricardo Neri ricardo.n...@ti.com Add definitions for missing registers in the HDMI wrapper. Also, order the registers by offset to improve readability. Signed-off-by: Ricardo Neri ricardo.n...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h index 6ef2f92..469d436 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h @@ -31,9 +31,11 @@ #define HDMI_WP_SYSCONFIG 0x10 #define HDMI_WP_IRQSTATUS_RAW 0x24 #define HDMI_WP_IRQSTATUS 0x28 -#define HDMI_WP_PWR_CTRL 0x40 #define HDMI_WP_IRQENABLE_SET 0x2C #define HDMI_WP_IRQENABLE_CLR 0x30 +#define HDMI_WP_IRQWAKEEN 0x34 +#define HDMI_WP_PWR_CTRL 0x40 +#define HDMI_WP_DEBOUNCE 0x44 #define HDMI_WP_VIDEO_CFG 0x50 #define HDMI_WP_VIDEO_SIZE 0x60 #define HDMI_WP_VIDEO_TIMING_H 0x68 -- 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 2/7] OMAPDSS: HDMI: OMAP4: Complete dumping of wrapper registers
From: Ricardo Neri ricardo.n...@ti.com Add missing registers when dumping the HDMI wrapper. Also, order the dump by offset to improve readability. Signed-off-by: Ricardo Neri ricardo.n...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c index 3dfe009..ecadd7a 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c @@ -859,8 +859,11 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPREG(HDMI_WP_SYSCONFIG); DUMPREG(HDMI_WP_IRQSTATUS_RAW); DUMPREG(HDMI_WP_IRQSTATUS); - DUMPREG(HDMI_WP_PWR_CTRL); DUMPREG(HDMI_WP_IRQENABLE_SET); + DUMPREG(HDMI_WP_IRQENABLE_CLR); + DUMPREG(HDMI_WP_IRQWAKEEN); + DUMPREG(HDMI_WP_PWR_CTRL); + DUMPREG(HDMI_WP_DEBOUNCE); DUMPREG(HDMI_WP_VIDEO_CFG); DUMPREG(HDMI_WP_VIDEO_SIZE); DUMPREG(HDMI_WP_VIDEO_TIMING_H); -- 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 5/7] OMAPDSS: HDMI: OMAP4: Rename the HDMI_CORE_CTRL1 register
From: Ricardo Neri ricardo.n...@ti.com
Rename the register to be aligned with the HDMI_CORE_SYS naming convention.
Also, update the naming of the #defines used for its fields.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 16
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 11 ++-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 46af726..ad5b820 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -527,7 +527,7 @@ static void hdmi_core_init(struct hdmi_core_video_config
*video_cfg,
static void hdmi_core_powerdown_disable(struct hdmi_ip_data *ip_data)
{
pr_debug(Enter hdmi_core_powerdown_disable\n);
- REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, 0x0, 0, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SYS_CTRL1, 0x0,
0, 0);
}
static void hdmi_core_swreset_release(struct hdmi_ip_data *ip_data)
@@ -550,12 +550,12 @@ static void hdmi_core_video_config(struct hdmi_ip_data
*ip_data,
void __iomem *core_sys_base = hdmi_core_sys_base(ip_data);
/* sys_ctrl1 default configuration not tunable */
- r = hdmi_read_reg(core_sys_base, HDMI_CORE_CTRL1);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC, 5, 5);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC, 4, 4);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_BSEL_24BITBUS, 2, 2);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_EDGE_RISINGEDGE, 1, 1);
- hdmi_write_reg(core_sys_base, HDMI_CORE_CTRL1, r);
+ r = hdmi_read_reg(core_sys_base, HDMI_CORE_SYS_SYS_CTRL1);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_VEN_FOLLOWVSYNC, 5, 5);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_HEN_FOLLOWHSYNC, 4, 4);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_BSEL_24BITBUS, 2, 2);
+ r = FLD_MOD(r, HDMI_CORE_SYS_SYS_CTRL1_EDGE_RISINGEDGE, 1, 1);
+ hdmi_write_reg(core_sys_base, HDMI_CORE_SYS_SYS_CTRL1, r);
REG_FLD_MOD(core_sys_base,
HDMI_CORE_SYS_VID_ACEN, cfg-ip_bus_width, 7, 6);
@@ -909,7 +909,7 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s)
DUMPCORE(HDMI_CORE_SYS_DEV_IDH);
DUMPCORE(HDMI_CORE_SYS_DEV_REV);
DUMPCORE(HDMI_CORE_SYS_SRST);
- DUMPCORE(HDMI_CORE_CTRL1);
+ DUMPCORE(HDMI_CORE_SYS_SYS_CTRL1);
DUMPCORE(HDMI_CORE_SYS_SYS_STAT);
DUMPCORE(HDMI_CORE_SYS_DE_DLY);
DUMPCORE(HDMI_CORE_SYS_DE_CTRL);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index d1a2315..149abd8 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -53,7 +53,7 @@
#define HDMI_CORE_SYS_DEV_IDH 0xC
#define HDMI_CORE_SYS_DEV_REV 0x10
#define HDMI_CORE_SYS_SRST 0x14
-#define HDMI_CORE_CTRL10x20
+#define HDMI_CORE_SYS_SYS_CTRL10x20
#define HDMI_CORE_SYS_SYS_STAT 0x24
#define HDMI_CORE_SYS_DE_DLY 0xC8
#define HDMI_CORE_SYS_DE_CTRL 0xCC
@@ -72,10 +72,11 @@
#define HDMI_CORE_SYS_UMASK1 0x1D4
#define HDMI_CORE_SYS_TMDS_CTRL0x208
-#define HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC0x1
-#define HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC0x1
-#define HDMI_CORE_CTRL1_BSEL_24BITBUS 0x1
-#define HDMI_CORE_CTRL1_EDGE_RISINGEDGE0x1
+/* value definitions for HDMI_CORE_SYS_SYS_CTRL1 fields */
+#define HDMI_CORE_SYS_SYS_CTRL1_VEN_FOLLOWVSYNC0x1
+#define HDMI_CORE_SYS_SYS_CTRL1_HEN_FOLLOWHSYNC0x1
+#define HDMI_CORE_SYS_SYS_CTRL1_BSEL_24BITBUS 0x1
+#define HDMI_CORE_SYS_SYS_CTRL1_EDGE_RISINGEDGE0x1
/* HDMI DDC E-DID */
#define HDMI_CORE_DDC_ADDR 0x3B4
--
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 4/7] OMAPDSS: HDMI: OMAP4: Complete dumping of DPLL registers
From: Ricardo Neri ricardo.n...@ti.com Add the spread spectrum clock configuration registers to the DPLL dump. Signed-off-by: Ricardo Neri ricardo.n...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c index ecadd7a..46af726 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c @@ -886,6 +886,8 @@ void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPPLL(PLLCTRL_CFG1); DUMPPLL(PLLCTRL_CFG2); DUMPPLL(PLLCTRL_CFG3); + DUMPPLL(PLLCTRL_SSC_CFG1); + DUMPPLL(PLLCTRL_SSC_CFG2); DUMPPLL(PLLCTRL_CFG4); } -- 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 3/7] OMAPDSS: HDMI: OMAP4: Complete register definitions for DPLL
From: Ricardo Neri ricardo.n...@ti.com Add missing register definitions for spread spectrum clocking. Signed-off-by: Ricardo Neri ricardo.n...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h index 469d436..d1a2315 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h @@ -168,6 +168,8 @@ #define PLLCTRL_CFG1 0xC #define PLLCTRL_CFG2 0x10 #define PLLCTRL_CFG3 0x14 +#define PLLCTRL_SSC_CFG1 0x18 +#define PLLCTRL_SSC_CFG2 0x1C #define PLLCTRL_CFG4 0x20 /* HDMI PHY */ -- 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 7/7] OMAPDSS: HDMI: OMAP4: Complete dumping of core registers
From: Ricardo Neri ricardo.n...@ti.com Add missing register entries when dumping the core. Signed-off-by: Ricardo Neri ricardo.n...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 47 ++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c index ad5b820..fd4172b 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c @@ -911,6 +911,7 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPCORE(HDMI_CORE_SYS_SRST); DUMPCORE(HDMI_CORE_SYS_SYS_CTRL1); DUMPCORE(HDMI_CORE_SYS_SYS_STAT); + DUMPCORE(HDMI_CORE_SYS_SYS_CTRL3); DUMPCORE(HDMI_CORE_SYS_DE_DLY); DUMPCORE(HDMI_CORE_SYS_DE_CTRL); DUMPCORE(HDMI_CORE_SYS_DE_TOP); @@ -918,14 +919,58 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s) DUMPCORE(HDMI_CORE_SYS_DE_CNTH); DUMPCORE(HDMI_CORE_SYS_DE_LINL); DUMPCORE(HDMI_CORE_SYS_DE_LINH_1); + DUMPCORE(HDMI_CORE_SYS_HRES_L); + DUMPCORE(HDMI_CORE_SYS_HRES_H); + DUMPCORE(HDMI_CORE_SYS_VRES_L); + DUMPCORE(HDMI_CORE_SYS_VRES_H); + DUMPCORE(HDMI_CORE_SYS_IADJUST); + DUMPCORE(HDMI_CORE_SYS_POLDETECT); + DUMPCORE(HDMI_CORE_SYS_HWIDTH1); + DUMPCORE(HDMI_CORE_SYS_HWIDTH2); + DUMPCORE(HDMI_CORE_SYS_VWIDTH); + DUMPCORE(HDMI_CORE_SYS_VID_CTRL); DUMPCORE(HDMI_CORE_SYS_VID_ACEN); DUMPCORE(HDMI_CORE_SYS_VID_MODE); + DUMPCORE(HDMI_CORE_SYS_VID_BLANK1); + DUMPCORE(HDMI_CORE_SYS_VID_BLANK3); + DUMPCORE(HDMI_CORE_SYS_VID_BLANK1); + DUMPCORE(HDMI_CORE_SYS_DC_HEADER); + DUMPCORE(HDMI_CORE_SYS_VID_DITHER); + DUMPCORE(HDMI_CORE_SYS_RGB2XVYCC_CT); + DUMPCORE(HDMI_CORE_SYS_R2Y_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_R2Y_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_G2Y_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_G2Y_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_B2Y_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_B2Y_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_R2CB_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_R2CB_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_G2CB_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_G2CB_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_B2CB_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_B2CB_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_R2CR_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_R2CR_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_G2CR_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_G2CR_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_B2CR_COEFF_LOW); + DUMPCORE(HDMI_CORE_SYS_B2CR_COEFF_UP); + DUMPCORE(HDMI_CORE_SYS_RGB_OFFSET_LOW); + DUMPCORE(HDMI_CORE_SYS_RGB_OFFSET_UP); + DUMPCORE(HDMI_CORE_SYS_Y_OFFSET_LOW); + DUMPCORE(HDMI_CORE_SYS_Y_OFFSET_UP); + DUMPCORE(HDMI_CORE_SYS_CBCR_OFFSET_LOW); + DUMPCORE(HDMI_CORE_SYS_CBCR_OFFSET_UP); DUMPCORE(HDMI_CORE_SYS_INTR_STATE); DUMPCORE(HDMI_CORE_SYS_INTR1); DUMPCORE(HDMI_CORE_SYS_INTR2); DUMPCORE(HDMI_CORE_SYS_INTR3); DUMPCORE(HDMI_CORE_SYS_INTR4); - DUMPCORE(HDMI_CORE_SYS_UMASK1); + DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK1); + DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK2); + DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK3); + DUMPCORE(HDMI_CORE_SYS_INTR_UNMASK4); + DUMPCORE(HDMI_CORE_SYS_INTR_CTRL); DUMPCORE(HDMI_CORE_SYS_TMDS_CTRL); DUMPCORE(HDMI_CORE_DDC_ADDR); -- 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 6/7] OMAPDSS: HDMI: OMAP4: Complete register definitions for core
From: Ricardo Neri ricardo.n...@ti.com Add missing register definitions; mainly for colorspace conversion, video timing and interrupt handling. Signed-off-by: Ricardo Neri ricardo.n...@ti.com Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 48 ++- 1 file changed, 47 insertions(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h index 149abd8..b25269c 100644 --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h @@ -55,6 +55,8 @@ #define HDMI_CORE_SYS_SRST 0x14 #define HDMI_CORE_SYS_SYS_CTRL10x20 #define HDMI_CORE_SYS_SYS_STAT 0x24 +#define HDMI_CORE_SYS_SYS_CTRL30x28 +#define HDMI_CORE_SYS_DCTL 0x34 #define HDMI_CORE_SYS_DE_DLY 0xC8 #define HDMI_CORE_SYS_DE_CTRL 0xCC #define HDMI_CORE_SYS_DE_TOP 0xD0 @@ -62,14 +64,58 @@ #define HDMI_CORE_SYS_DE_CNTH 0xDC #define HDMI_CORE_SYS_DE_LINL 0xE0 #define HDMI_CORE_SYS_DE_LINH_10xE4 +#define HDMI_CORE_SYS_HRES_L 0xE8 +#define HDMI_CORE_SYS_HRES_H 0xEC +#define HDMI_CORE_SYS_VRES_L 0xF0 +#define HDMI_CORE_SYS_VRES_H 0xF4 +#define HDMI_CORE_SYS_IADJUST 0xF8 +#define HDMI_CORE_SYS_POLDETECT0xFC +#define HDMI_CORE_SYS_HWIDTH1 0x110 +#define HDMI_CORE_SYS_HWIDTH2 0x114 +#define HDMI_CORE_SYS_VWIDTH 0x11C +#define HDMI_CORE_SYS_VID_CTRL 0x120 #define HDMI_CORE_SYS_VID_ACEN 0x124 #define HDMI_CORE_SYS_VID_MODE 0x128 +#define HDMI_CORE_SYS_VID_BLANK1 0x12C +#define HDMI_CORE_SYS_VID_BLANK2 0x130 +#define HDMI_CORE_SYS_VID_BLANK3 0x134 +#define HDMI_CORE_SYS_DC_HEADER0x138 +#define HDMI_CORE_SYS_VID_DITHER 0x13C +#define HDMI_CORE_SYS_RGB2XVYCC_CT 0x140 +#define HDMI_CORE_SYS_R2Y_COEFF_LOW0x144 +#define HDMI_CORE_SYS_R2Y_COEFF_UP 0x148 +#define HDMI_CORE_SYS_G2Y_COEFF_LOW0x14C +#define HDMI_CORE_SYS_G2Y_COEFF_UP 0x150 +#define HDMI_CORE_SYS_B2Y_COEFF_LOW0x154 +#define HDMI_CORE_SYS_B2Y_COEFF_UP 0x158 +#define HDMI_CORE_SYS_R2CB_COEFF_LOW 0x15C +#define HDMI_CORE_SYS_R2CB_COEFF_UP0x160 +#define HDMI_CORE_SYS_G2CB_COEFF_LOW 0x164 +#define HDMI_CORE_SYS_G2CB_COEFF_UP0x168 +#define HDMI_CORE_SYS_B2CB_COEFF_LOW 0x16C +#define HDMI_CORE_SYS_B2CB_COEFF_UP0x170 +#define HDMI_CORE_SYS_R2CR_COEFF_LOW 0x174 +#define HDMI_CORE_SYS_R2CR_COEFF_UP0x178 +#define HDMI_CORE_SYS_G2CR_COEFF_LOW 0x17C +#define HDMI_CORE_SYS_G2CR_COEFF_UP0x180 +#define HDMI_CORE_SYS_B2CR_COEFF_LOW 0x184 +#define HDMI_CORE_SYS_B2CR_COEFF_UP0x188 +#define HDMI_CORE_SYS_RGB_OFFSET_LOW 0x18C +#define HDMI_CORE_SYS_RGB_OFFSET_UP0x190 +#define HDMI_CORE_SYS_Y_OFFSET_LOW 0x194 +#define HDMI_CORE_SYS_Y_OFFSET_UP 0x198 +#define HDMI_CORE_SYS_CBCR_OFFSET_LOW 0x19C +#define HDMI_CORE_SYS_CBCR_OFFSET_UP 0x1A0 #define HDMI_CORE_SYS_INTR_STATE 0x1C0 #define HDMI_CORE_SYS_INTR10x1C4 #define HDMI_CORE_SYS_INTR20x1C8 #define HDMI_CORE_SYS_INTR30x1CC #define HDMI_CORE_SYS_INTR40x1D0 -#define HDMI_CORE_SYS_UMASK1 0x1D4 +#define HDMI_CORE_SYS_INTR_UNMASK1 0x1D4 +#define HDMI_CORE_SYS_INTR_UNMASK2 0x1D8 +#define HDMI_CORE_SYS_INTR_UNMASK3 0x1DC +#define HDMI_CORE_SYS_INTR_UNMASK4 0x1E0 +#define HDMI_CORE_SYS_INTR_CTRL0x1E4 #define HDMI_CORE_SYS_TMDS_CTRL0x208 /* value definitions for HDMI_CORE_SYS_SYS_CTRL1 fields */ -- 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: [PATCH 1/4] arm: omap: display: Create omapdrm inside omap_display_init
On Friday 13 September 2013 03:54 PM, Tomi Valkeinen wrote:
On 13/09/13 13:17, Archit Taneja wrote:
On Friday 13 September 2013 03:32 PM, Tomi Valkeinen wrote:
On 13/09/13 12:51, Archit Taneja wrote:
The calls in omap_generic_init() check the machine type via
of_machine_is_compatible(), even if it's a multiplatform image, the dtb
should be only of one platform. So it wouldn't be called at all.
Hmm. BeagleBone is ti,am33xx. The Generic AM33XX (Flattened Device
Tree) machine definition uses omap_generic_init(). So if I'm not
missing something here, omap_generic_init() is called for BeagleBone.
I was talking about the calls within omap_generic_init() :
omap_generic_init(void)
{
...
if (of_machine_is_compatible(ti,omap4-panda)) {
omap4_panda_display_init_of();
legacy_init_ehci_clk(auxclk3_ck);
}
}
omap4_panda_display_init_of() would be called only if a panda board dtb
was used. Are you talking about these display calls, or something else?
Ah, right. I was looking at the DSS DT branch. There we have
omapdss_init_of() call from omap_generic_init(). So that is a problem,
but not in the mainline.
You're right, the current mainline doesn't call the DSS init function on
am33xx. But it does create omapfb and omapdrm devices, as you noted.
Well, those devices don't do any actual harm, but I agree that they
shouldn't be there. It's probably best to move the device creation into
display.c, as you did. Just include omapfb also, and maybe remove the
DMM creation as a first patch.
Sure, I'll do that.
I'm not sure either about how to deal with the direct call to
omapdss_init_of().
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
Re: [PATCH 3/3] ARM: OMAP2+: BBB DT: mark eMMC as non removable
On Friday 13 September 2013 03:39 PM, Sekhar Nori wrote: Mark the eMMC module on BeagleBone black as non removable. Signed-off-by: Sekhar Nori nsek...@ti.com The patches which touch dts files are not really following the subject line conventions. I will fix that and send a v2. Thanks to Nishant for pointing out. Thanks, Sekhar -- 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: Odd behavior with dpll4_m4x2_ck on omap3 + DT
On 09/13/2013 10:51 AM, Stefan Roese wrote: On 11.09.2013 09:21, Tomi Valkeinen wrote: On 10/09/13 16:17, Tero Kristo wrote: In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) rate = parent_rate; else rate = parent_rate * 2; + return rate; } Stefan, are you able to test the above? I'd rather have a proper fix for this, than hack omapdss =). Okay, I finally found some time to test this. The patch above generates this warning: arch/arm/mach-omap2/dpll3xxx.c: In function 'omap3_clkoutx2_recalc': arch/arm/mach-omap2/dpll3xxx.c:663:6: warning: passing argument 1 of '__clk_get_rate' from incompatible pointer type [enabled by default] include/linux/clk-provider.h:423:15: note: expected 'struct clk *' but argument is of type 'struct clk_hw_omap *' Yea sorry about that, I just quickly hacked the patch together without testing it at all. :P I then changed it (not 100% sure if correctly) to this version: + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk-hw.clk)) And this seems to work. At least the clock rate mismatch warning does not appear with this patch applied (and without the clk_enable) in the bootlog any more. Yea, looks good to me, however I guess I would like second opinion on this also. -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
Re: [PATCH 3/4] drm: omap: Enable DT support for DMM
On Fri, Sep 13, 2013 at 5:14 AM, Archit Taneja arc...@ti.com wrote:
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross.
looks good.. but do we want to get information about # of LUT's, etc,
from DT? Or did we decide that we can reliably get this from the hw?
I lost track of that discussion (I guess Andy would remember)..
BR,
-R
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: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
Let me summarize:
- GIC supports up to 160 interrupts
- CROSSBAR supports up to 250 interrupts
- CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones
- Drivers request a CROSSBAR interrupt number which must be mapped
to some arbitrary available GIC irq number
Correct.
So basically the CROSSBAR mechanism is pretty much the same as MSI[X]
just in a different flavour and with a different set of semantics and
limitations, i.e. poor mans MSI[X] with a new level of bogosity.
So if CROSSBAR is going to be the new fangled SoC MSI[X] long term
equivalent then you better provide some infrastructure for that and
make the drivers ready to use it. Maybe check with the PCI/MSI folks
to share some of the interfaces.
If that whole thing is another onetime HW designers wet dream, then
please go back to the limited but completely functional (Who is going
to use more than 160 peripheral interrupts) device tree model. I
really have no interest to support hardware designer brain farts.
Thanks for clear NAK for irqchip approach. I should have looped you
in the discussion where I was also suggesting against the irqchip
approach. We will try to look at MSI stuff but if its get too
complicated am going to fall-back to the initial probe based
approach to achieve the functionality.
Before you dig into MSI, lets talk about irq domains first.
GIC implements a legacy irq domain, i.e. a linear domain of all
possible GIC interrupts with a 1:1 mapping.
So why can't you make use of irq domains and have the whole routing
business implemented sanely?
What's needed is in gic_init_bases():
if (of_property_read(node, routable_irqs, nr_routable_irqs) {
irq_domain_add_legacy(nr_gic_irqs);
} else {
irq_domain_add_legacy(nr_per_cpu_irqs);
irq_domain_add_linear(nr_routable_irqs);
}
Now that separate domain has an xlate function which grabs a free GIC
irq from a bitmap and returns the hardware irq number in the gic
space. The map/unmap callbacks take care of setting up / tearing down
the route in the crossbar.
Thoughts?
Thanks,
tglx
--
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: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
Let me summarize:
- GIC supports up to 160 interrupts
- CROSSBAR supports up to 250 interrupts
- CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones
- Drivers request a CROSSBAR interrupt number which must be mapped
to some arbitrary available GIC irq number
Correct.
So basically the CROSSBAR mechanism is pretty much the same as MSI[X]
just in a different flavour and with a different set of semantics and
limitations, i.e. poor mans MSI[X] with a new level of bogosity.
So if CROSSBAR is going to be the new fangled SoC MSI[X] long term
equivalent then you better provide some infrastructure for that and
make the drivers ready to use it. Maybe check with the PCI/MSI folks
to share some of the interfaces.
If that whole thing is another onetime HW designers wet dream, then
please go back to the limited but completely functional (Who is going
to use more than 160 peripheral interrupts) device tree model. I
really have no interest to support hardware designer brain farts.
Thanks for clear NAK for irqchip approach. I should have looped you
in the discussion where I was also suggesting against the irqchip
approach. We will try to look at MSI stuff but if its get too
complicated am going to fall-back to the initial probe based
approach to achieve the functionality.
Before you dig into MSI, lets talk about irq domains first.
GIC implements a legacy irq domain, i.e. a linear domain of all
possible GIC interrupts with a 1:1 mapping.
So why can't you make use of irq domains and have the whole routing
business implemented sanely?
What's needed is in gic_init_bases():
if (of_property_read(node, routable_irqs, nr_routable_irqs) {
irq_domain_add_legacy(nr_gic_irqs);
} else {
irq_domain_add_legacy(nr_per_cpu_irqs);
irq_domain_add_linear(nr_routable_irqs);
}
Now that separate domain has an xlate function which grabs a free GIC
irq from a bitmap and returns the hardware irq number in the gic
space. The map/unmap callbacks take care of setting up / tearing down
the route in the crossbar.
Thoughts?
This sounds pretty good idea. We will explore above option.
Thanks Thomas.
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 v4 2/4] ARM: dts: am335x-boneblack: add eMMC DT entry
* Koen Kooi k...@dominion.thruhere.net [130912 11:43]:
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 0d95d54..bc8d1a2 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -113,6 +113,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins =
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ ;
+ };
};
ocp {
Here you can now use just the defines to make it a bit shorter:
0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */
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
omap4, panda: 3.11, dtb and wifi
i know we switched to dtb-only booting, but what's happened to wifi? 3.5.x: flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl12xx/ total 0 drwxr-xr-x 5 root root0 set 13 17:26 . drwxr-xr-x 4 root root0 set 13 17:26 .. -rw-r--r-- 1 root root 4096 set 13 17:28 bt_coex_state lrwxrwxrwx 1 root root0 set 13 17:27 driver - ../../../../../../../../bus/platform/drivers/wl12xx_driver -r 1 root root0 set 13 17:28 fwlog -r--r--r-- 1 root root 4096 set 13 17:28 hw_pg_ver drwxr-xr-x 3 root root0 set 13 17:27 ieee80211 -r--r--r-- 1 root root 4096 set 13 17:28 modalias drwxr-xr-x 3 root root0 set 13 17:27 net drwxr-xr-x 2 root root0 set 13 17:28 power lrwxrwxrwx 1 root root0 set 13 17:27 subsystem - ../../../../../../../../bus/platform -rw-r--r-- 1 root root 4096 set 13 17:26 uevent 3.11.x: flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl* ls: cannot access /sys/bus/platform/devices/wl*: No such file or directory -- bye, p. -- 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/3] mmc: omap_hsmmc: get rid of ti,non-removable
* Sekhar Nori nsek...@ti.com [130913 03:18]: Get rid of TI specific binding ti,non-removable in favour of the generic binding present for the same purpose. Looks like there's a different handling in the MMC driver for no_regulator_off_init that's needed for eMMC. That needs to be sorted out and tested first. This patch set does not support the old binding anymore. So, yes, it does introduce an ABI breakage. IMHO, it is not really worth supporting both bindings ATM since DT-usage in OMAP is still very nascent and almost always DTB and uImage are upgraded together. The old bindings must be supported. It's not like we can just drop them. We should just keep the old binding and parse it the same way as the generic binding. That's a minimal amount of code. After the issue with no_regulator_off_init has been solved, then we can naturally update the existing .dts files to use the generic binding. 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: Fix build error with context tracking calls
On Tue, Sep 10, 2013 at 08:07:45AM -0700, Kevin Hilman wrote:
Nicolas Pitre nicolas.pi...@linaro.org writes:
Adding Kevin Hilman to the CC as he might be interested as well.
Thanks, I'd already noticed this but was distracted getting arm-soc
changes ready for the merge window. Looking into it now.
Kevin, can you please try this patch? It built tested fine on ARM
and live tested correctly on x86. There should be no problem but
just in case.
Thanks!
---
From 9bb601401baea0a2b2eead3909a9f186d894d617 Mon Sep 17 00:00:00 2001
From: Frederic Weisbecker fweis...@gmail.com
Date: Tue, 10 Sep 2013 00:54:17 +0200
Subject: [PATCH] arm: Fix build error with context tracking calls
ad65782fba50 (context_tracking: Optimize main APIs off case
with static key) converted context tracking main APIs to inline
functions and left ARM asm callers behind.
This can be easily fixed by making ARM calling the post static
keys context tracking functions. We just need to replicate the
static key checks there. We'll remove these later when ARM will
support the context tracking static keys.
Reported-by: Guenter Roeck li...@roeck-us.net
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Anil Kumar anilk...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/kernel/entry-header.S |8
kernel/context_tracking.c | 12
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index de23a9b..39f89fb 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -329,10 +329,10 @@
#ifdef CONFIG_CONTEXT_TRACKING
.if \save
stmdb sp!, {r0-r3, ip, lr}
- bl user_exit
+ bl context_tracking_user_exit
ldmia sp!, {r0-r3, ip, lr}
.else
- bl user_exit
+ bl context_tracking_user_exit
.endif
#endif
.endm
@@ -341,10 +341,10 @@
#ifdef CONFIG_CONTEXT_TRACKING
.if \save
stmdb sp!, {r0-r3, ip, lr}
- bl user_enter
+ bl context_tracking_user_enter
ldmia sp!, {r0-r3, ip, lr}
.else
- bl user_enter
+ bl context_tracking_user_enter
.endif
#endif
.endm
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 247091b..859c8df 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -51,6 +51,15 @@ void context_tracking_user_enter(void)
unsigned long flags;
/*
+* Repeat the user_enter() check here because some archs may be calling
+* this from asm and if no CPU needs context tracking, they shouldn't
+* go further. We can remove that check here once these archs support
the static key
+* check.
+*/
+ if (!static_key_false(context_tracking_enabled))
+ return;
+
+ /*
* Some contexts may involve an exception occuring in an irq,
* leading to that nesting:
* rcu_irq_enter() rcu_user_exit() rcu_user_exit() rcu_irq_exit()
@@ -151,6 +160,9 @@ void context_tracking_user_exit(void)
{
unsigned long flags;
+ if (!static_key_false(context_tracking_enabled))
+ return;
+
if (in_interrupt())
return;
--
1.7.5.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: omap4, panda: 3.11, dtb and wifi
* Paolo Pisati p.pis...@gmail.com [130913 08:43]: i know we switched to dtb-only booting, but what's happened to wifi? 3.5.x: flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl12xx/ total 0 drwxr-xr-x 5 root root0 set 13 17:26 . drwxr-xr-x 4 root root0 set 13 17:26 .. -rw-r--r-- 1 root root 4096 set 13 17:28 bt_coex_state lrwxrwxrwx 1 root root0 set 13 17:27 driver - ../../../../../../../../bus/platform/drivers/wl12xx_driver -r 1 root root0 set 13 17:28 fwlog -r--r--r-- 1 root root 4096 set 13 17:28 hw_pg_ver drwxr-xr-x 3 root root0 set 13 17:27 ieee80211 -r--r--r-- 1 root root 4096 set 13 17:28 modalias drwxr-xr-x 3 root root0 set 13 17:27 net drwxr-xr-x 2 root root0 set 13 17:28 power lrwxrwxrwx 1 root root0 set 13 17:27 subsystem - ../../../../../../../../bus/platform -rw-r--r-- 1 root root 4096 set 13 17:26 uevent 3.11.x: flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl* ls: cannot access /sys/bus/platform/devices/wl*: No such file or directory Hmm it seems we're still missing the .dts entries. I'll post two patches shortly, one for panda and one for 4430sdp. 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 1/2] ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Commit b42b9181 (ARM: OMAP2+: Remove board-omap4panda.c)
removed legacy booting in favor of device tree based booting
for pandaboard. That caused the WLAN to stop working as the
related .dts entries fell through the cracks.
The legacy muxing was setting pulls for GPIO 48 and 49, so let's
keep that behaviour for now to avoid further regressions for
BT and FM. Also input logic was enabled for MMC CLK line, but
I've verified that the input logic we don't need enabled for
CLK line as it's not bidirectional.
Also, we want to use non-removable instead of ti,non-removable
as the ti,non-removable also sets no_regulator_off_init which
is really not what we want as then wl12xx won't get powered
up and down which is needed for resetting it.
Note that looks like the WLAN interface fails to come up after
a warm reset, but that most likely was also happening with
the legacy booting and needs a separate fix.
Cc: Paolo Pisati p.pis...@gmail.com
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Luciano Coelho l...@coelho.fi
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 46 -
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..814ab67 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,19 @@
*/
clock-frequency = 1920;
};
+
+ /* regulator for wl12xx on sdio5 */
+ 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 = gpio2 11 0;
+ startup-delay-us = 7;
+ enable-active-high;
+ };
};
omap4_pmx_wkup {
@@ -235,6 +248,33 @@
0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
;
};
+
+ /*
+* wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP
+* REVISIT: Are the pull-ups needed for GPIO 48 and 49?
+*/
+ wl12xx_gpio: pinmux_wl12xx_gpio {
+ pinctrl-single,pins =
+ 0x26 (PIN_OUTPUT | MUX_MODE3) /*
gpmc_a19.gpio_43 */
+ 0x2c (PIN_OUTPUT | MUX_MODE3) /*
gpmc_a22.gpio_46 */
+ 0x30 (PIN_OUTPUT_PULLUP | MUX_MODE3)/*
gpmc_a24.gpio_48 */
+ 0x32 (PIN_OUTPUT_PULLUP | MUX_MODE3)/*
gpmc_a25.gpio_49 */
+ ;
+ };
+
+ /* wl12xx GPIO inputs and SDIO pins */
+ wl12xx_pins: pinmux_wl12xx_pins {
+ pinctrl-single,pins =
+ 0x38 (PIN_INPUT | MUX_MODE3)/*
gpmc_ncs2.gpio_52 */
+ 0x3a (PIN_INPUT | MUX_MODE3)/*
gpmc_ncs3.gpio_53 */
+ 0x108 (PIN_OUTPUT | MUX_MODE0) /*
sdmmc5_clk.sdmmc5_clk */
+ 0x10a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_cmd.sdmmc5_cmd */
+ 0x10c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat0.sdmmc5_dat0 */
+ 0x10e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat1.sdmmc5_dat1 */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat2.sdmmc5_dat2 */
+ 0x112 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat3.sdmmc5_dat3 */
+ ;
+ };
};
i2c1 {
@@ -314,8 +354,12 @@
};
mmc5 {
- ti,non-removable;
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_pins;
+ vmmc-supply = wl12xx_vmmc;
+ non-removable;
bus-width = 4;
+ cap-power-off-card;
};
emif1 {
--
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: Fix muxing and regulator for wl12xx on the SDIO bus for blaze
Commit 76787b3b (ARM: OMAP2+: Remove board-4430sdp.c)
removed legacy booting in favor of device tree based booting
for 4430sdp. That caused the WLAN to stop working as the
related .dts entries fell through the cracks.
I don't have the 1283 PG 2.21 connectivity device on my 4430sdp,
but the earlier version of this patch was tested by Luciano
Coelho. This version has left out the input logic for MMC CLK
line compared to the earlier version as that is not bidirectional,
and should be safe to do.
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Luciano Coelho l...@coelho.fi
Cc: Ruslan Bilovol ruslan.bilo...@ti.com
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap4-sdp.dts | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..4f78380 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,19 @@
DMic, Digital Mic,
Digital Mic, Digital Mic1 Bias;
};
+
+ /* regulator for wl12xx on sdio5 */
+ 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 = gpio2 22 0;
+ startup-delay-us = 7;
+ enable-active-high;
+ };
};
omap4_pmx_wkup {
@@ -295,6 +308,26 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
;
};
+
+ /* wl12xx GPIO output for WLAN_EN */
+ wl12xx_gpio: pinmux_wl12xx_gpio {
+ pinctrl-single,pins =
+ 0x3c (PIN_OUTPUT | MUX_MODE3) /*
gpmc_nwp.gpio_54 */
+ ;
+ };
+
+ /* wl12xx GPIO inputs and SDIO pins */
+ wl12xx_pins: pinmux_wl12xx_pins {
+ pinctrl-single,pins =
+ 0x3a (PIN_INPUT | MUX_MODE3)/*
gpmc_ncs3.gpio_53 */
+ 0x108 (PIN_OUTPUT | MUX_MODE3) /*
sdmmc5_clk.sdmmc5_clk */
+ 0x10a (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_cmd.sdmmc5_cmd */
+ 0x10c (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat0.sdmmc5_dat0 */
+ 0x10e (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat1.sdmmc5_dat1 */
+ 0x110 (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat2.sdmmc5_dat2 */
+ 0x112 (PIN_INPUT_PULLUP | MUX_MODE3)/*
sdmmc5_dat3.sdmmc5_dat3 */
+ ;
+ };
};
i2c1 {
@@ -420,8 +453,12 @@
};
mmc5 {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_pins;
+ vmmc-supply = wl12xx_vmmc;
+ non-removable;
bus-width = 4;
- ti,non-removable;
+ cap-power-off-card;
};
emif1 {
--
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] WLAN regression fixes for omap4 after moving to DT based booting
Hi all, Looks like these two patches are still missing as I did not update the kernel on my panda for a while but was testing with my 4430sdp that does not have the WLAN card.. Regards, Tony --- Tony Lindgren (2): ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for blaze arch/arm/boot/dts/omap4-panda-common.dtsi | 46 - arch/arm/boot/dts/omap4-sdp.dts | 39 - 2 files changed, 83 insertions(+), 2 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
Re: [PATCH 0/3] mmc: omap_hsmmc: get rid of ti,non-removable
On Friday 13 September 2013 09:07 PM, Tony Lindgren wrote: * Sekhar Nori nsek...@ti.com [130913 03:18]: Get rid of TI specific binding ti,non-removable in favour of the generic binding present for the same purpose. Looks like there's a different handling in the MMC driver for no_regulator_off_init that's needed for eMMC. That needs to be sorted out and tested first. Hi Sekhar, no_regulator_off_init is needed for eMMC detection on omap4 platforms. This patch set does not support the old binding anymore. So, yes, it does introduce an ABI breakage. IMHO, it is not really worth supporting both bindings ATM since DT-usage in OMAP is still very nascent and almost always DTB and uImage are upgraded together. The old bindings must be supported. It's not like we can just drop them. We should just keep the old binding and parse it the same way as the generic binding. That's a minimal amount of code. After the issue with no_regulator_off_init has been solved, then we can naturally update the existing .dts files to use the generic binding. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Fix build error with context tracking calls
Frederic Weisbecker fweis...@gmail.com writes: On Tue, Sep 10, 2013 at 08:07:45AM -0700, Kevin Hilman wrote: Nicolas Pitre nicolas.pi...@linaro.org writes: Adding Kevin Hilman to the CC as he might be interested as well. Thanks, I'd already noticed this but was distracted getting arm-soc changes ready for the merge window. Looking into it now. Kevin, can you please try this patch? It built tested fine on ARM and live tested correctly on x86. There should be no problem but just in case. Tested-by: Kevin Hilman khil...@linaro.org Things are back to working again on ARM. Thanks for the fix, and for build testing on ARM. As you noticed to test on ARM, we still have to carry that patch to drop that 'depends on 64BIT' in order to build/test this... any more thoughts on what the remaining obstacles there are? 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
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 09/12/2013 04:58 AM, Sekhar Nori wrote:
On Wednesday 11 September 2013 12:22 AM, Joel Fernandes wrote:
HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.
[..]
It is better to send one version with all comments fixed. Helps avoid
confusion.
Ok, here is the final version with all comments fixed, please apply this one:
---8---
From: Joel Fernandes jo...@ti.com
Subject: [PATCH v4] ARM: EDMA: Fix clearing of unused list for DT DMA resources
HWMOD removal for MMC is breaking edma_start as the events are being manually
triggered due to unused channel list not being clear.
This patch fixes the issue, by reading the dmas property from the DT node if
it exists and clearing the bits in the unused channel list. For this purpose
we use the of_* helpers to parse the arguments in the dmas phandle list.
Reviewed-by: Sekhar Nori nsek...@ti.com
Reported-by: Balaji T K balaj...@ti.com
Cc: Pantel Antoniou pa...@antoniou-consulting.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
Changes since v1, in v2 and v3:
- Reduced indentation of non-of case by returning from of-case
- Using of_* helpers for parsing
Note:
This patch should go into the merge window as it is a critical bug fix.
arch/arm/common/edma.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 39ad030..43c7b22 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -560,14 +560,33 @@ static int reserve_contiguous_slots(int ctlr, unsigned int
id,
static int prepare_unused_channel_list(struct device *dev, void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- int i, ctlr;
+ int i, count, ctlr;
+ struct of_phandle_args dma_spec;
+ if (dev-of_node) {
+ count = of_property_count_strings(dev-of_node, dma-names);
+ if (count 0)
+ return 0;
+ for (i = 0; i count; i++) {
+ if (of_parse_phandle_with_args(dev-of_node, dmas,
+ #dma-cells, i,
+ dma_spec))
+ continue;
+
+ ctlr = EDMA_CTLR(dma_spec.args[0]);
+ clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
+ edma_cc[ctlr]-edma_unused);
+ }
+ return 0;
+ }
+
+ /* For non-OF case */
for (i = 0; i pdev-num_resources; i++) {
if ((pdev-resource[i].flags IORESOURCE_DMA)
(int)pdev-resource[i].start = 0) {
ctlr = EDMA_CTLR(pdev-resource[i].start);
clear_bit(EDMA_CHAN_SLOT(pdev-resource[i].start),
- edma_cc[ctlr]-edma_unused);
+ edma_cc[ctlr]-edma_unused);
}
}
--
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: [PATCH 0/2] WLAN regression fixes for omap4 after moving to DT based booting
Hi, Not related to wlan but with DT conversion; I noticed the following in dmesg on Panda ES with omap2plus_defconfig on current mainline: [0.00] smp_twd: clock not found -2 and: [0.440399] omap-gpmc 5000.gpmc: error: clk_get -Olof -- 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
