Re: Porting board initialization for fdt
Hi, On Mon, Nov 12, 2012 at 12:38:37AM +0200, Constantine Shulyupin wrote: What is architecture and the best strategy to port board initialization to fdt? Let's see for example omap4_ehci_init and usbhs_bdata @ arch/arm/mach-omap2/board-omap4panda.c. before getting rid of platform_data, we need to switch over to proper frameworks for muxing, clock, etc. In case of EHCI, pinctrl migration is currently under development by Keshava (in Cc). After that we need to take a look at platform and see if there are any function pointers in there, if there are, those need to be removed. How to perform board specific initializations? Can omap4_ehci_init be converted to probe function of new platform driver omap4_ehci? yeah, that function is actually wrong. First, that GPIO pin belongs to the HUB driver, not the EHCI driver. Second, those clocks belong to the PHY, not EHCI either. Before those details are cleaned up, we will always have hacky solutions which will break in one way or another. When those cleanups are done, conversion to FDT is not a problem at all. -- balbi signature.asc Description: Digital signature
RE: [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
On Tue, Nov 06, 2012 at 22:26:54, Cousson, Benoit wrote:
Hi Anil,
On 11/06/2012 06:07 AM, AnilKumar, Chimata wrote:
On Mon, Nov 05, 2012 at 22:13:25, Cousson, Benoit wrote:
Hi Anil / Colin,
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Added while (1); after the above steps to make sure that no other
process acquire cpu. Otherwise we might see an unexpected behaviour
because we are shutting down all the power rails of SoC except RTC.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 79
+++-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
I don't know how it is connected at board level, but I'm not sure the
binding is the proper one.
Hi Benoit,
| __ ___ |
| | || | |
| |RTC || | |
| |PMIC | Line | | |
| |PWR_EN|===|PWR_EN | |
| |__||___| |
| AM335x SoC TPS65217 |
||
||
BeagleBone
This is how RTC PMIC_PWR_EN is connected to PWR_EN of TPS65217 PMIC. Only
when
RTC pull low in PMIC_PWR_EN then PMIC will go to power off state provided
TPS65217
status should be changed to STATUS_OFF.
ALARM2 event should be trigger to configure PMIC_PWR_EN properly then the
Line
driven low so that PMIC will go to shutdown mode.
Thanks for the nice diagram :-)
I missed this mail thread so delayed in response
I'm wondering if we cannot abuse the gpio binding to describe that
connection instead of creating two custom attributes (PMIC + RTC).
Ideally we should do that without having to change the RTC to use the
gpiolib at all.
rtc: rtc@44e3e000 {
compatible = ti,da830-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75, 76;
ti,hwmods = rtc;
/* expose the PWR_EN functionality of this RTC*/
gpio-controller;
#gpio-cells = 0; /* assuming we can use 0 ??? */
};
...
tps: tps@24 {
compatible = ti,tps65217;
/*
* Enable the power enable feature from
* the input line if that attribute is there.
*/
gpio-power-en = rtc; /* PWR_EN */
...
}
Any thought?
No, these two are independent controllers. PMIC can go to power
off mode if we pull PWR_EN to low. We can pull down that line
by any means like PRCM or GPIO or some other. So these two flags
should be independent from each other.
Thanks
AnilKumar
--
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/4] rtc: OMAP: Add system pm_power_off to rtc driver
On Tue, Nov 06, 2012 at 11:15:34, Bedia, Vaibhav wrote:
On Mon, Nov 05, 2012 at 15:12:27, AnilKumar, Chimata wrote:
[...]
+#define SHUTDOWN_TIME_SEC 2
+#define SECS_IN_MIN60
+#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
+#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
+
static void __iomem*rtc_base;
[...]
+
+ /* Wait few seconds instead of rollover */
+ do {
+ omap_rtc_read_time(NULL, tm);
+ if (WAIT_AFTER = tm.tm_sec)
+ mdelay(WAIT_TIME_MS);
+ } while (WAIT_AFTER = tm.tm_sec);
This hardcoded wait for rollover doesn't look good. I see some
helper functions in rtc-lib.c which probably could be used for
converting the current time to elapsed seconds, add the delay and
then convert it back to the time to be programmed in RTC without
worrying about rollover. Why not use that?
I am not aware of those APIs, can you point some?
+
+ /* Add shutdown time to the current value */
+ tm.tm_sec += SHUTDOWN_TIME_SEC;
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /* Set the ALARM2 time */
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+ /* Enable alarm2 interrupt */
+ val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
+ writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
+ rtc_base + OMAP_RTC_INTERRUPTS_REG);
+
These registers are not present in older versions of the IP so how
does that get handled?
I think, earlier this feature is not supported/not used.
You also need to describe the connection between the ALARM2 and the
power off logic in detail.
Sure, I will add.
Thanks
AnilKumar
--
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] pwm-backlight: Pinctrl-fy
Hi Linus, On Nov 11, 2012, at 7:26 PM, Linus Walleij wrote: On Fri, Nov 9, 2012 at 9:06 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Wed, Oct 31, 2012 at 05:57:27PM +0200, Pantelis Antoniou wrote: + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, unable to select pin group\n); + I just saw this done in a similar way in some other driver and then remembered your patch. When I reviewed this I wasn't sure if a warning was good enough in this case. I've checked the kernel tree and it seems like a majority handled this as failure instead of a warning. I took a look at the pinctrl core and it seems like indeed if neither pinctrl is enabled or if there isn't actually a pinmux configuration for a device, then devm_pinctrl_get_select_default() will actually not return an error, so in those cases where an error is returned it should actually be handled as a fatal error. So it depends. One good reason to just error out and return the error code is if the error returned is -EPROBE_DEFER, right? Because then you're pinctrl driver is not up yet, and you need to bail out and be revisited later. On a related key we have this debate going on with some subsystem maintainers as to whether we should try do centralize boilerplate like this, the lates suggestion is: http://marc.info/?l=linux-kernelm=135263661110528w=2 Interesting... This is certainly much nicer than peppering all the devices with pinctrl calls. The fun never ends... Indeed. Yours, Linus Walleij Regards -- Pantelis -- 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/5] OMAPFB: use dma_alloc instead of omap's vram
Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Tomi Tomi Valkeinen (5): OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask OMAPFB: use dma_alloc_attrs to allocate memory OMAP: RX51: remove use of vram OMAP: common.c: remove init call to vram OMAP: remove vram allocator arch/arm/mach-omap2/board-rx51-video.c| 14 - arch/arm/mach-omap2/board-rx51.c |3 - arch/arm/plat-omap/common.c |2 - arch/arm/plat-omap/fb.c |5 +- arch/arm/plat-omap/include/plat/vram.h| 43 --- drivers/video/omap2/Kconfig |3 - drivers/video/omap2/Makefile |1 - drivers/video/omap2/dss/Kconfig | 12 - drivers/video/omap2/omapfb/Kconfig|1 - drivers/video/omap2/omapfb/omapfb-ioctl.c | 14 +- drivers/video/omap2/omapfb/omapfb-main.c | 69 ++-- drivers/video/omap2/omapfb/omapfb.h |5 + drivers/video/omap2/vram.c| 514 - 13 files changed, 51 insertions(+), 635 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/vram.h delete mode 100644 drivers/video/omap2/vram.c -- 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 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask
Use DMA_BIT_MASK() for fb's coherent_dma_mask for clarity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/plat-omap/fb.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index bcbb9d5..218963b 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -29,6 +29,7 @@
#include linux/memblock.h
#include linux/io.h
#include linux/omapfb.h
+#include linux/dma-mapping.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -45,7 +46,7 @@ static struct platform_device omap_fb_device = {
.id = -1,
.dev = {
.dma_mask = omap_fb_dma_mask,
- .coherent_dma_mask = ~(u32)0,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = omapfb_config,
},
.num_resources = 0,
@@ -81,7 +82,7 @@ static struct platform_device omap_fb_device = {
.id = -1,
.dev = {
.dma_mask = omap_fb_dma_mask,
- .coherent_dma_mask = ~(u32)0,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = omapfb_config,
},
.num_resources = 0,
--
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/5] OMAPFB: use dma_alloc_attrs to allocate memory
Use dma_alloc_attrs to allocate memory instead of omap specific vram
allocator. After this we can remove the omap vram allocator.
There are some downsides to this change:
1) dma_alloc_attrs doesn't let us allocate at certain physical address.
However, this should not be a problem as this feature of vram allocator
is only used when reserving the framebuffer that was initialized by the
bootloader, and we don't currently support passing a framebuffer from
the bootloader to the kernel anyway.
2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
we don't need the ioremap when using VRFB. This patch uses
DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
not operational.
3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
changed the ioctl to return 64M for all the values, which, I hope, the
applications will interpret as there's enough vram.
4) vram kernel parameter to define how much ram to reserve for video
use no longer works. The user needs to enable CMA and use cma
parameter.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/Kconfig|1 -
drivers/video/omap2/omapfb/omapfb-ioctl.c | 14 +++---
drivers/video/omap2/omapfb/omapfb-main.c | 69 +++--
drivers/video/omap2/omapfb/omapfb.h |5 +++
4 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/omapfb/Kconfig
b/drivers/video/omap2/omapfb/Kconfig
index 4ea17dc..4cb12ce 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -2,7 +2,6 @@ menuconfig FB_OMAP2
tristate OMAP2+ frame buffer support
depends on FB OMAP2_DSS !DRM_OMAP
- select OMAP2_VRAM
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..574c170 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -31,7 +31,6 @@
#include video/omapdss.h
#include plat/vrfb.h
-#include plat/vram.h
#include omapfb.h
@@ -853,14 +852,15 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
break;
case OMAPFB_GET_VRAM_INFO: {
- unsigned long vram, free, largest;
-
DBG(ioctl GET_VRAM_INFO\n);
- omap_vram_get_info(vram, free, largest);
- p.vram_info.total = vram;
- p.vram_info.free = free;
- p.vram_info.largest_free_block = largest;
+ /*
+* We don't have the ability to get this vram info anymore.
+* Fill in something that should keep the applications working.
+*/
+ p.vram_info.total = SZ_1M * 64;
+ p.vram_info.free = SZ_1M * 64;
+ p.vram_info.largest_free_block = SZ_1M * 64;
if (copy_to_user((void __user *)arg, p.vram_info,
sizeof(p.vram_info)))
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 16db158..84c1012 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -32,7 +32,6 @@
#include video/omapdss.h
#include plat/cpu.h
-#include plat/vram.h
#include plat/vrfb.h
#include omapfb.h
@@ -1336,24 +1335,25 @@ static void omapfb_free_fbmem(struct fb_info *fbi)
rg = ofbi-region;
- WARN_ON(atomic_read(rg-map_count));
-
- if (rg-paddr)
- if (omap_vram_free(rg-paddr, rg-size))
- dev_err(fbdev-dev, VRAM FREE failed\n);
+ if (rg-token == NULL)
+ return;
- if (rg-vaddr)
- iounmap(rg-vaddr);
+ WARN_ON(atomic_read(rg-map_count));
if (ofbi-rotation_type == OMAP_DSS_ROT_VRFB) {
/* unmap the 0 angle rotation */
if (rg-vrfb.vaddr[0]) {
iounmap(rg-vrfb.vaddr[0]);
- omap_vrfb_release_ctx(rg-vrfb);
rg-vrfb.vaddr[0] = NULL;
}
+
+ omap_vrfb_release_ctx(rg-vrfb);
}
+ dma_free_attrs(fbdev-dev, rg-size, rg-token, rg-dma_handle,
+ rg-attrs);
+
+ rg-token = NULL;
rg-vaddr = NULL;
rg-paddr = 0;
rg-alloc = 0;
@@ -1388,7 +1388,9 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi,
unsigned long size,
struct omapfb_info *ofbi = FB2OFB(fbi);
struct omapfb2_device *fbdev = ofbi-fbdev;
struct omapfb2_mem_region *rg;
- void __iomem *vaddr;
+ void *token;
+ DEFINE_DMA_ATTRS(attrs);
+ dma_addr_t dma_handle;
int r;
rg = ofbi-region;
@@ -1403,42 +1405,43 @@ static int omapfb_alloc_fbmem(struct fb_info
[PATCH 3/5] OMAP: RX51: remove use of vram
As omapfb no longer uses omap specific vram allocator we can remove the
vram pre-allocation from rx51 board file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-rx51-video.c | 14 --
arch/arm/mach-omap2/board-rx51.c |3 ---
2 files changed, 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index c22e111..46f4fc9 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -16,7 +16,6 @@
#include linux/mm.h
#include asm/mach-types.h
#include video/omapdss.h
-#include plat/vram.h
#include linux/platform_data/spi-omap2-mcspi.h
#include board-rx51.h
@@ -87,17 +86,4 @@ static int __init rx51_video_init(void)
}
subsys_initcall(rx51_video_init);
-
-void __init rx51_video_mem_init(void)
-{
- /*
-* GFX 864x480x32bpp
-* VID1/2 1280x720x32bpp double buffered
-*/
- omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
- 2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
-}
-
-#else
-void __init rx51_video_mem_init(void) { }
#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 7bbb05d..6e0de6f 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -34,8 +34,6 @@
#define RX51_GPIO_SLEEP_IND 162
-extern void rx51_video_mem_init(void);
-
static struct gpio_led gpio_leds[] = {
{
.name = sleep_ind,
@@ -112,7 +110,6 @@ static void __init rx51_init(void)
static void __init rx51_reserve(void)
{
- rx51_video_mem_init();
omap_reserve();
}
--
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 4/5] OMAP: common.c: remove init call to vram
OMAP specific vram allocator is no longer used, and we can remove init
call to the vram allocator.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/plat-omap/common.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 111315a..d21ed18 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -17,7 +17,6 @@
#include linux/dma-mapping.h
#include plat/common.h
-#include plat/vram.h
#include linux/platform_data/dsp-omap.h
#include plat/dma.h
@@ -25,7 +24,6 @@
void __init omap_reserve(void)
{
- omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
--
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 5/5] OMAP: remove vram allocator
OMAP specific vram allocator is no longer in use, and we can remove all
the vram code.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/plat-omap/include/plat/vram.h | 43 ---
drivers/video/omap2/Kconfig|3 -
drivers/video/omap2/Makefile |1 -
drivers/video/omap2/dss/Kconfig| 12 -
drivers/video/omap2/vram.c | 514
5 files changed, 573 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vram.h
delete mode 100644 drivers/video/omap2/vram.c
diff --git a/arch/arm/plat-omap/include/plat/vram.h
b/arch/arm/plat-omap/include/plat/vram.h
deleted file mode 100644
index 4d65b7d..000
--- a/arch/arm/plat-omap/include/plat/vram.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * VRAM manager for OMAP
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen tomi.valkei...@nokia.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, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAP_VRAM_H__
-#define __OMAP_VRAM_H__
-
-#include linux/types.h
-
-extern int omap_vram_add_region(unsigned long paddr, size_t size);
-extern int omap_vram_free(unsigned long paddr, size_t size);
-extern int omap_vram_alloc(size_t size, unsigned long *paddr);
-extern int omap_vram_reserve(unsigned long paddr, size_t size);
-extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
- unsigned long *largest_free_block);
-
-#ifdef CONFIG_OMAP2_VRAM
-extern void omap_vram_set_sdram_vram(u32 size, u32 start);
-
-extern void omap_vram_reserve_sdram_memblock(void);
-#else
-static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
-
-static inline void omap_vram_reserve_sdram_memblock(void) { }
-#endif
-
-#endif
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index d877c36..346d67d 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -1,6 +1,3 @@
-config OMAP2_VRAM
- bool
-
config OMAP2_VRFB
bool
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 5ddef12..5ea7cb9 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1,4 +1,3 @@
-obj-$(CONFIG_OMAP2_VRAM) += vram.o
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
obj-$(CONFIG_OMAP2_DSS) += dss/
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 80f5390..058a669 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -6,18 +6,6 @@ menuconfig OMAP2_DSS
if OMAP2_DSS
-config OMAP2_VRAM_SIZE
- int VRAM size (MB)
- range 0 32
- default 0
- help
- The amount of SDRAM to reserve at boot time for video RAM use.
- This VRAM will be used by omapfb and other drivers that need
- large continuous RAM area for video use.
-
- You can also set this with vram=bytes kernel argument, or
- in the board file.
-
config OMAP2_DSS_DEBUG_SUPPORT
bool Debug support
default y
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
deleted file mode 100644
index f2b15c4..000
--- a/drivers/video/omap2/vram.c
+++ /dev/null
@@ -1,514 +0,0 @@
-/*
- * VRAM manager for OMAP
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen tomi.valkei...@nokia.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, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-/*#define DEBUG*/
-
-#include linux/kernel.h
-#include linux/mm.h
-#include linux/list.h
-#include linux/slab.h
-#include linux/seq_file.h
-#include linux/memblock.h
-#include linux/completion.h
-#include linux/debugfs.h
-#include linux/jiffies.h
-#include linux/module.h
-
-#include asm/setup.h
-
-#include plat/vram.h
-
-#ifdef DEBUG
-#define DBG(format, ...) pr_debug(VRAM: format, ##
RE: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Fri, Nov 09, 2012 at 00:46:28, Hunter, Jon wrote:
On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote:
On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
[snip]
There is no reliable way to determine which source should be used in
runtime
for boards that do not have the 32k oscillator wired.
So thinking about this some more and given that we are moving away from
board files, if a board does not provide a 32kHz clock source, then this
should be reflected in the device-tree source file for that board.
Hence, at boot time we should be able to determine if a 32kHz clock
source can be used.
Let me feed some more thoughts here :)
The way it is being detected currently is based on timer idle status bit.
I am worried that, this is the only option we have.
Why not use device-tree to indicate the presence of a 32k clock source?
This seems like a board level configuration and so device-tree seems to
be the perfect place for this IMO.
I think I agree with you, but for this to happen in clean way, its time to
start populating clock-nodes in DT, don't you think? Something like,
clocks {
rtc_clk: clk@X {
compatible = crystal-32k, per-32k, xyz;
clock-frequency = 32768;
};
...
};
Timer {
ref-clock = rtc_clk;
};
What do you think?
Thanks,
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] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Mon, Nov 12, 2012 at 12:54:59, Igor Grinberg wrote: On 11/12/12 08:38, Hiremath, Vaibhav wrote: On Sun, Nov 11, 2012 at 17:05:07, Igor Grinberg wrote: On 11/08/12 20:34, Jon Hunter wrote: On 11/08/2012 12:17 PM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: On 11/08/2012 11:58 AM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: Igor was mentioning a h/w scenario where the 32kHz source is not present. However, I am not sure which devices support this and is applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 PRM Clock Generator and the AM3517 DM Rev C (SPRS550C) Section 4 Clock Specifications. But AFAICT, even in that h/w configuration the internal 32k oscillator will be used Just to clarify, there's no internal 32k oscillator used on the 3517/3505; just a divider from the HF clock. Ah yes I see that now! and so the gptimer will still have a 32k clock source. That's a good question and you might want to check with Igor on that one, the AM3517 TRM conflicts with the DM as to whether it's available to the GPTIMER or not :-( Well the external 32k and internal divided down version go through the same mux and so that seems to imply either they are both available to the gptimer or neither is. Yep, but the /800 do not get you the 32768... and that makes the timer suck. Of course this can be dealt with in the clock subsystem (I remember Paul said that he will look into that), but it will take time. Also, what about having the sys_clk instead of 32k for higher precision? Is that possible already (without my patch)? Yes, it is possible. You can choose it through bootargs. Is the kernel command line the only way for doing this? I personally dislike it, because it brings multiple maintenance problems. This must be possible at least through DT. Its standard interface, so carries all the applicable pros and cons. I am not quite sure about runtime change of clocksoyrce, its pros and cons. Thanks, Vaibhav -- Regards, Igor. -- 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: add get_user() support for 8 byte types
On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
From: Rob Clark r...@ti.com
A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/include/asm/uaccess.h | 25 -
arch/arm/lib/getuser.S | 17 -
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 7e1f760..2e3fdb2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
extern int __get_user_1(void *);
extern int __get_user_2(void *);
extern int __get_user_4(void *);
+extern int __get_user_8(void *);
#define __GUP_CLOBBER_1 lr, cc
#ifdef CONFIG_CPU_USE_DOMAINS
@@ -108,6 +109,7 @@ extern int __get_user_4(void *);
#define __GUP_CLOBBER_2 lr, cc
#endif
#define __GUP_CLOBBER_4 lr, cc
+#define __GUP_CLOBBER_8 lr, cc
#define __get_user_x(__r2,__p,__e,__l,__s) \
__asm__ __volatile__ ( \
@@ -122,22 +124,35 @@ extern int __get_user_4(void *);
({ \
unsigned long __limit = current_thread_info()-addr_limit - 1; \
register const typeof(*(p)) __user *__p asm(r0) = (p);\
- register unsigned long __r2 asm(r2); \
register unsigned long __l asm(r1) = __limit; \
register int __e asm(r0); \
switch (sizeof(*(__p))) { \
- case 1: \
+ case 1: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 1); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 2: \
+ } \
+ case 2: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 2); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 4: \
+ } \
+ case 4: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 4); \
+ x = (typeof(*(p))) __r2;\
+ break; \
+ } \
+ case 8: { \
+ register unsigned long long __r2 asm(r2); \
Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
asm, so the compiler shouldn't care much. For OABI, I think you may have to
do some more work to get the two words where you want them.
+ __get_user_x(__r2, __p, __e, __l, 8); \
+ x = (typeof(*(p))) __r2;\
break; \
+ } \
default: __e = __get_user_bad(); break; \
} \
- x = (typeof(*(p))) __r2;\
__e;\
})
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..d05285c 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
* Inputs: r0 contains the address
* r1 contains the address limit, which must be preserved
* Outputs: r0 is the error code
- * r2 contains the zero-extended value
+ * r2, r3 contains the zero-extended value
* lr corrupted
*
* No other registers must be altered. (see asm/uaccess.h
@@ -66,6 +66,19 @@ ENTRY(__get_user_4)
mov pc, lr
ENDPROC(__get_user_4)
+ENTRY(__get_user_8)
+ check_uaccess r0, 4, r1, r2, __get_user_bad
Shouldn't you be passing 8 here, so that
Re: [PATCH 12/11] ARM: OMAP: Fix relative includes for fpga.h
Hi Tony,
After rebasing on top of your omap-for-v3.8/tmp-merge, I realized that this
patch is generating a build break due to removal of the fpga.h include from
debug-leds.c.
arch/arm/plat-omap/debug-leds.c: In function 'fpga_probe':
arch/arm/plat-omap/debug-leds.c:114:9: error: 'H2P2_DBG_FPGA_SIZE' undeclared
(first use in this function)
arch/arm/plat-omap/debug-leds.c:114:9: note: each undeclared identifier is
reported only once for each function it appears in
It does not appear with the omap2plus_config but will appear if you enable the
NEW_LEDS support that enable OMAP_DEBUG_LEDS.
I'm not sure why the size is still hard coded. In theory, assuming the resource
is properly initialized, resource_size should be usable.
The patch below is fixing that.
Regards,
Benoit
---
From 81e1c31cd78b1f5a04983cf920b287764f11 Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Mon, 12 Nov 2012 11:44:03 +0100
Subject: [PATCH] ARM: OMAP: debug-leds: Use resource_size instead of hard coded
macro
The debug-leds driver should not rely on hard coded macro for
the iomem size but use the resource size instead.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/plat-omap/debug-leds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/debug-leds.c b/arch/arm/plat-omap/debug-leds.c
index c43ea21..aa7ebc6 100644
--- a/arch/arm/plat-omap/debug-leds.c
+++ b/arch/arm/plat-omap/debug-leds.c
@@ -111,7 +111,7 @@ static int fpga_probe(struct platform_device *pdev)
if (!iomem)
return -ENODEV;
- fpga = ioremap(iomem-start, H2P2_DBG_FPGA_SIZE);
+ fpga = ioremap(iomem-start, resource_size(iomem));
__raw_writew(0xff, fpga-leds);
for (i = 0; i ARRAY_SIZE(dbg_leds); i++) {
--
1.7.0.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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Op 10 nov. 2012, om 00:40 heeft Grant Likely grant.lik...@secretlab.ca het volgende geschreven: On Fri, Nov 9, 2012 at 11:23 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/09/2012 09:28 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: ... I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. From your perspective, is it important to use the exact same .dtb overlays for those add-on boards, or is it okay to have a separate build of the overlay for each base tree? I certainly think it'd be extremely beneficial to use the exact same child board .dtb with arbitrary base boards. Consider something like the Arduino shield connector format, which I /believe/ has been re-used across a wide variety of Arduino boards and other compatible or imitation boards. Now consider a vendor of an Arduino shield. The shield vendor probably wants to publish a single .dtb file that works for users irrespective of which board they're using it with. (Well, I'm not sure that Arduino can run Linux; perhaps that's why you picked BeagleBone capes for your document!) Correct, the Arduino is only an AVR with a tiny amount of ram. No Linux there. However, Arduino shields are a good example of a use case. I think there are even some Arduino shield compatible Linux boards out there. A good example of those would be the Rascal Micro: http://rascalmicro.com/ 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] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
Hi Vaibhav,
On 11/12/2012 11:38 AM, Hiremath, Vaibhav wrote:
On Fri, Nov 09, 2012 at 00:46:28, Hunter, Jon wrote:
On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote:
On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote:
On 11/08/2012 01:59 AM, Igor Grinberg wrote:
[snip]
There is no reliable way to determine which source should be used in
runtime
for boards that do not have the 32k oscillator wired.
So thinking about this some more and given that we are moving away from
board files, if a board does not provide a 32kHz clock source, then this
should be reflected in the device-tree source file for that board.
Hence, at boot time we should be able to determine if a 32kHz clock
source can be used.
Let me feed some more thoughts here :)
The way it is being detected currently is based on timer idle status bit.
I am worried that, this is the only option we have.
Why not use device-tree to indicate the presence of a 32k clock source?
This seems like a board level configuration and so device-tree seems to
be the perfect place for this IMO.
I think I agree with you, but for this to happen in clean way, its time to
start populating clock-nodes in DT, don't you think? Something like,
clocks {
rtc_clk: clk@X {
compatible = crystal-32k, per-32k, xyz;
clock-frequency = 32768;
};
...
};
Timer {
ref-clock = rtc_clk;
};
What do you think?
That's indeed the proper way to do it, since this is a pure board level
parameter and we do have the binding to express that.
We just have to add that in the DTS:-)
Regards,
Benoit
--
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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Op 5 nov. 2012, om 21:40 heeft Grant Likely grant.lik...@secretlab.ca het volgende geschreven: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. I think the beaglebone use cases cover it as well, but it deserves a seperate mention: SOMs. Gumstix is a good example of those, their website has a list of the different expansionboards they sell so we can see if we missed a use case somewhere. Their expansionboards have an EEPROM to ID them, just like the beagleboard classic/xM expansionboards, but I don't know if all 3rd party vendors honour that standard. I know the Ettus USRP E-100 on my desk has it. 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Interesting. This just came up internally at NVIDIA within the last couple weeks, and was discussed on the U-Boot mailing list very recently too: http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 (it spills into the November archive too) For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at I don't know if you're maintaining this as a document and taking patches to it, but if so: Sure, why not... http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary for the so split across those two lines. fixed - SHOULD reliably handle changes between different underlying overlays (ie. what happens to existing .dtb overly files if the structure of the dtb it is layered over changes. If not possible, then SHALL detect when the base tree doesn't match and refuse to apply the overlay. Perhaps use (versioned) DT bindings to represent the interface between the two .dts files? See the links to the U-Boot mailing list discussions below? Implementing versioning is conceptually a lot more complex than plain overlays since it means either the kernel or u-boot needs to start filtering the data that it's given. This can get really complex in a hurry. Mitch makes a valid point later in this thread that when it comes to manipulating the data depending on the board then the data overlay model alone doesn't handle it well. I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Suggestions and proposals are definitely welcome here. I didn't find versioning all that difficult TBH. Making the property access functions work sanely with versioning should cover most (if not all) kernel users. Keep non versioned property access function available to possibly users with a prefix for those that need it. - What is the model for overlays? - Can an overlay modify existing properties? - Can an overlay add new properties to existing nodes? - Can an overlay delete existing nodes/properties? This proposal is very oriented at an overlay-based approach. I'm not totally convinced that a pure overlay approach (as in how dtc does overlayed DT nodes) will be flexible enough, but would love to be persuaded. Again see below. The way I'm currently thinking about the overlay approach is as a discrete set of changes that all can be applied at once.* That certainly doesn't preclude the change being generated with a script or other tool in either firmware or userspace. For most changes it works really well. Of the scenarios that don't work well, I can think of two. The first is it moving or renaming existing nodes, and the second is if the structure of the base tree changes (say due to a firmware update). Although the second limitation is specifically with binary .dtb overlays. Recompiling the dts overlay against the new tree would work fine.** Atomicity should be handled correctly. I can't imagine how hard would be to back out a semi-applied overlay without some kind of core DT tracking support. Leaving it to the driver/user is too difficult to get right. About moving and renaming nodes, I can't think of a user-case today that needs it. Perhaps it can be handled by removal re-insertion? *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. ** all this is based on my current ideas about the .dtb overlay format which would be trivial to implement, but I'm not committed to that approach just yet. The above problems could be solved. It may be sufficient to solve it by making the phandle values less volatile. Right now dtc generates phandles linearly. Generated phandles could be overridden with explicit phandle properties, but it isn't a fantastic solution. Perhaps generating the phandle from a hash of the node name would be sufficient. Node names don't have to be unique though right; perhaps hash the path-name instead of the node-name? But then, why not just reference by path name;
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 9, 2012, at 7:02 PM, Grant Likely wrote: On Wed, Nov 7, 2012 at 12:54 AM, Mitch Bradley w...@firmworks.com wrote: On 11/6/2012 12:37 PM, Stephen Warren wrote: This proposal is very oriented at an overlay-based approach. I'm not totally convinced that a pure overlay approach (as in how dtc does overlayed DT nodes) will be flexible enough, but would love to be persuaded. Again see below. An overlay approach will not be powerful enough to solve the sorts of problems that occur when a product goes into full production, becomes a family, and starts to evolve. Issues like second-source parts that aren't quite compatible and need to be detected and reported, board-stuff options for different customer profiles, speed grades of parts that aren't properly probeable but instead need to be identified by some subterfuge, the list of tedious issues goes on and on. It's nice to pretend that the world fits into a few coherent simple use cases, but 30 years of experience shipping computer product families proves otherwise. You need a programming language to solve the full set of problems - which I why the device tree is designed so it can be generated and modified by a program. I'm not going to argue with that. There is nothing saying that the overlay wouldn't be generated or applied by a script. However, I do strongly think that the data model needs to be independent of any tool or execution environment used to manipulate it. I certainly am not interested in encoding scripts or bytecode into the tree - the opposite of the approach used by ACPI which must execute AML to even retrieve the device tree. I like the overlay approach because it is conceptually straightforward and provides a working model of how changes could be made from userspace while still being usable by firmware. An alternate approach from userspace would be to use a live virtual filesystem to manipulate the device tree, though that approach only applies to Linux userspace. Firmware would still need its own approach. g. I completely agree here. I certainly wouldn't want to introduce any kind of bytecode or a programming model for manipulating DT. I know OF has a full blown forth interpreter, but that's not what modern DT should be (IMHO). Having DT provide such a programming model will preclude a number of users of accessing it, and on top of that, complexity will increase considerably. When faced with a new problem, vendors will just code a workaround, never bothering fixing it properly. In a nutshell, let's not turn DT into ACPI, please. Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 9, 2012, at 10:33 PM, Grant Likely wrote: On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: Maybe some extra version match table can just be passed during the board machine_init of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); Would we need explicit of_platform_populate calls if we have node modification notifiers? In that case the notifier would pick it up automatically, and can do the per version matching internally. There still needs to be something to register everything below this node is interesting which is exactly what of_platform_populate() does now. I see the notifiers being used by the of_platform_populate backend to know when nodes have been created (or destroyed). g. I see. So of_platform_populate could just register the notifier and not do the tree walk itself. Perhaps the name is a bit misleading then? Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 9, 2012, at 11:22 PM, Grant Likely wrote: On Fri, Nov 9, 2012 at 5:32 AM, Joel A Fernandes agnel.j...@gmail.com wrote: Hi Pantelis, I hope I'm not too late to reply as I'm traveling. On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Joanne has purchased one of Jane's capes and packaged it into a rugged case for data logging. As far as Joanne is concerned, the BeagleBone and cape together are a single unit and she'd prefer a single monolithic FDT instead of using an FDT overlay. Option A: Using dtc, she uses the BeagleBone and cape .dts source files to generate a single .dtb for the entire system which is loaded by U-Boot. -or- Unlikely. Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files (instead of .dts files), -or- Possible but low probability. Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. I love Grant's hashing idea a lot keeping the phandle problem for compile time and not requiring fixups. IMO it is still a cleaner approach if u-boot does the simple tree merging for all cases, and not the kernel reasons mentioned below. I'm more than sufficiently convinced that making changes at runtime from userspace is pretty much required. Also consider: it is order of magnitudes easier to modify the kernel than it is to change the firmware for end users. Complete agreement here. (1) From a development standpoint, very little or nothing will have to be changed in kernel (except for scripts/dtc) considering we are moving forward with hashing. (2) Also this discussed a while back but at some point is going to brought up again- loading of dt fragment directly from EEPROM and merging at run time. If we were to implement this in kernel, we would have to add cape specific EEPROM reading code, merge the tree before it is unflattened and parse. Unless it is required for boot to userspace I'm not considering merging before userspace starts. That's well after the tree is unflattened into the live form. If it is require to boot then I agree that is should be done in firmware. I see zero problem with having a beaglebone specific cape driver that knows to read the eeprom and request a specific configuration file. Heck, the kernel doesn't even need to parse the eeprom data. It can be read from userspace and userspace decides which overlay to provide. There's nothing stopping userspace from reading the eeprom, looking up the correct dts for the board, downloading the file from the Internet, compiling it with dtc and installing it and yes that is getting a little extreme. We're trying to come up with the method that will work best for us. From an ease of use perspective, having a kernel driver doing the probing and performing the DT fragment insertion looks the best. It's especially nice for the manufacturer, since he can make sure that when he ships a board a single kernel image will contain everything with no possibility of RMAs. For h/w prototyping, where the user is tinkering around with his own design, the user space approach would be best. The downloading over the internet DTS file, is a bit extreme for now :) I think doing tree merging in kernel is messy and we should do it in uboot considering we might have to read EEPROM for this use case. Ideally reading the fragment from the EEPROM for all capes and merging without worrying about version detection, Doing the merge and passing the merged blob to the kernel which (kernel) works the same way it does today. It may be sufficient to solve it by making the phandle values less volatile. Right now dtc generates phandles linearly. Generated phandles could be overridden with explicit phandle properties, but it isn't a fantastic solution. Perhaps generating the phandle from a hash of the node name would be sufficient. I doubt the hash method will work reliably. We only have 32 bits to work with, nothing like the SHA hashes of git. I was wondering I have worked with kernel's crypto code in the past to generate 32 bit md5sums of 1000s of dataitems, from what I've seen, collisions are rare and since we are talking about just a few nodes that are being referenced in the base dt. I think the probability is even less (ofcourse such an analysis strongly depends on dataset). this method also takes away a lot of complexity with having it to do runtime fixups and will help us get off the ground quickly. It wouldn't be hard to put together a test and run it on all the .dts files in the kernel; generating md5 sums for all the full_name paths and seeing if we've got any collisions yet. We can also
Re: [PATCH 0/3] OMAPDSS: DISPC: Writeback fixes
On 2012-11-07 08:15, Archit Taneja wrote: Some issues were found in the DISPC driver when performing scaling with writeback pipeline. This series fixes those issues. Reference tree: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 3.8/writeback_fixes_dispc Archit Taneja (3): OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipeline OMAPDSS: DISPC: Don't allow predecimation for writeback OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for writeback drivers/video/omap2/dss/dispc.c | 39 +++ 1 file changed, 27 insertions(+), 12 deletions(-) Thanks, looks ok. I'll apply to omapdss tree. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] OMAPDSS: APPLY: Misc Fixes
On 2012-11-07 11:17, Archit Taneja wrote: This series resolves a few minor issues with APPLY. Tested on a 4430sdp, checked switching overlays between DSI command mode and HDMI displays for any unexpected behavior. Reference tree: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 3.8/apply_fixes Archit Taneja (3): OMAPDSS: APPLY: Don't treat an overlay's channel out as shadow bits OMAPDSS: APPLY: Remove unnecessary variable in dss_apply_irq_handler OMAPDSS: APPLY: Remove unnecessary call to mg_clear_shadow_dirty drivers/video/omap2/dss/apply.c | 48 +-- 1 file changed, 26 insertions(+), 22 deletions(-) Thanks, looks ok. I'll apply to omapdss tree. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen,
On Nov 10, 2012, at 12:57 AM, Stephen Warren wrote:
On 11/08/2012 07:26 PM, David Gibson wrote:
...
I also think graft will handle most of your use cases, although as I
said I don't fully understand the implications of some of them, so I
could be wrong. So, the actual insertion of the subtree is pretty
trivial to implement. phandles are the obvious other matter to be
dealt with. I haven't found the right thread where what you've
envisaged so far is discussed, so here are things I can see:
1) Avoiding phandle collisions between main tree and subtree (or
between subtrees).
I'm hopeful that this can be resolved just by establishing some
conventions about the ranges of phandles to be used for various
components. I'd certainly be happy to add a directive to dtc which
enforces allocation of phandles within a specified range.
One case I wonder about is:
Base board A that's split into two .dts files e.g. due to there being
two versions of the base board which are 90% identical, yet there being
a few differences between them.
Base board B that's just a single .dts file.
We might allocate phandle range 0..999 for the base board.
Child board X plugs into either, so the two base boards need to export
the same set of phandle IDs to the child board to allow it to reference
them.
If base board A version 2 comes along after the phandle IDs that the
child board uses are defined, then how do we handle assigning a specific
phandle ID range to each of base board A's two version-specific
overlays, when the version-specific changes might affect arbitrary
phandle IDs within the range, and require some to be moved into the base
board version-specific overlays and some to stay in the common base
board .dts?
Static phandle allocation, could work, but not without considerable trouble.
Maybe we're over-engineering things. Perhaps having the kernel use the
phandle values generated by dtc is not required.
What about the following simple scheme:
1) Have dtc create local phandle values the same way, as it is today.
Generate the flat tree normally, but keep in a table the locations
of all phandle references. Keep track of non resolvable phandle references
in a different table. One could use the fixup mechanism I described in
a previous email, if you don't care about keeping a big table.
2) Upon loading the base DT or the overlay, the kernel makes sure the phandles
don't overlap; simply add a per DT fragment constant offset.
3) Resolve phandle references that were unresolved at compile time.
2) Resolving phandle references within a subtree
If we can handle (1) by convention, we don't need anything here, the
references are fine as is.
(3) Resolving phandle references from the subtree to the main tree.
So, I think this can actually be avoided, at least in cases where what
physical connections are available to the expansion module is well
defined. The main causes to have external references are interrupts
and gpios. Interrupts we handle by defining an interrupt specifier
space for the interrupts available on the expansion
socket/connector/bus/whatever. In the master tree we then have
something like:
...
expansion-socket@ {
expansion-id = SlotA;
interrupt-map = /* map expansion irq specs to
board interrupt controllers */ ;
interrupt-map-mask = ... ;
ranges = /* map expansion local addresses to global
mmio */ ;
};
We would end up needing an interrupt-map or ranges type of property for
basically any resource type.
For example, what about an I2C bus that's routed to the daughter board,
and the daughter board contains an I2C bus mux, whose control path isn't
through I2C but rather GPIOs? In this case, the I2C bus mux isn't a
child of the I2C bus, but a separate entity that indicates its parent
I2C bus using a phandle. I presume a similar argument applies to almost
any kind of resource. This is probably do-able, but certainly something
to consider with the socket approach. I do like the socket approach though.
Capebus has taken this approach.
You see, perhaps from the standpoint of the standard platform devices that
a cape provides, a bus is not a very fitting construct.
But from a hardware engineer/user perspective, a cape is an expansion board,
and virtual slots are used. This is similar to what you're saying
with socket approach, right?
Regards
-- Pantelis
--
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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote: On 11/09/2012 09:28 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: ... I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. From your perspective, is it important to use the exact same .dtb overlays for those add-on boards, or is it okay to have a separate build of the overlay for each base tree? I certainly think it'd be extremely beneficial to use the exact same child board .dtb with arbitrary base boards. Oh yes. In fact if one was to use a single kernel image for beagleboard and beaglebone, for the cape to work for both, it is required for it's dtb to be compatible. We're not there yet, but people would like to have an upgrade path. beaglebone - beagleboard - pandaboard - future-boards It is not possible yet, but perhaps newer boards could have that. Consider something like the Arduino shield connector format, which I /believe/ has been re-used across a wide variety of Arduino boards and other compatible or imitation boards. Now consider a vendor of an Arduino shield. The shield vendor probably wants to publish a single .dtb file that works for users irrespective of which board they're using it with. (Well, I'm not sure that Arduino can run Linux; perhaps that's why you picked BeagleBone capes for your document!) Arduino can't possible do it. Using arduino shields with an adapter could be possible though. I suppose it would be acceptable for the shield vendor to ship the .dts file rather than the .dtb, and hence need to build the shield .dtb for a specific base board. However, I think the process for an end-user needs to be as simple as drop this .dts/.dtb file into some standard directory, and I imagine it'll be much easier for distros/... to make that process work if they're dealing with a .dtb that they can just blast into the kernel's firmware loader interface, rather than having to also locate the base-board .dts/.dtb file, and run dtc and/or other tools on both .dts files together. Yes. A single supported dtb is the way to go ideally. Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Joel, Again, sorry for the late reply due to travel. On Nov 10, 2012, at 5:36 AM, Joel A Fernandes wrote: Hi Pantelis, On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. I love Grant's hashing idea a lot keeping the phandle problem for compile time and not requiring fixups. IMO it is still a cleaner approach if u-boot does the tree merging for all cases, and not the kernel. That way from a development standpoint, very little or nothing will have to be changed in kernel (except for scripts/dtc) considering we are moving forward with hashing. Also this discussed a while back but at some point is going to brought up again- loading of dt fragment directly from EEPROM and merging at run time. If we were to implement this in kernel, we would have to add cape specific EEPROM reading code, merge the tree before it is unflattened and parse. I think doing tree merging in kernel is messy and we should do it in uboot. Ideally reading the fragment from the EEPROM for all capes and merging without worrying about version detection, Doing the merge and passing the merged blob to the kernel which (kernel) works the same way it does today. Not going to work, for a lot of cases. Doing it in the kernel seems to be the cleaner option. There are valid use cases for doing in u-boot too. True, if dynamic runtime stuff from userspace is what we're talking about, then yeah I see the important need for kernel to do the merge. Kernel doing the merge is our use case, and I feel it's the use case of about 90% of users. u-boot doing the merge is the rest. Alternatively to hashing, reading david gibsons paper I followed, phandle is supposed to 'uniquely' identity node. I wonder why the node name itself is not sufficient to unquiely identify. The code that does the tree walking can then just strcmp the node name while it walks the tree instead of having to find a node with a phandle number. I guess the reason is phandles are small to store as data values. Another approach can be to arrange the string block in alphabetical order (unless it already is), and store phandle as index of the node name referenced relative to the starting of the strong block. This will not affect nodes in dtb being moved around since they will still have the same index value. the problem being adding or removing nodes Changes the offsets of all other nodes in the string block as well.. Hmm. This is pretty radical change to the DT format, no? Yes, true and the only way hypothetically to replace the phandle tree-walking mechanism is to store node paths instead of phandle which David pointed is too long to store, so I guess this wont work after all. Anyway this was an interesting exercise, thanks. It is always nice to have a fresh perspective. Thank you. Regards, Joel Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Rob. On Nov 11, 2012, at 10:47 PM, Rob Landley wrote: On 11/09/2012 10:28:59 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Speaking of which... I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. And I'd like to write up an article on doing it as a learning exercise. Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) Rob It should be possible when the stuff we're talking about is ready. I don't know what you'll find is broken during the exercise, but I guess your article is going to be entertaining at least :) Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Mon, Nov 12, 2012 at 11:34 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Grant, On Nov 9, 2012, at 10:33 PM, Grant Likely wrote: On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: Maybe some extra version match table can just be passed during the board machine_init of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); Would we need explicit of_platform_populate calls if we have node modification notifiers? In that case the notifier would pick it up automatically, and can do the per version matching internally. There still needs to be something to register everything below this node is interesting which is exactly what of_platform_populate() does now. I see the notifiers being used by the of_platform_populate backend to know when nodes have been created (or destroyed). g. I see. So of_platform_populate could just register the notifier and not do the tree walk itself. Perhaps the name is a bit misleading then? Kind of, yes. of_platform_populate() would still have the same effect that it does now except that it would also pay attention to additions and removals from the DT nodes it is interested in. This would work cleanly enough for node additions/removals, but it wouldn't process changes to properties on existing nodes. g. -- 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/3] mmc: omap_hsmmc: Fix Oops in case of data errors
commit ae4bf788ee9bf7c2d51b0309117d1fcccbdd50a2
mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ
sets both end_cmd and end_trans to 1.
Setting end_cmd to 1 for Data Timeout/CRC leads to NULL pointer dereference of
host-cmd as the command complete has previously been handled.
Set end_cmd only in case of command Timeout/CRC.
Moreover host-cmd-error should not be updated on data error case, only
host-data-error needs to be updated.
Signed-off-by: Balaji T K balaj...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fedd258..245d7b5 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -968,10 +968,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
__func__);
}
-static void hsmmc_command_incomplete(struct omap_hsmmc_host *host, int err)
+static void hsmmc_command_incomplete(struct omap_hsmmc_host *host,
+ int err, int end_cmd)
{
omap_hsmmc_reset_controller_fsm(host, SRC);
- host-cmd-error = err;
+ if (end_cmd) {
+ if (host-cmd)
+ host-cmd-error = err;
+ }
if (host-data) {
omap_hsmmc_reset_controller_fsm(host, SRD);
@@ -990,14 +994,16 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
if (status ERR) {
omap_hsmmc_dbg_report_irq(host, status);
+
+ if (status (CMD_TIMEOUT | CMD_CRC))
+ end_cmd = 1;
if (status (CMD_TIMEOUT | DATA_TIMEOUT))
- hsmmc_command_incomplete(host, -ETIMEDOUT);
+ hsmmc_command_incomplete(host, -ETIMEDOUT, end_cmd);
else if (status (CMD_CRC | DATA_CRC))
- hsmmc_command_incomplete(host, -EILSEQ);
+ hsmmc_command_incomplete(host, -EILSEQ, end_cmd);
- end_cmd = 1;
if (host-data || host-response_busy) {
- end_trans = 1;
+ end_trans = !end_cmd;
host-response_busy = 0;
}
}
--
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
[PATCH v3 3/3] mmc: omap_hsmmc: update error code for response_busy cmd
update error code to cmd-error for commands with response_busy and no data
Signed-off-by: Balaji T K balaj...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d931e08..352e18e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -980,8 +980,9 @@ static void hsmmc_command_incomplete(struct omap_hsmmc_host
*host,
if (host-data) {
omap_hsmmc_reset_controller_fsm(host, SRD);
omap_hsmmc_dma_cleanup(host, err);
+ } else if (host-mrq host-mrq-cmd) {
+ host-mrq-cmd-error = err;
}
-
}
static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host, int status)
--
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
[PATCH v3 0/3] mmc: omap_hsmmc: fixes for irq error handler
Balaji T K (3): mmc: omap_hsmmc: Fix Oops in case of data errors mmc: omap_hsmmc: no reset of cmd state machine for DCRC mmc: omap_hsmmc: update error code for response_busy cmd drivers/mmc/host/omap_hsmmc.c | 23 +++ 1 files changed, 15 insertions(+), 8 deletions(-) based on mmc-fixes-for-3.7-rc5 in mmc_next Since v1: split into 3 patches Address comments from Felipe Balbi -- 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
[PATCH v3 2/3] mmc: omap_hsmmc: no reset of cmd state machine for DCRC
Avoid soft reset of command internal state machine on data errors.
Signed-off-by: Balaji T K balaj...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 245d7b5..d931e08 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -971,8 +971,8 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
static void hsmmc_command_incomplete(struct omap_hsmmc_host *host,
int err, int end_cmd)
{
- omap_hsmmc_reset_controller_fsm(host, SRC);
if (end_cmd) {
+ omap_hsmmc_reset_controller_fsm(host, SRC);
if (host-cmd)
host-cmd-error = err;
}
--
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: [PATCH] mmc: hsmmc: Fix NULL pointer dereference on unload when booted with device tree
On Friday 09 November 2012 11:55 PM, Tony Lindgren wrote: When booting with device tree, we don't have any pdata, and will get the following when trying to unload omap_hsmmc: Unable to handle kernel NULL pointer dereference at virtual address 0044 pgd = edafc000 *pgd=adbbd831, *pte=, *ppte= SMP ARM Modules linked in: omap_hsmmc(-) omap_serial pinctrl_single CPU: 1Not tainted (3.7.0-rc4-00044-g8ca5f6a-dirty #245) PC is at omap_hsmmc_gpio_free+0x8/0x3c [omap_hsmmc] LR is at omap_hsmmc_remove+0xf0/0x174 [omap_hsmmc] snip Signed-off-by: Tony Lindgren t...@atomide.com --- This is against v3.7-rc4, would be nice to get in during the -rc cycle. Hi Tony, Got fixed by below commit, merged in rc5 http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=9ea28ecbeb090159a3383ff60b29dee00c489774 -- 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] omap_vout: remove cpu_is_* uses
Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based on current omapdss master branch, which has the omapdss version code. The omapdss version code is queued for v3.8. I'm not sure which is the best way to handle these patches due to the dependency to omapdss. The easiest option is to merge these for 3.9. There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP dependency in the omap_vout driver. I'm not going to touch that, as it doesn't look as trivial as this cpu_is_* removal, and I don't have much knowledge of the omap_vout driver. Compiled, but not tested. Tomi Tomi Valkeinen (2): [media] omap_vout: use omapdss's version instead of cpu_is_* [media] omap_vout: remove extra include drivers/media/platform/omap/omap_vout.c|4 +-- drivers/media/platform/omap/omap_voutlib.c | 38 drivers/media/platform/omap/omap_voutlib.h |3 +++ 3 files changed, 32 insertions(+), 13 deletions(-) -- 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 1/2] [media] omap_vout: use omapdss's version instead of cpu_is_*
cpu_is_* class functions create a dependency to OMAP platform code.
omapdss driver, which omap_vout uses, exposes a function to get the
version of the DSS hardware.
To remove the dependency to OMAP platform code this patch changes
omap_vout to use the omapdss version. For most of the checks, the ones
dealing with DSS differences, this is actually more correct than using
cpu_is_* functions. For the check whether VRFB is available or not this
is not really correct, but still works fine.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/media/platform/omap/omap_vout.c|3 +--
drivers/media/platform/omap/omap_voutlib.c | 38
drivers/media/platform/omap/omap_voutlib.h |3 +++
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c
index 3ff94a3..7b1afc8 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -44,7 +44,6 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
-#include plat/cpu.h
#include plat/dma.h
#include video/omapvrfb.h
#include video/omapdss.h
@@ -2064,7 +2063,7 @@ static int __init omap_vout_create_video_devices(struct
platform_device *pdev)
vout-vid_info.id = k + 1;
/* Set VRFB as rotation_type for omap2 and omap3 */
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ if (omap_vout_dss_omap24xx() || omap_vout_dss_omap34xx())
vout-vid_info.rotation_type = VOUT_ROT_VRFB;
/* Setup the default configuration for the video devices
diff --git a/drivers/media/platform/omap/omap_voutlib.c
b/drivers/media/platform/omap/omap_voutlib.c
index 115408b..80b0d88 100644
--- a/drivers/media/platform/omap/omap_voutlib.c
+++ b/drivers/media/platform/omap/omap_voutlib.c
@@ -26,7 +26,7 @@
#include linux/dma-mapping.h
-#include plat/cpu.h
+#include video/omapdss.h
#include omap_voutlib.h
@@ -124,7 +124,7 @@ int omap_vout_new_window(struct v4l2_rect *crop,
win-chromakey = new_win-chromakey;
/* Adjust the cropping window to allow for resizing limitation */
- if (cpu_is_omap24xx()) {
+ if (omap_vout_dss_omap24xx()) {
/* For 24xx limit is 8x to 1/2x scaling. */
if ((crop-height/win-w.height) = 2)
crop-height = win-w.height * 2;
@@ -140,7 +140,7 @@ int omap_vout_new_window(struct v4l2_rect *crop,
if (crop-height != win-w.height)
crop-width = 768;
}
- } else if (cpu_is_omap34xx()) {
+ } else if (omap_vout_dss_omap34xx()) {
/* For 34xx limit is 8x to 1/4x scaling. */
if ((crop-height/win-w.height) = 4)
crop-height = win-w.height * 4;
@@ -196,7 +196,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
if (try_crop.width = 0 || try_crop.height = 0)
return -EINVAL;
- if (cpu_is_omap24xx()) {
+ if (omap_vout_dss_omap24xx()) {
if (try_crop.height != win-w.height) {
/* If we're resizing vertically, we can't support a
* crop width wider than 768 pixels.
@@ -207,9 +207,9 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
}
/* vertical resizing */
vresize = (1024 * try_crop.height) / win-w.height;
- if (cpu_is_omap24xx() (vresize 2048))
+ if (omap_vout_dss_omap24xx() (vresize 2048))
vresize = 2048;
- else if (cpu_is_omap34xx() (vresize 4096))
+ else if (omap_vout_dss_omap34xx() (vresize 4096))
vresize = 4096;
win-w.height = ((1024 * try_crop.height) / vresize) ~1;
@@ -226,9 +226,9 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
}
/* horizontal resizing */
hresize = (1024 * try_crop.width) / win-w.width;
- if (cpu_is_omap24xx() (hresize 2048))
+ if (omap_vout_dss_omap24xx() (hresize 2048))
hresize = 2048;
- else if (cpu_is_omap34xx() (hresize 4096))
+ else if (omap_vout_dss_omap34xx() (hresize 4096))
hresize = 4096;
win-w.width = ((1024 * try_crop.width) / hresize) ~1;
@@ -243,7 +243,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
if (try_crop.width == 0)
try_crop.width = 2;
}
- if (cpu_is_omap24xx()) {
+ if (omap_vout_dss_omap24xx()) {
if ((try_crop.height/win-w.height) = 2)
try_crop.height = win-w.height * 2;
@@ -258,7 +258,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
if (try_crop.height != win-w.height)
try_crop.width = 768;
}
- } else if (cpu_is_omap34xx()) {
+ } else if
[PATCH 2/2] [media] omap_vout: remove extra include
Remove including plat/dma.h which is not needed. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/media/platform/omap/omap_vout.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c index 7b1afc8..a2cc634 100644 --- a/drivers/media/platform/omap/omap_vout.c +++ b/drivers/media/platform/omap/omap_vout.c @@ -44,7 +44,6 @@ #include media/v4l2-device.h #include media/v4l2-ioctl.h -#include plat/dma.h #include video/omapvrfb.h #include video/omapdss.h -- 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 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi, On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: ... 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work? 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. That's a significant change, you should update Documentation/ . What about omapfb.vram, is it still there? Perhaps we also need to select/depend on CMA? -- Gražvydas -- 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: add get_user() support for 8 byte types
On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon will.dea...@arm.com wrote:
On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
From: Rob Clark r...@ti.com
A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/include/asm/uaccess.h | 25 -
arch/arm/lib/getuser.S | 17 -
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 7e1f760..2e3fdb2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
extern int __get_user_1(void *);
extern int __get_user_2(void *);
extern int __get_user_4(void *);
+extern int __get_user_8(void *);
#define __GUP_CLOBBER_1 lr, cc
#ifdef CONFIG_CPU_USE_DOMAINS
@@ -108,6 +109,7 @@ extern int __get_user_4(void *);
#define __GUP_CLOBBER_2 lr, cc
#endif
#define __GUP_CLOBBER_4 lr, cc
+#define __GUP_CLOBBER_8 lr, cc
#define __get_user_x(__r2,__p,__e,__l,__s) \
__asm__ __volatile__ ( \
@@ -122,22 +124,35 @@ extern int __get_user_4(void *);
({ \
unsigned long __limit = current_thread_info()-addr_limit - 1;
\
register const typeof(*(p)) __user *__p asm(r0) = (p);\
- register unsigned long __r2 asm(r2); \
register unsigned long __l asm(r1) = __limit; \
register int __e asm(r0); \
switch (sizeof(*(__p))) { \
- case 1: \
+ case 1: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 1); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 2: \
+ } \
+ case 2: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 2); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 4: \
+ } \
+ case 4: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 4); \
+ x = (typeof(*(p))) __r2;\
+ break; \
+ } \
+ case 8: { \
+ register unsigned long long __r2 asm(r2); \
Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
asm, so the compiler shouldn't care much. For OABI, I think you may have to
do some more work to get the two words where you want them.
Is the question whether the compiler is guaranteed to allocate r2 and
r3 in all cases? I'm not quite sure, I confess to usually trying to
avoid inline asm. But from looking at the disassembly (for little
endian EABI build) it seemed to do the right thing.
The only other idea I had was to explicitly declare two 'unsigned
long's and then shift them into a 64bit x, although I'm open to
suggestions if there is a better way.
+ __get_user_x(__r2, __p, __e, __l, 8); \
+ x = (typeof(*(p))) __r2;\
break; \
+ } \
default: __e = __get_user_bad(); break; \
} \
- x = (typeof(*(p))) __r2;\
__e;\
})
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..d05285c 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
* Inputs: r0 contains the address
*
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
On 2012-11-12 15:39, Grazvydas Ignotas wrote: Hi, On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: ... 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work? Yes. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. That's a significant change, you should update Documentation/ . Ah right. The documentation. I never remember =). What about omapfb.vram, is it still there? Yes. Perhaps we also need to select/depend on CMA? dma_alloc_* funcs work fine without CMA. CMA only makes them work better. Thus I don't think OMAPFB should depend on CMA, but perhaps CMA should be enabled by default in omap2plus_defconfig? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
On 2012-11-12 15:39, Grazvydas Ignotas wrote: Hi, On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: ... 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work? 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. That's a significant change, you should update Documentation/ . I've added the following documentation change: diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS index a564cee..4484e02 100644 --- a/Documentation/arm/OMAP/DSS +++ b/Documentation/arm/OMAP/DSS @@ -285,7 +285,10 @@ FB0 +-- GFX LCD LCD Misc notes -- -OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. +OMAP FB allocates the framebuffer memory using the standard dma allocator. You +can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma +allocator, and if CMA is enabled, you use cma= kernel parameter to increase +the global memory area for CMA. Using DSI DPLL to generate pixel clock it is possible produce the pixel clock of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. @@ -301,11 +304,6 @@ framebuffer parameters. Kernel boot arguments - -vram=size[,physaddr] - - Amount of total VRAM to preallocate and optionally a physical start - memory address. For example, 10M. omapfb allocates memory for - framebuffers from VRAM. - signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Mon, Nov 12, 2012 at 01:46:57PM +, Rob Clark wrote:
On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon will.dea...@arm.com wrote:
On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
@@ -122,22 +124,35 @@ extern int __get_user_4(void *);
({ \
unsigned long __limit = current_thread_info()-addr_limit -
1; \
register const typeof(*(p)) __user *__p asm(r0) = (p);\
- register unsigned long __r2 asm(r2); \
register unsigned long __l asm(r1) = __limit; \
register int __e asm(r0); \
switch (sizeof(*(__p))) { \
- case 1: \
+ case 1: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 1); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 2: \
+ } \
+ case 2: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 2); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 4: \
+ } \
+ case 4: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 4); \
+ x = (typeof(*(p))) __r2;\
+ break; \
+ } \
+ case 8: { \
+ register unsigned long long __r2 asm(r2); \
Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
asm, so the compiler shouldn't care much. For OABI, I think you may have to
do some more work to get the two words where you want them.
Is the question whether the compiler is guaranteed to allocate r2 and
r3 in all cases? I'm not quite sure, I confess to usually trying to
avoid inline asm. But from looking at the disassembly (for little
endian EABI build) it seemed to do the right thing.
I can't recall how OABI represents 64-bit values and particularly whether this
differs between little and big-endian, so I wondered whether you may have to
do some marshalling when you assign x. However, a few quick experiments with
GCC suggest that the register representation matches EABI in regards to word
ordering (it just doesn't require an even base register), although it would
be good to find this written down somewhere...
The only other idea I had was to explicitly declare two 'unsigned
long's and then shift them into a 64bit x, although I'm open to
suggestions if there is a better way.
Can't you just use register unsigned long long for all cases? Even better,
follow what put_user does and use typeof(*(p))?
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..d05285c 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
* Inputs: r0 contains the address
* r1 contains the address limit, which must be preserved
* Outputs: r0 is the error code
- * r2 contains the zero-extended value
+ * r2, r3 contains the zero-extended value
* lr corrupted
*
* No other registers must be altered. (see asm/uaccess.h
@@ -66,6 +66,19 @@ ENTRY(__get_user_4)
mov pc, lr
ENDPROC(__get_user_4)
+ENTRY(__get_user_8)
+ check_uaccess r0, 4, r1, r2, __get_user_bad
Shouldn't you be passing 8 here, so that we validate the correct range?
yes, sorry, I'll fix that
+#ifdef CONFIG_THUMB2_KERNEL
+5: TUSER(ldr)r2, [r0]
+6: TUSER(ldr)r3, [r0, #4]
+#else
+5: TUSER(ldr)r2, [r0], #4
+6: TUSER(ldr)r3, [r0]
+#endif
This doesn't work for EABI big-endian systems.
Hmm, is that true? Wouldn't put_user() then have the same problem?
I dug up the PCS and it seems that we arrange the two halves of the
doubleword to match the ldm/stm memory representation for EABI, so sorry
for the confusion.
I guess __ARMEB__ is the flag for
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Mon, Nov 12, 2012 at 8:38 AM, Will Deacon will.dea...@arm.com wrote:
On Mon, Nov 12, 2012 at 01:46:57PM +, Rob Clark wrote:
On Mon, Nov 12, 2012 at 4:46 AM, Will Deacon will.dea...@arm.com wrote:
On Fri, Nov 09, 2012 at 09:17:33PM +, Rob Clark wrote:
@@ -122,22 +124,35 @@ extern int __get_user_4(void *);
({ \
unsigned long __limit = current_thread_info()-addr_limit -
1; \
register const typeof(*(p)) __user *__p asm(r0) = (p);\
- register unsigned long __r2 asm(r2); \
register unsigned long __l asm(r1) = __limit; \
register int __e asm(r0); \
switch (sizeof(*(__p))) { \
- case 1: \
+ case 1: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 1); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 2: \
+ } \
+ case 2: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 2); \
+ x = (typeof(*(p))) __r2;\
break; \
- case 4: \
+ } \
+ case 4: { \
+ register unsigned long __r2 asm(r2); \
__get_user_x(__r2, __p, __e, __l, 4); \
+ x = (typeof(*(p))) __r2;\
+ break; \
+ } \
+ case 8: { \
+ register unsigned long long __r2 asm(r2); \
Does this matter? For EABI, we'll pass in (r2, r3) and it's all handcrafted
asm, so the compiler shouldn't care much. For OABI, I think you may have to
do some more work to get the two words where you want them.
Is the question whether the compiler is guaranteed to allocate r2 and
r3 in all cases? I'm not quite sure, I confess to usually trying to
avoid inline asm. But from looking at the disassembly (for little
endian EABI build) it seemed to do the right thing.
I can't recall how OABI represents 64-bit values and particularly whether this
differs between little and big-endian, so I wondered whether you may have to
do some marshalling when you assign x. However, a few quick experiments with
GCC suggest that the register representation matches EABI in regards to word
ordering (it just doesn't require an even base register), although it would
be good to find this written down somewhere...
yeah, I was kinda hoping that someone a bit closer to the compiler
would speak up here :-)
The only other idea I had was to explicitly declare two 'unsigned
long's and then shift them into a 64bit x, although I'm open to
suggestions if there is a better way.
Can't you just use register unsigned long long for all cases? Even better,
follow what put_user does and use typeof(*(p))?
typeof(*(p) was my first try but:
register typeof(*(p)) __r2 asm(r2);
gives me the error:
error: read-only variable ‘__r2’ used as ‘asm’ output
I guess because 'const' ends up being part of the typeof *p? I
suppose I could do typeof(x) instead
BR,
-R
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..d05285c 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
* Inputs: r0 contains the address
* r1 contains the address limit, which must be preserved
* Outputs: r0 is the error code
- * r2 contains the zero-extended value
+ * r2, r3 contains the zero-extended value
* lr corrupted
*
* No other registers must be altered. (see asm/uaccess.h
@@ -66,6 +66,19 @@ ENTRY(__get_user_4)
mov pc, lr
ENDPROC(__get_user_4)
+ENTRY(__get_user_8)
+ check_uaccess r0, 4, r1, r2, __get_user_bad
Shouldn't you be passing 8 here, so that we validate the correct range?
yes, sorry, I'll fix that
+#ifdef CONFIG_THUMB2_KERNEL
+5: TUSER(ldr)r2, [r0]
+6: TUSER(ldr)
[PATCH linux-next] ARM: OMAP2: Fix compillation error in cm_common
Fixes the following error: CC arch/arm/mach-omap2/cm_common.o arch/arm/mach-omap2/cm_common.c: In function ‘cm_register’: arch/arm/mach-omap2/cm_common.c:42:11: error: ‘EINVAL’ undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c:42:11: note: each undeclared identifier is reported only once for each function it appears in arch/arm/mach-omap2/cm_common.c:45:11: error: ‘EEXIST’ undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c: In function ‘cm_unregister’: arch/arm/mach-omap2/cm_common.c:66:11: error: ‘EINVAL’ undeclared (first use in this function) make[1]: *** [arch/arm/mach-omap2/cm_common.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi, with today's linux-next the kernel build failed with the abive error for OMAP. Regards, Peter arch/arm/mach-omap2/cm_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c index 3246cef..3fafc27 100644 --- a/arch/arm/mach-omap2/cm_common.c +++ b/arch/arm/mach-omap2/cm_common.c @@ -13,6 +13,7 @@ #include linux/kernel.h #include linux/init.h +#include linux/errno.h #include cm2xxx.h #include cm3xxx.h -- 1.8.0 -- 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: [GIT PULL] musb regression fixes for v3.7-rc4
On Friday 09 November 2012, Tony Lindgren wrote: This series fixes an annoying regression to make MUSB working on omap4 again. Although it's getting rather late for these changes for the -rc cycle, it is important as many devices are using MUSB for charging and connectivity. With the USB PHY changes, MUSB started using the newly added drivers/usb/phy/omap-usb2.c driver introduced by commit 657b306a (usb: phy: add a new driver for omap usb2 phy) that is using the newly introduced drivers/bus/omap-ocp2scp.c introduced by commit 26a84b3e (drivers: bus: add a new driver for omap-ocp2scp). These changes allowed dropping a lot of PHY related code from arch/arm/mach-omap2/omap_phy_internal.c and have it live in the device driver like it should with commit c9e4412a (arm: omap: phy: remove unused functions from omap-phy-internal.c). However, MUSB on omap4 broke with these changes for legacy platform data boot, and now only works with device tree for omap4. Unfortunately we are still few critical bindings away from being able to make omap4 usbale with device tree. Fix the regression properly by adding platform data support to the ocp2scp driver so we can avoid adding back the driver code to arch/arm/mach-omap2. Applied to fixes branch, will send this soon. Arnd -- 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 linux-next] ARM: OMAP2: Fix compillation error in cm_common
Hi On Mon, 12 Nov 2012, Peter Ujfalusi wrote: Fixes the following error: CC arch/arm/mach-omap2/cm_common.o arch/arm/mach-omap2/cm_common.c: In function ‘cm_register’: arch/arm/mach-omap2/cm_common.c:42:11: error: ‘EINVAL’ undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c:42:11: note: each undeclared identifier is reported only once for each function it appears in arch/arm/mach-omap2/cm_common.c:45:11: error: ‘EEXIST’ undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c: In function ‘cm_unregister’: arch/arm/mach-omap2/cm_common.c:66:11: error: ‘EINVAL’ undeclared (first use in this function) make[1]: *** [arch/arm/mach-omap2/cm_common.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi, with today's linux-next the kernel build failed with the abive error for OMAP. Regards, Peter arch/arm/mach-omap2/cm_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c index 3246cef..3fafc27 100644 --- a/arch/arm/mach-omap2/cm_common.c +++ b/arch/arm/mach-omap2/cm_common.c @@ -13,6 +13,7 @@ #include linux/kernel.h #include linux/init.h +#include linux/errno.h #include cm2xxx.h #include cm3xxx.h -- 1.8.0 Acked-by: Paul Walmsley p...@pwsan.com Thanks Peter. Tony, how would you like to handle this one? - Paul
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/09/2012 09:28 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Interesting. This just came up internally at NVIDIA within the last couple weeks, and was discussed on the U-Boot mailing list very recently too: http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 (it spills into the November archive too) For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at I don't know if you're maintaining this as a document and taking patches to it, but if so: Sure, why not... http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary for the so split across those two lines. fixed - SHOULD reliably handle changes between different underlying overlays (ie. what happens to existing .dtb overly files if the structure of the dtb it is layered over changes. If not possible, then SHALL detect when the base tree doesn't match and refuse to apply the overlay. Perhaps use (versioned) DT bindings to represent the interface between the two .dts files? See the links to the U-Boot mailing list discussions below? Implementing versioning is conceptually a lot more complex than plain overlays since it means either the kernel or u-boot needs to start filtering the data that it's given. This can get really complex in a hurry. Mitch makes a valid point later in this thread that when it comes to manipulating the data depending on the board then the data overlay model alone doesn't handle it well. What I was thinking of sounds a lot simpler than what I think you're responding to. All I was thinking about was that we define some kind of explicit interface between .dts files, e.g. some kind of direct representation of the connector between the boards. The versioning aspect is then: Then, when the connector design changes, we change the naming of that interface representation. This would happen in just the same way that we'd name/represent the connector design of a BeagleBone differently from that of an Arduino. So, perhaps we start out with: ti,beaglebone-cape-connector arduino,shield-connector and later end up with: ti,beaglebone-cape-connector-v2 as far as any code that handled/references the v1/v2 interface definitions, they'd probably be completely unrelated types in the general case, just named very similarly. -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 10, 2012, at 1:23 AM, Stephen Warren wrote: On 11/09/2012 09:28 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: ... I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. From your perspective, is it important to use the exact same .dtb overlays for those add-on boards, or is it okay to have a separate build of the overlay for each base tree? I certainly think it'd be extremely beneficial to use the exact same child board .dtb with arbitrary base boards. Oh yes. In fact if one was to use a single kernel image for beagleboard and beaglebone, for the cape to work for both, it is required for it's dtb to be compatible. Well, as Grant pointed out, it's not actually strictly necessary for the .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb can be generated at run-time using dtc for example. Of course, relying on .dts compatibility rather than .dtb compatibility might negatively impact the complexity of an initrd environment if we end up loading overlays from there... We're not there yet, but people would like to have an upgrade path. beaglebone - beagleboard - pandaboard - future-boards It is not possible yet, but perhaps newer boards could have that. -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/12/2012 05:50 AM, Pantelis Antoniou wrote: Hi Rob. On Nov 11, 2012, at 10:47 PM, Rob Landley wrote: On 11/09/2012 10:28:59 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Speaking of which... I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. And I'd like to write up an article on doing it as a learning exercise. Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) Rob It should be possible when the stuff we're talking about is ready. I don't know what you'll find is broken during the exercise, but I guess your article is going to be entertaining at least :) To be honest, I think Rob's proposal should be possible irrespective of this conversation; if he wants to simply define the HW structure once before running qemu, then none of this overlay discussion is relevant. Perhaps the missing piece is the Documentation/devicetree/bindings/ directory? -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. I think this can be solved by deferring the pinmux to the .dts for the child board. Presumably the I2C controller node can be enabled just fine, but the I2C signals not actually routed out to any pins on the SoC until the specific pinmux configuration is loaded. But your explanation still feels a little odd; is it really true on the BeagleBone, you can either use LCD for graphics /or/ you can use the I2C controller to communicate with a cape? I certainly fully understand that from a SoC's perspective (and soc.dtsi perspective) you can't just enable everything due to pinmux constraints, but it seems that once you get to the level of a particular board design, the designer has made those trade-offs and so you know which specific combination is to be selected. -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. I think this can be solved by deferring the pinmux to the .dts for the child board. Presumably the I2C controller node can be enabled just fine, but the I2C signals not actually routed out to any pins on the SoC until the specific pinmux configuration is loaded. Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. So you'll end up hacking the device drivers to handle a weird state that basically means 'don't activate until I tell you to go'. It is simpler just not to create the device. But your explanation still feels a little odd; is it really true on the BeagleBone, you can either use LCD for graphics /or/ you can use the I2C controller to communicate with a cape? I certainly fully understand that from a SoC's perspective (and soc.dtsi perspective) you can't just enable everything due to pinmux constraints, but it seems that once you get to the level of a particular board design, the designer has made those trade-offs and so you know which specific combination is to be selected. There are multiple I2C busses, multiple SPI buses, multiple options to connect something that produces audio, and so on. It is not odd at the least for the kind of market these chips are for. Even TI doesn't know exactly the kind of applications these devices will be used for. The chip is there to provide connection option at a (cheap) price point. Think of a swiss-army knife with some tools that can be used at the same time, and some that can't. Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/12/2012 10:19 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. I think this can be solved by deferring the pinmux to the .dts for the child board. Presumably the I2C controller node can be enabled just fine, but the I2C signals not actually routed out to any pins on the SoC until the specific pinmux configuration is loaded. Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. So you'll end up hacking the device drivers to handle a weird state that basically means 'don't activate until I tell you to go'. It is simpler just not to create the device. But your explanation still feels a little odd; is it really true on the BeagleBone, you can either use LCD for graphics /or/ you can use the I2C controller to communicate with a cape? I certainly fully understand that from a SoC's perspective (and soc.dtsi perspective) you can't just enable everything due to pinmux constraints, but it seems that once you get to the level of a particular board design, the designer has made those trade-offs and so you know which specific combination is to be selected. There are multiple I2C busses, multiple SPI buses, multiple options to connect something that produces audio, and so on. It is not odd at the least for the kind of market these chips are for. Even TI doesn't know exactly the kind of applications these devices will be used for. The chip is there to provide connection option at a (cheap) price point. Think of a swiss-army knife with some tools that can be used at the same time, and some that can't. Yes, I fully understand the flexibility of the SoC; the NVIDIA Tegra SoC I maintain has exactly the same kind of flexibility. However, I'm still thining that presumably the pins that could be used for hypothetical example as any of (a) LCD, (b) I2C controller 2, (c) UART 3 have been routed to the cape-bus connector specifically for the purpose of e.g. I2C controller 2, and hence their usage has been locked in. Is that not the case? Is it instead true that some SoC pins are routed to both an LCD connector /and/ the cape-bus connector so the board itself has a usage conflict, or is it true that the cape-bus connector is in fact just a set of 100 random pins each with no specific pre-defined purpose, and it's up to the cape designer to pick the SoC's pinmux configuration rather than the base board designer? That would make the cape-bus pinout specific to the BeagleBone or the specific SoC on the board, which if IIUC is something very different to the Arduino shield pinout design, where each pin on the connector is designated for a specific purpose, and hence arbitrary
Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses
* Tomi Valkeinen tomi.valkei...@ti.com [121112 05:35]: Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based on current omapdss master branch, which has the omapdss version code. The omapdss version code is queued for v3.8. I'm not sure which is the best way to handle these patches due to the dependency to omapdss. The easiest option is to merge these for 3.9. There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP dependency in the omap_vout driver. I'm not going to touch that, as it doesn't look as trivial as this cpu_is_* removal, and I don't have much knowledge of the omap_vout driver. Compiled, but not tested. Thanks for fixing this. Can you please resend with the selected people cc:d from output of: $ scripts/get_maintainer.pl -f drivers/media/platform/omap So we get the necessary acks. 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Stephen, On Nov 12, 2012, at 7:29 PM, Stephen Warren wrote: On 11/12/2012 10:19 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 7:10 PM, Stephen Warren wrote: On 11/12/2012 10:00 AM, Pantelis Antoniou wrote: Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: ... *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Do we actually need to do that? From the base-board perspective, consider an SoC's I2C channel that is routed to the child board connector. The routing to the connector is always present on the base board. Only the presence (or lack thereof) of devices on that I2C bus is influenced by whether a child board is connected or not, and the design of the child board. Therefore, wouldn't it make sense for the base board to always enable the I2C controller? That would make it easier for someone to hook up a couple wires to the I2C pins and use utilities such as i2cget/set to communicate with it, without going through the whole process of creating a DT to represent the device. This could speed up simple hacking/prototyping and allow it to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. I think this can be solved by deferring the pinmux to the .dts for the child board. Presumably the I2C controller node can be enabled just fine, but the I2C signals not actually routed out to any pins on the SoC until the specific pinmux configuration is loaded. Well, I2C is just an example; same thing happens with SPI, LCD, audio, etc. So you'll end up hacking the device drivers to handle a weird state that basically means 'don't activate until I tell you to go'. It is simpler just not to create the device. But your explanation still feels a little odd; is it really true on the BeagleBone, you can either use LCD for graphics /or/ you can use the I2C controller to communicate with a cape? I certainly fully understand that from a SoC's perspective (and soc.dtsi perspective) you can't just enable everything due to pinmux constraints, but it seems that once you get to the level of a particular board design, the designer has made those trade-offs and so you know which specific combination is to be selected. There are multiple I2C busses, multiple SPI buses, multiple options to connect something that produces audio, and so on. It is not odd at the least for the kind of market these chips are for. Even TI doesn't know exactly the kind of applications these devices will be used for. The chip is there to provide connection option at a (cheap) price point. Think of a swiss-army knife with some tools that can be used at the same time, and some that can't. Yes, I fully understand the flexibility of the SoC; the NVIDIA Tegra SoC I maintain has exactly the same kind of flexibility. However, I'm still thining that presumably the pins that could be used for hypothetical example as any of (a) LCD, (b) I2C controller 2, (c) UART 3 have been routed to the cape-bus connector specifically for the purpose of e.g. I2C controller 2, and hence their usage has been locked in. Is that not the case? Is it instead true that some SoC pins are routed to both an LCD connector /and/ the cape-bus connector so the board itself has a usage conflict, or is it true that the cape-bus connector is in fact just a set of 100 random pins each with no specific pre-defined purpose, and it's up to the cape designer to pick the SoC's pinmux configuration rather than the base board designer? That would make the cape-bus pinout specific to the BeagleBone or the specific SoC on the board, which if IIUC is something very different to the Arduino shield pinout
Re: [PATCH linux-next] ARM: OMAP2: Fix compillation error in cm_common
* Paul Walmsley p...@pwsan.com [121112 08:27]: Hi On Mon, 12 Nov 2012, Peter Ujfalusi wrote: Fixes the following error: CC arch/arm/mach-omap2/cm_common.o arch/arm/mach-omap2/cm_common.c: In function ‘cm_register’: arch/arm/mach-omap2/cm_common.c:42:11: error: ‘EINVAL’ undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c:42:11: note: each undeclared identifier is reported only once for each function it appears in arch/arm/mach-omap2/cm_common.c:45:11: error: ‘EEXIST’ undeclared (first use in this function) arch/arm/mach-omap2/cm_common.c: In function ‘cm_unregister’: arch/arm/mach-omap2/cm_common.c:66:11: error: ‘EINVAL’ undeclared (first use in this function) make[1]: *** [arch/arm/mach-omap2/cm_common.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi, with today's linux-next the kernel build failed with the abive error for OMAP. Regards, Peter arch/arm/mach-omap2/cm_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c index 3246cef..3fafc27 100644 --- a/arch/arm/mach-omap2/cm_common.c +++ b/arch/arm/mach-omap2/cm_common.c @@ -13,6 +13,7 @@ #include linux/kernel.h #include linux/init.h +#include linux/errno.h #include cm2xxx.h #include cm3xxx.h -- 1.8.0 Acked-by: Paul Walmsley p...@pwsan.com Thanks Peter. Tony, how would you like to handle this one? I can queue it. 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 V3 00/13] ARM: OMAP: DMTIMER fixes
This series includes several fixes for the OMAP DMTIMER driver. This is based upon Tony Lindgren's current master branch [1]. Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda. Testing includes ... 1. Booting kernel on above boards 2. Set date and ensuring time of day is correct after 24 hours 3. Checking the timer counter is incrementing when configuring and starting a timer 4. Checking the timer overflow interrupt when timer expires. 5. Using different clock sources to operate the timer with. 6. Running a loop test overnight that continually runs test #3 and #4 for each available timer This has also been boot tested on the AM335x Beagle Bone. V3 changes: - Combined patches #2 and #3 in version 2 series into single patch. - Updated errata i103/i767 workaround to pass errata information via platform data to avoid using cpu_is_() macros in dmtimer driver. [1] http://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git Jon Hunter (13): ARM: OMAP: Add DMTIMER definitions for posted mode ARM: OMAP3+: Implement timer workaround for errata i103 and i767 ARM: OMAP: Fix timer posted mode support ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs ARM: OMAP2+: Don't use __omap_dm_timer_reset() ARM: OMAP: Fix dmtimer reset for timer1 ARM: OMAP: Don't restore of DMTIMER TISTAT register ARM: OMAP: Don't restore DMTIMER interrupt status register ARM: OMAP: Fix spurious interrupts when using timer match feature ARM: OMAP: Add dmtimer interrupt disable function ARM: OMAP: Remove unnecessary call to clk_get() ARM: OMAP: Remove __omap_dm_timer_set_source function arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 15 +++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 41 +-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 + arch/arm/mach-omap2/timer.c| 70 +- arch/arm/plat-omap/dmtimer.c | 77 arch/arm/plat-omap/include/plat/dmtimer.h | 72 +- 6 files changed, 188 insertions(+), 91 deletions(-) -- 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 V3 02/13] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 49 ++-
arch/arm/plat-omap/dmtimer.c |3 +-
arch/arm/plat-omap/include/plat/dmtimer.h | 52 +++--
3 files changed, 93 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a135d28..63229c5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -222,10 +222,24 @@ void __init omap_dmtimer_init(void)
}
}
+/**
+ * omap_dm_timer_get_errata - get errata flags for a timer
+ *
+ * Get the timer errata flags that are specific to the OMAP device being used.
+ */
+u32 __init omap_dm_timer_get_errata(void)
+{
+ if (cpu_is_omap24xx())
+ return 0;
+
+ return OMAP_TIMER_ERRATA_I103_I767;
+}
+
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
int gptimer_id,
const char *fck_source,
- const char *property)
+ const char *property,
+ int posted)
{
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
const char *oh_name;
@@ -311,10 +325,15 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
}
__omap_dm_timer_init_regs(timer);
__omap_dm_timer_reset(timer, 1, 1);
- timer-posted = 1;
- timer-rate = clk_get_rate(timer-fclk);
+ if (posted)
+ __omap_dm_timer_enable_posted(timer);
+
+ /* Check that the intended posted configuration matches the actual */
+ if (posted != timer-posted)
+ return -EINVAL;
+ timer-rate = clk_get_rate(timer-fclk);
timer-reserved = 1;
return res;
@@ -326,7 +345,17 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property);
+ clkev.errata = omap_dm_timer_get_errata();
+
+ /*
+* For clock-event timers we
[PATCH V3 01/13] ARM: OMAP: Add DMTIMER definitions for posted mode
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 17 ++---
arch/arm/plat-omap/include/plat/dmtimer.h |4
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a135d28 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -108,7 +108,7 @@ static int omap2_gp_timer_set_next_event(unsigned long
cycles,
struct clock_event_device *evt)
{
__omap_dm_timer_load_start(clkev, OMAP_TIMER_CTRL_ST,
- 0x - cycles, 1);
+ 0x - cycles, OMAP_TIMER_POSTED);
return 0;
}
@@ -118,7 +118,7 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
{
u32 period;
- __omap_dm_timer_stop(clkev, 1, clkev.rate);
+ __omap_dm_timer_stop(clkev, OMAP_TIMER_POSTED, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
@@ -126,10 +126,10 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
period -= 1;
/* Looks like we need to first set the load value separately */
__omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG,
- 0x - period, 1);
+ 0x - period, OMAP_TIMER_POSTED);
__omap_dm_timer_load_start(clkev,
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
- 0x - period, 1);
+ 0x - period, OMAP_TIMER_POSTED);
break;
case CLOCK_EVT_MODE_ONESHOT:
break;
@@ -359,7 +359,8 @@ static bool use_gptimer_clksrc;
*/
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
- return (cycle_t)__omap_dm_timer_read_counter(clksrc, 1);
+ return (cycle_t)__omap_dm_timer_read_counter(clksrc,
+OMAP_TIMER_POSTED);
}
static struct clocksource clocksource_gpt = {
@@ -373,7 +374,8 @@ static struct clocksource clocksource_gpt = {
static u32 notrace dmtimer_read_sched_clock(void)
{
if (clksrc.reserved)
- return __omap_dm_timer_read_counter(clksrc, 1);
+ return __omap_dm_timer_read_counter(clksrc,
+ OMAP_TIMER_POSTED);
return 0;
}
@@ -455,7 +457,8 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
BUG_ON(res);
__omap_dm_timer_load_start(clksrc,
- OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
+ OMAP_TIMER_POSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(clocksource_gpt, clksrc.rate))
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index f8943c8..1bee0ac 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,10 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE0x02
+/* posted mode types */
+#define OMAP_TIMER_NONPOSTED 0x00
+#define OMAP_TIMER_POSTED 0x01
+
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x8000
#define OMAP_TIMER_ALWON 0x4000
--
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 V3 03/13] ARM: OMAP: Fix timer posted mode support
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the timer-posted variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which was before the
omap_dm_timer_enable_posted() function was introduced. Although this is a
regression from the original code it only impacts performance and so is not
needed for stable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 381a612..10ec31b 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -121,21 +121,16 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- omap_dm_timer_enable(timer);
if (timer-pdev-id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
__omap_dm_timer_reset(timer, 0, 0);
- __omap_dm_timer_enable_posted(timer);
- omap_dm_timer_disable(timer);
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
- int ret;
-
/*
* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
* do not call clk_get() for these devices.
@@ -149,13 +144,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
}
}
+ omap_dm_timer_enable(timer);
+
if (timer-capability OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+ __omap_dm_timer_enable_posted(timer);
+ omap_dm_timer_disable(timer);
- timer-posted = 1;
- return ret;
+ return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
}
static inline u32 omap_dm_timer_reserved_systimer(int id)
--
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 V3 04/13] ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
all 12 instances of the DMTIMER. Please note that this is a difference between
OMAP3 and OMAP4 and could be the source of the confusion.
For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
12 timers. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index abe66ce..fac2550 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -153,28 +153,13 @@ static struct omap_hwmod omap3xxx_debugss_hwmod = {
};
/* timer class */
-static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
- SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
- .sysc_fields= omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
- .name = timer,
- .sysc = omap3xxx_timer_1ms_sysc,
-};
-
static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -224,7 +209,7 @@ static struct omap_hwmod omap3xxx_timer1_hwmod = {
},
},
.dev_attr = capability_alwon_dev_attr,
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer2 */
@@ -241,7 +226,7 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT2_SHIFT,
},
},
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer3 */
@@ -383,7 +368,7 @@ static struct omap_hwmod omap3xxx_timer10_hwmod = {
},
},
.dev_attr = capability_pwm_dev_attr,
- .class = omap3xxx_timer_1ms_hwmod_class,
+ .class = omap3xxx_timer_hwmod_class,
};
/* timer11 */
--
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 V3 05/13] ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs
For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index a0116d0..067fd0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -58,7 +58,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index fac2550..fcce693 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -159,7 +159,8 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
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 V3 08/13] ARM: OMAP: Don't restore of DMTIMER TISTAT register
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c |3 ---
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 4 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d4f9541..320d103 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -83,9 +83,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- if (timer-revision == 1)
- __raw_writel(timer-context.tistat, timer-sys_stat);
-
__raw_writel(timer-context.tisr, timer-irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer-context.twer);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index ac16f1e..2f9fd1d 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -84,7 +84,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tistat;
u32 tisr;
u32 tier;
u32 twer;
--
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 V3 06/13] ARM: OMAP2+: Don't use __omap_dm_timer_reset()
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.
For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
have the fields clock-activity, wakeup-enable and auto-idle and so this
function could configure the OCP_CFG register incorrectly.
Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
register for timers that have this field. Commit 0f0d080 (ARM: OMAP: DMTimer:
Use posted mode) configures the clock-activity field to keep the f-clk enabled
so that the wake-up capability is enabled. Therefore, add the appropriate flags
to the timer HWMOD structures to configure this field in the same way.
For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4
arch/arm/mach-omap2/timer.c|1 -
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 067fd0a..0db8f45 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -60,6 +60,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = CLOCKACT_TEST_ICLK,
.sysc_fields= omap_hwmod_sysc_type1,
};
@@ -268,6 +269,7 @@ struct omap_hwmod omap2xxx_timer1_hwmod = {
},
.dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer2 */
@@ -286,6 +288,7 @@ struct omap_hwmod omap2xxx_timer2_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer3 */
@@ -304,6 +307,7 @@ struct omap_hwmod omap2xxx_timer3_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer4 */
@@ -322,6 +326,7 @@ struct omap_hwmod omap2xxx_timer4_hwmod = {
},
},
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer5 */
@@ -341,6 +346,7 @@ struct omap_hwmod omap2xxx_timer5_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer6 */
@@ -360,6 +366,7 @@ struct omap_hwmod omap2xxx_timer6_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer7 */
@@ -379,6 +386,7 @@ struct omap_hwmod omap2xxx_timer7_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer8 */
@@ -398,6 +406,7 @@ struct omap_hwmod omap2xxx_timer8_hwmod = {
},
.dev_attr = capability_dsp_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer9 */
@@ -417,6 +426,7 @@ struct omap_hwmod omap2xxx_timer9_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer10 */
@@ -436,6 +446,7 @@ struct omap_hwmod omap2xxx_timer10_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class = omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer11 */
@@ -455,6 +466,7 @@ struct omap_hwmod omap2xxx_timer11_hwmod = {
},
.dev_attr = capability_pwm_dev_attr,
.class
[PATCH V3 09/13] ARM: OMAP: Don't restore DMTIMER interrupt status register
Restoring the timer interrupt status is not possible because writing a 1 to any
bit in the register clears that bit if set and writing a 0 has no affect.
Furthermore, if an interrupt is pending when someone attempts to disable a
timer, the timer will fail to transition to the idle state and hence it's
context will not be lost. Users should take care to service all interrupts
before disabling the timer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c |5 +
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 320d103..f0a3c4c 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -83,7 +83,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer-context.tisr, timer-irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer-context.twer);
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG,
@@ -440,7 +439,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
*/
timer-context.tclr =
omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
- timer-context.tisr = __raw_readl(timer-irq_stat);
omap_dm_timer_disable(timer);
return 0;
}
@@ -684,8 +682,7 @@ int omap_dm_timer_write_status(struct omap_dm_timer *timer,
unsigned int value)
return -EINVAL;
__omap_dm_timer_write_status(timer, value);
- /* Save the context */
- timer-context.tisr = value;
+
return 0;
}
EXPORT_SYMBOL_GPL(omap_dm_timer_write_status);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 2f9fd1d..0c07e37 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -84,7 +84,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tisr;
u32 tier;
u32 twer;
u32 tclr;
--
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 V3 13/13] ARM: OMAP: Remove __omap_dm_timer_set_source function
The __omap_dm_timer_set_source() function is only used by the system timer
(clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
remove this code from the dmtimer driver and move it to the system timer
code for OMAP2+ devices.
The current __omap_dm_timer_set_source() function calls clk_disable() before
calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
omap_hwmod_enable() to after the call to clk_set_parent() in
omap_dm_timer_init_one().
The function omap_hwmod_setup_one() will enable the timers functional clock
and therefore increment the use-count of the functional clock to 1.
clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
clk_disable() before calling clk_set_parent() to decrement the use-count.
Hence, avoid these extra calls to disable and enable the functional clock by
moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
clk_set_parent().
We can also remove the delay from the __omap_dm_timer_set_source() function
because enabling the clock will now be handled via the HWMOD framework by
calling omap_hwmod_setup_one(). Therefore, by moving the calls to
omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
clk_set_parent().
It should be safe to move these hwmod calls to later in the
omap_dm_timer_init_one() because other calls to the hwmod layer that occur
before are just requesting resource information.
Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
with the following configurations:
1. CONFIG_OMAP_32K_TIMER=y
2. CONFIG_OMAP_32K_TIMER=y and boot parameter clocksource=gp_timer
3. CONFIG_OMAP_32K_TIMER not set
4. CONFIG_OMAP_32K_TIMER not set and boot parameter clocksource=gp_timer
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c |9 -
arch/arm/plat-omap/dmtimer.c |1 +
arch/arm/plat-omap/include/plat/dmtimer.h | 19 ---
3 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 19765bd..099e406 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -274,9 +274,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
oh_name = name;
}
- omap_hwmod_setup_one(oh_name);
oh = omap_hwmod_lookup(oh_name);
-
if (!oh)
return -ENODEV;
@@ -306,8 +304,6 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(timer-fclk))
return -ENODEV;
- omap_hwmod_enable(oh);
-
/* FIXME: Need to remove hard-coded test on timer ID */
if (gptimer_id != 12) {
struct clk *src;
@@ -316,13 +312,16 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
if (IS_ERR(src)) {
res = -EINVAL;
} else {
- res = __omap_dm_timer_set_source(timer-fclk, src);
+ res = clk_set_parent(timer-fclk, src);
if (IS_ERR_VALUE(res))
pr_warn(%s: %s cannot set source\n,
__func__, oh-name);
clk_put(src);
}
}
+
+ omap_hwmod_setup_one(oh_name);
+ omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
if (posted)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 305faf5..9deeb30 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -35,6 +35,7 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include linux/clk.h
#include linux/module.h
#include linux/io.h
#include linux/device.h
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 769efb6..05a36e1 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -32,7 +32,6 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include linux/clk.h
#include linux/delay.h
#include linux/io.h
#include linux/platform_device.h
@@ -397,24 +396,6 @@ static inline void __omap_dm_timer_override_errata(struct
omap_dm_timer *timer,
timer-errata = ~errata;
}
-static inline int __omap_dm_timer_set_source(struct clk *timer_fck,
- struct clk *parent)
-{
- int ret;
-
- clk_disable(timer_fck);
- ret = clk_set_parent(timer_fck, parent);
- clk_enable(timer_fck);
-
- /*
-* When the functional clock disappears, too quick
[PATCH V3 11/13] ARM: OMAP: Add dmtimer interrupt disable function
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because the same interrupt
enable register is used to disable interrupts. However, some timer instances
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1,
2 and 10 need this function and for OMAP5 all timers need this function.
Please note that the interrupt disable function has been written so that it
can be used by all OMAP devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 31 +
arch/arm/plat-omap/include/plat/dmtimer.h |3 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index a38e896..b4e6634 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -661,6 +661,37 @@ int omap_dm_timer_set_int_enable(struct omap_dm_timer
*timer,
}
EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_enable);
+/**
+ * omap_dm_timer_set_int_disable - disable timer interrupts
+ * @timer: pointer to timer handle
+ * @mask: bit mask of interrupts to be disabled
+ *
+ * Disables the specified timer interrupts for a timer.
+ */
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
+{
+ u32 l = mask;
+
+ if (unlikely(!timer))
+ return -EINVAL;
+
+ omap_dm_timer_enable(timer);
+
+ if (timer-revision == 1)
+ l = __raw_readl(timer-irq_ena) ~mask;
+
+ __raw_writel(l, timer-irq_dis);
+ l = omap_dm_timer_read_reg(timer, OMAP_TIMER_WAKEUP_EN_REG) ~mask;
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG, l);
+
+ /* Save the context */
+ timer-context.tier = ~mask;
+ timer-context.twer = ~mask;
+ omap_dm_timer_disable(timer);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_disable);
+
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
{
unsigned int l;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 0c07e37..769efb6 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -135,6 +135,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int
def_on, int toggle, i
int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler);
int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer, unsigned int
value);
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask);
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer);
int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int
value);
@@ -321,7 +322,7 @@ static inline void __omap_dm_timer_init_regs(struct
omap_dm_timer *timer)
OMAP_TIMER_V1_SYS_STAT_OFFSET;
timer-irq_stat = timer-io_base + OMAP_TIMER_V1_STAT_OFFSET;
timer-irq_ena = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
- timer-irq_dis = NULL;
+ timer-irq_dis = timer-io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
timer-pend = timer-io_base + _OMAP_TIMER_WRITE_PEND_OFFSET;
timer-func_base = timer-io_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 V3 07/13] ARM: OMAP: Fix dmtimer reset for timer1
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
a fix was added to prevent timer1 being reset in the function
omap_dm_timer_reset() because timer1 was being used as the system timer for
OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 10ec31b..d4f9541 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -121,11 +121,8 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- if (timer-pdev-id != 1) {
- omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
- omap_dm_timer_wait_for_reset(timer);
- }
-
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+ omap_dm_timer_wait_for_reset(timer);
__omap_dm_timer_reset(timer, 0, 0);
}
--
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 V3 10/13] ARM: OMAP: Fix spurious interrupts when using timer match feature
The OMAP DMTIMERs can generate an interrupt when the timer counter value matches the value stored in the timer's match register. When using this feature spurious interrupts were seen, because the compare logic is being enabled before the match value is loaded and according to the documentation the match value must be loaded before the compare logic is enable. The reset value for the timer counter and match registers is 0 and hence, by enabling the compare logic before the actual match value is loaded a spurious interrupt can be generated as the reset values match. Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/plat-omap/dmtimer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index f0a3c4c..a38e896 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -584,8 +584,8 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable, l |= OMAP_TIMER_CTRL_CE; else l = ~OMAP_TIMER_CTRL_CE; - omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); omap_dm_timer_write_reg(timer, OMAP_TIMER_MATCH_REG, match); + omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); /* Save the context */ timer-context.tclr = l; -- 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 V3 12/13] ARM: OMAP: Remove unnecessary call to clk_get()
Whenever we call the function omap_dm_timer_set_source() to set the clock
source of a dmtimer we look-up the dmtimer functional clock source by
calling clk_get(). This is not necessary because on requesting a dmtimer
we look-up the functional clock source and store it in the omap_dm_timer
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index b4e6634..305faf5 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -448,7 +448,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
{
int ret;
char *parent_name = NULL;
- struct clk *fclk, *parent;
+ struct clk *parent;
struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
@@ -467,11 +467,8 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
if (pdata pdata-set_timer_src)
return pdata-set_timer_src(timer-pdev, source);
- fclk = clk_get(timer-pdev-dev, fck);
- if (IS_ERR_OR_NULL(fclk)) {
- pr_err(%s: fck not found\n, __func__);
+ if (!timer-fclk)
return -EINVAL;
- }
switch (source) {
case OMAP_TIMER_SRC_SYS_CLK:
@@ -490,18 +487,15 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
parent = clk_get(timer-pdev-dev, parent_name);
if (IS_ERR_OR_NULL(parent)) {
pr_err(%s: %s not found\n, __func__, parent_name);
- ret = -EINVAL;
- goto out;
+ return -EINVAL;
}
- ret = clk_set_parent(fclk, parent);
+ ret = clk_set_parent(timer-fclk, parent);
if (IS_ERR_VALUE(ret))
pr_err(%s: failed to set %s as parent\n, __func__,
parent_name);
clk_put(parent);
-out:
- clk_put(fclk);
return ret;
}
--
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 v5 0/6] Move rest of omap-iommu to live in drivers/iommu
Hi, On 11 November 2012 03:39, Ohad Ben-Cohen o...@wizery.com wrote: On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren t...@atomide.com wrote: We need to move the iommu code to live under drivers for arm common zImage support. For the iommu changes in the entire series: Acked-by: Ohad Ben-Cohen o...@wizery.com Joerg, it might relieve some pain if this will go through Tony's tree, as there are some OMAP platform iommu changes coming in from Omar as well (part of which might have already been merged in the omap branches). Hope it's ok with both of you guys? Omar, do you still have any iommu changes coming in ? Yes, I have the hwmod and runtime pm changes for iommu, I was waiting for Tony to publish a branch with these changes to submit (as per Tony's suggestion), but I already have the patches rebased onto these. I will submit them. Cheers, Omar -- 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
[RESEND PATCH v3 5/6] watchdog: omap_wdt: delete redundant platform_set_drvdata() calls
It's not needed to manually reset the driver data. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: Wim Van Sebroeck w...@iguana.be --- drivers/watchdog/omap_wdt.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 7e8d3e0..af1e72e 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -280,7 +280,6 @@ static int __devinit omap_wdt_probe(struct platform_device *pdev) err_misc: pm_runtime_disable(wdev-dev); - platform_set_drvdata(pdev, NULL); return ret; } @@ -306,7 +305,6 @@ static int __devexit omap_wdt_remove(struct platform_device *pdev) pm_runtime_disable(wdev-dev); watchdog_unregister_device(wdog); - platform_set_drvdata(pdev, NULL); return 0; } -- 1.7.2.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
[RESEND PATCH v3 3/6] watchdog: omap_wdt: convert request_mem_region() to devm_request_mem_region()
Use devm_request_mem_region() to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wim Van Sebroeck w...@iguana.be
---
drivers/watchdog/omap_wdt.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index d6722db..45019b0 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -217,15 +217,14 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
if (!res)
return -ENOENT;
- mem = request_mem_region(res-start, resource_size(res), pdev-name);
+ mem = devm_request_mem_region(pdev-dev, res-start,
+ resource_size(res), pdev-name);
if (!mem)
return -EBUSY;
wdev = devm_kzalloc(pdev-dev, sizeof(*wdev), GFP_KERNEL);
- if (!wdev) {
- ret = -ENOMEM;
- goto err_kzalloc;
- }
+ if (!wdev)
+ return -ENOMEM;
omap_wdt-info= omap_wdt_info;
omap_wdt-ops = omap_wdt_ops;
@@ -289,9 +288,6 @@ err_misc:
err_ioremap:
wdev-base = NULL;
-err_kzalloc:
- release_mem_region(res-start, resource_size(res));
-
return ret;
}
@@ -316,7 +312,6 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
pm_runtime_disable(wdev-dev);
watchdog_unregister_device(wdog);
- release_mem_region(res-start, resource_size(res));
platform_set_drvdata(pdev, NULL);
iounmap(wdev-base);
--
1.7.2.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
[RESEND PATCH v3 2/6] watchdog: omap_wdt: convert kzalloc() to devm_kzalloc()
Use devm_kzalloc() to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wim Van Sebroeck w...@iguana.be
---
drivers/watchdog/omap_wdt.c | 23 ++-
1 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index d28ad5e..d6722db 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -208,24 +208,20 @@ static int __devinit omap_wdt_probe(struct
platform_device *pdev)
struct omap_wdt_dev *wdev;
int ret;
- omap_wdt = kzalloc(sizeof(*omap_wdt), GFP_KERNEL);
+ omap_wdt = devm_kzalloc(pdev-dev, sizeof(*omap_wdt), GFP_KERNEL);
if (!omap_wdt)
return -ENOMEM;
/* reserve static register mappings */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- ret = -ENOENT;
- goto err_get_resource;
- }
+ if (!res)
+ return -ENOENT;
mem = request_mem_region(res-start, resource_size(res), pdev-name);
- if (!mem) {
- ret = -EBUSY;
- goto err_busy;
- }
+ if (!mem)
+ return -EBUSY;
- wdev = kzalloc(sizeof(struct omap_wdt_dev), GFP_KERNEL);
+ wdev = devm_kzalloc(pdev-dev, sizeof(*wdev), GFP_KERNEL);
if (!wdev) {
ret = -ENOMEM;
goto err_kzalloc;
@@ -292,14 +288,10 @@ err_misc:
err_ioremap:
wdev-base = NULL;
- kfree(wdev);
err_kzalloc:
release_mem_region(res-start, resource_size(res));
-err_busy:
-err_get_resource:
- kfree(omap_wdt);
return ret;
}
@@ -329,9 +321,6 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
iounmap(wdev-base);
- kfree(wdev);
- kfree(wdog);
-
return 0;
}
--
1.7.2.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
[RESEND PATCH v3 1/6] watchdog: omap_wdt: convert to new watchdog core
Convert omap_wdt to new watchdog core. On OMAP boards, there are usually
multiple watchdogs. Since the new watchdog core supports multiple
watchdogs, all watchdog drivers used on OMAP should be converted.
The legacy watchdog device node is still created, so this should not
break existing users.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Tested-by: Jarkko Nikula jarkko.nik...@jollamobile.com
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Cc: Wim Van Sebroeck w...@iguana.be
---
drivers/watchdog/Kconfig|1 +
drivers/watchdog/omap_wdt.c | 274 ++-
2 files changed, 118 insertions(+), 157 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ad1bb93..a7f5590 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -232,6 +232,7 @@ config EP93XX_WATCHDOG
config OMAP_WATCHDOG
tristate OMAP Watchdog
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+ select WATCHDOG_CORE
help
Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog.
Say 'Y'
here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430
watchdog timer.
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index f5db18db..d28ad5e 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -31,18 +31,14 @@
#include linux/module.h
#include linux/types.h
#include linux/kernel.h
-#include linux/fs.h
#include linux/mm.h
-#include linux/miscdevice.h
#include linux/watchdog.h
#include linux/reboot.h
#include linux/init.h
#include linux/err.h
#include linux/platform_device.h
#include linux/moduleparam.h
-#include linux/bitops.h
#include linux/io.h
-#include linux/uaccess.h
#include linux/slab.h
#include linux/pm_runtime.h
#include mach/hardware.h
@@ -51,24 +47,20 @@
#include omap_wdt.h
-static struct platform_device *omap_wdt_dev;
-
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, initial watchdog timeout (in seconds));
-static unsigned int wdt_trgr_pattern = 0x1234;
-static DEFINE_SPINLOCK(wdt_lock);
-
struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
- int omap_wdt_users;
+ boolomap_wdt_users;
struct resource *mem;
- struct miscdevice omap_wdt_miscdev;
+ int wdt_trgr_pattern;
+ struct mutexlock; /* to avoid races with PM */
};
-static void omap_wdt_ping(struct omap_wdt_dev *wdev)
+static void __omap_wdt_ping(struct omap_wdt_dev *wdev)
{
void __iomem*base = wdev-base;
@@ -76,8 +68,8 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) 0x08)
cpu_relax();
- wdt_trgr_pattern = ~wdt_trgr_pattern;
- __raw_writel(wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
+ wdev-wdt_trgr_pattern = ~wdev-wdt_trgr_pattern;
+ __raw_writel(wdev-wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
/* wait for posted write to complete */
while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) 0x08)
@@ -85,7 +77,7 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
/* reloaded WCRR from WLDR */
}
-static void omap_wdt_enable(struct omap_wdt_dev *wdev)
+static void __omap_wdt_enable(struct omap_wdt_dev *wdev)
{
void __iomem *base = wdev-base;
@@ -99,7 +91,7 @@ static void omap_wdt_enable(struct omap_wdt_dev *wdev)
cpu_relax();
}
-static void omap_wdt_disable(struct omap_wdt_dev *wdev)
+static void __omap_wdt_disable(struct omap_wdt_dev *wdev)
{
void __iomem *base = wdev-base;
@@ -113,18 +105,10 @@ static void omap_wdt_disable(struct omap_wdt_dev *wdev)
cpu_relax();
}
-static void omap_wdt_adjust_timeout(unsigned new_timeout)
-{
- if (new_timeout TIMER_MARGIN_MIN)
- new_timeout = TIMER_MARGIN_DEFAULT;
- if (new_timeout TIMER_MARGIN_MAX)
- new_timeout = TIMER_MARGIN_MAX;
- timer_margin = new_timeout;
-}
-
-static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
+static void __omap_wdt_set_timeout(struct omap_wdt_dev *wdev,
+ unsigned int timeout)
{
- u32 pre_margin = GET_WLDR_VAL(timer_margin);
+ u32 pre_margin = GET_WLDR_VAL(timeout);
void __iomem *base = wdev-base;
/* just count up at 32 KHz */
@@ -136,16 +120,14 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
*wdev)
cpu_relax();
}
-/*
- * Allow only one task to hold it open
- */
-static int omap_wdt_open(struct inode *inode, struct file *file)
+static int omap_wdt_start(struct watchdog_device *wdog)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
+ struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
void __iomem *base = wdev-base;
-
[RESEND PATCH v3 0/6] watchdog: omap_wdt: convert to new watchdog core
Hello, This is a third version of the patch to convert omap_wdt to new watchdog core. On OMAP boards, there are usually multiple watchdogs. Since the new watchdog core supports multiple watchdogs, all watchdog drivers used on OMAP should be converted. This is especially important on devices like Nokia N9 or N800 where multiple watchdogs are present and watchdog HW cannot be disabled on devices available to consumers/hobbyists. I have also done additional cleanups to utilize devres. They are separate patches to make reviewing easier. Please review and consider applying/queueing these patches, perhaps maybe for 3.8. Thanks. Tested on top of 3.7-rc5 on Nokia N950. Patch set history: v3 (https://lkml.org/lkml/2012/10/10/402): Patch 1 rebased on top of current mainline. Added received Tested by -tags. Added patches 2..6. v2 (https://lkml.org/lkml/2012/9/8/134): Fix a bug in the first version of the patch: __omap_wdt_disable() in probe was mistakenly moved outside PM runtime calls. This caused a crash as device was probably accessed with some clocks off. Thanks to Jarkko Nikula jarkko.nik...@bitmer.com for reporting this. v1 (https://lkml.org/lkml/2012/9/4/217): The initial version. Aaro Koskinen (6): watchdog: omap_wdt: convert to new watchdog core watchdog: omap_wdt: convert kzalloc() to devm_kzalloc() watchdog: omap_wdt: convert request_mem_region() to devm_request_mem_region() watchdog: omap_wdt: convert ioremap() to devm_ioremap() watchdog: omap_wdt: delete redundant platform_set_drvdata() calls watchdog: omap_wdt: eliminate goto drivers/watchdog/Kconfig|1 + drivers/watchdog/omap_wdt.c | 329 +-- 2 files changed, 131 insertions(+), 199 deletions(-) -- 1.7.2.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
[RESEND PATCH v3 4/6] watchdog: omap_wdt: convert ioremap() to devm_ioremap()
Use devm_ioremap() to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wim Van Sebroeck w...@iguana.be
---
drivers/watchdog/omap_wdt.c | 14 +++---
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 45019b0..7e8d3e0 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -255,11 +255,9 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
wdev-wdt_trgr_pattern = 0x1234;
mutex_init(wdev-lock);
- wdev-base = ioremap(res-start, resource_size(res));
- if (!wdev-base) {
- ret = -ENOMEM;
- goto err_ioremap;
- }
+ wdev-base = devm_ioremap(pdev-dev, res-start, resource_size(res));
+ if (!wdev-base)
+ return -ENOMEM;
platform_set_drvdata(pdev, omap_wdt);
@@ -283,10 +281,6 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
err_misc:
pm_runtime_disable(wdev-dev);
platform_set_drvdata(pdev, NULL);
- iounmap(wdev-base);
-
-err_ioremap:
- wdev-base = NULL;
return ret;
}
@@ -314,8 +308,6 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
watchdog_unregister_device(wdog);
platform_set_drvdata(pdev, NULL);
- iounmap(wdev-base);
-
return 0;
}
--
1.7.2.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
[RESEND PATCH v3 6/6] watchdog: omap_wdt: eliminate goto
Eliminate a goto to simplify the code.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wim Van Sebroeck w...@iguana.be
---
drivers/watchdog/omap_wdt.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index af1e72e..bee43a9 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -267,8 +267,10 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
__omap_wdt_disable(wdev);
ret = watchdog_register_device(omap_wdt);
- if (ret)
- goto err_misc;
+ if (ret) {
+ pm_runtime_disable(wdev-dev);
+ return ret;
+ }
pr_info(OMAP Watchdog Timer Rev 0x%02x: initial timeout %d sec\n,
__raw_readl(wdev-base + OMAP_WATCHDOG_REV) 0xFF,
@@ -277,11 +279,6 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
pm_runtime_put_sync(wdev-dev);
return 0;
-
-err_misc:
- pm_runtime_disable(wdev-dev);
-
- return ret;
}
static void omap_wdt_shutdown(struct platform_device *pdev)
--
1.7.2.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: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/11/2012 03:16 AM, Igor Grinberg wrote: On 11/08/12 18:20, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [121107 23:15]: On 11/07/12 19:33, Tony Lindgren wrote: I think this should be the default for the timers as that counter does not stop during deeper idle states. Well, it is the default as you can see from the patch. The problem is that for boards that for some reason do not have the 32k wired and rely on MPU/GP timer source, the default will not work and currently there is no way for board to specify which timer source it can use. Yes. I was just wondering if we can avoid patching all the board files by doing it the other way around by introducing a new omap_gp_timer rather than renaming all the existing ones? Is the renaming that bad? One line per machine_desc structure? Of course we can skip the renaming, but then it will be less consistent and will not reflect the actual timer source used. I tried to make it flexible as much as possible and self explanatory. So above are my considerations, but at this point in time I don't really care if we rename them or just add a new one, but we have to get rid of the ugly fall back. I am not sure if you guys disagree, but does it make sense to start thinking about this with regard to device-tree? With device-tree all the boards files will become obsolete and so we need to be able to handle this during boot time and not compile time. We have discussed this in San Diego (remember?) and you actually proposed this way as a solution. Well, may be I took it a bit further than you thought, but this is because the board code cannot know which timer source should be used at runtime and the fall back described below, does not work. Yes thanks I agree we should get rid of that Kconfig option for sure. --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, OMAP2430 sdp2430 board) .handle_irq = omap2_intc_handle_irq, .init_machine = omap_2430sdp_init, .init_late = omap2430_init_late, - .timer = omap2_timer, + .timer = omap2_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, OMAP3430 3430SDP board) .handle_irq = omap3_intc_handle_irq, .init_machine = omap_3430sdp_init, .init_late = omap3430_init_late, - .timer = omap3_timer, + .timer = omap3_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END ... Can't we assume that the default timer is omap[234]_sync32k_timer to avoid renaming the timer entries in all the board files? Hmmm... How will this work with the macros defining the sys_timer structure? I would also not want to hide the exact timer used under the default name. Can't you just add a new sys_timer (or a new macro) for GP only setups? Of course I can... but I tried to create a flexible generic code, so no meter how a board will be wired, you just need to specify which timer source it uses and be done with it. If you are concerned about how a board is wired up (if the 32k is present), then I think that that is best handled via device-tree and we should query device-tree on boot to see what our options are. What do you guys think? Cheers Jon -- 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
[RESEND PATCH v3 0/4] cbus/retu drivers
This patch set introduces drivers for CBUS access and Retu multifunction chip found on Nokia Internet Tablets (770, N800, N810). It would be nice get these patches applied as the functionality of these devices is severely lacking without Retu. E.g. watchdog support is mandatory at least on Nokia N800, you cannot currently run the mainline kernel for longer than ~60 seconds (there is no way to disable the watchdog). Drivers originate from linux-omap cbus branch and have been cleaned up/rewritten around i2c and MFD core. Patches have been tested on top of 3.7-rc5 with Nokia N800 (watchdog feeding works, power off shuts down the device, power button triggers IRQs and input events, loading and unloading retu-pwrbutton module in a loop while manically pressing the power button does not crash the kernel). Changes since the second version (https://lkml.org/lkml/2012/10/31/520): - i2c-cbus: - move i2c-cbus.h under linux/platform_data - retu-mfd - replace retu_pwrbutton_res[0] expression with simpler retu_pwrbutton_res. - retu-pwrbutton: - eliminate struct retu_pwrbutton - delete checks for duplicate events - rework probe to avoid races - disable IRQ before unregister in retu_pwrbutton_remove() to avoid races - eliminate double free in retu_pwrbutton_remove() - add .owner = THIS_MODULE Changes since the first version (https://lkml.org/lkml/2012/9/3/265): - i2c-cbus: - use devres - improve comments - simplify and delete redundant code - refactoring bug fixes on error handling - discard input parameter from cbus_send_bit/data() - retu-mfd: - use devres - use regmap - retu_wdt: use devres - retu-pwrbutton: use devres Changes since the RFC version (http://marc.info/?l=linux-omapm=134618967116737w=2): - added DT support for getting i2c-cbus GPIO pins - merged n8x0 board file changes into i2c-cbus patch - corrected typo in Kconfig for MFD_RETU - added power off functionality to retu-mfd - added IRQ functionality to retu-mfd - added power button key driver - some cleanups Aaro Koskinen (4): i2c: introduce i2c-cbus driver mfd: introduce retu-mfd driver watchdog: introduce retu_wdt driver input: misc: introduce retu-pwrbutton arch/arm/mach-omap2/board-n8x0.c | 42 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-cbus.c | 300 drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile|1 + drivers/input/misc/retu-pwrbutton.c| 102 +++ drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 264 drivers/watchdog/Kconfig | 12 ++ drivers/watchdog/Makefile |1 + drivers/watchdog/retu_wdt.c| 178 +++ include/linux/mfd/retu.h | 22 +++ include/linux/platform_data/i2c-cbus.h | 27 +++ 15 files changed, 980 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/busses/i2c-cbus.c create mode 100644 drivers/input/misc/retu-pwrbutton.c create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 drivers/watchdog/retu_wdt.c create mode 100644 include/linux/mfd/retu.h create mode 100644 include/linux/platform_data/i2c-cbus.h -- 1.7.2.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
[RESEND PATCH v3 3/4] watchdog: introduce retu_wdt driver
Introduce Retu watchdog driver.
Cc: linux-watch...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wim Van Sebroeck w...@iguana.be
---
drivers/watchdog/Kconfig| 12 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/retu_wdt.c | 178 +++
3 files changed, 191 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/retu_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ad1bb93..c3a836d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,18 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config RETU_WATCHDOG
+ tristate Retu watchdog
+ depends on MFD_RETU
+ select WATCHDOG_CORE
+ help
+ Retu watchdog driver for Nokia Internet Tablets (700, N800,
+ N810). At least on N800 the watchdog cannot be disabled, so
+ this driver is essential and you should enable it.
+
+ To compile this driver as a module, choose M here: the
+ module will be called retu_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 572b39b..d2f1c0c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_STMP3XXX_WATCHDOG) += stmp3xxx_wdt.o
obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/retu_wdt.c b/drivers/watchdog/retu_wdt.c
new file mode 100644
index 000..aeb0f39
--- /dev/null
+++ b/drivers/watchdog/retu_wdt.c
@@ -0,0 +1,178 @@
+/*
+ * Retu watchdog driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Amit Kucheria and Michael Buesch.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * 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/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+
+/* Watchdog timer values in seconds */
+#define RETU_WDT_MAX_TIMER 63
+
+struct retu_wdt_dev {
+ struct retu_dev *rdev;
+ struct device *dev;
+ struct delayed_work ping_work;
+};
+
+/*
+ * Since Retu watchdog cannot be disabled in hardware, we must kick it
+ * with a timer until userspace watchdog software takes over. If
+ * CONFIG_WATCHDOG_NOWAYOUT is set, we never start the feeding.
+ */
+static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ schedule_delayed_work(wdev-ping_work,
+ round_jiffies_relative(RETU_WDT_MAX_TIMER * HZ / 2));
+}
+
+static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ cancel_delayed_work_sync(wdev-ping_work);
+}
+
+static void retu_wdt_ping_work(struct work_struct *work)
+{
+ struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
+ struct retu_wdt_dev, ping_work);
+ retu_wdt_ping_enable(wdev);
+}
+
+static int retu_wdt_start(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_disable(wdev);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_stop(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_enable(wdev);
+
+ return 0;
+}
+
+static int retu_wdt_ping(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ wdog-timeout = timeout;
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static const struct watchdog_info retu_wdt_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .identity = Retu
[RESEND PATCH v3 2/4] mfd: introduce retu-mfd driver
Retu is a multi-function device found on Nokia Internet Tablets
implementing at least watchdog, RTC, headset detection and power button
functionality.
This patch implements minimum functionality providing register access,
IRQ handling and power off functions.
Cc: sa...@linux.intel.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/mfd/Kconfig |9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/retu-mfd.c | 264 ++
include/linux/mfd/retu.h | 22
4 files changed, 296 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/retu-mfd.c
create mode 100644 include/linux/mfd/retu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index acab3ef..7528c5e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1044,6 +1044,15 @@ config MFD_PALMAS
If you say yes here you get support for the Palmas
series of PMIC chips from Texas Instruments.
+config MFD_RETU
+ tristate Support for Retu multi-function device
+ select MFD_CORE
+ depends on I2C
+ select REGMAP_IRQ
+ help
+ Retu is a multi-function device found on Nokia Internet Tablets
+ (770, N800 and N810).
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d8ccb63..ad7879f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -138,3 +138,4 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+obj-$(CONFIG_MFD_RETU) += retu-mfd.o
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
new file mode 100644
index 000..7ff4a37
--- /dev/null
+++ b/drivers/mfd/retu-mfd.c
@@ -0,0 +1,264 @@
+/*
+ * Retu MFD driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall and Mikko Ylinen.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * 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/err.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/module.h
+#include linux/regmap.h
+#include linux/mfd/core.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/moduleparam.h
+
+/* Registers */
+#define RETU_REG_ASICR 0x00/* ASIC ID and revision */
+#define RETU_REG_ASICR_VILMA (1 7)/* Bit indicating Vilma */
+#define RETU_REG_IDR 0x01/* Interrupt ID */
+#define RETU_REG_IMR 0x02/* Interrupt mask */
+
+/* Interrupt sources */
+#define RETU_INT_PWR 0 /* Power button */
+
+struct retu_dev {
+ struct regmap *regmap;
+ struct device *dev;
+ struct mutexmutex;
+ struct regmap_irq_chip_data *irq_data;
+};
+
+static struct resource retu_pwrbutton_res[] = {
+ {
+ .name = retu-pwrbutton,
+ .start = RETU_INT_PWR,
+ .end= RETU_INT_PWR,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell retu_devs[] = {
+ {
+ .name = retu-wdt
+ },
+ {
+ .name = retu-pwrbutton,
+ .resources = retu_pwrbutton_res,
+ .num_resources = ARRAY_SIZE(retu_pwrbutton_res),
+ }
+};
+
+static struct regmap_irq retu_irqs[] = {
+ [RETU_INT_PWR] = {
+ .mask = 1 RETU_INT_PWR,
+ }
+};
+
+static struct regmap_irq_chip retu_irq_chip = {
+ .name = RETU,
+ .irqs = retu_irqs,
+ .num_irqs = ARRAY_SIZE(retu_irqs),
+ .num_regs = 1,
+ .status_base= RETU_REG_IDR,
+ .mask_base = RETU_REG_IMR,
+ .ack_base = RETU_REG_IDR,
+};
+
+/* Retu device registered for the power off. */
+static struct retu_dev *retu_pm_power_off;
+
+int retu_read(struct retu_dev *rdev, u8 reg)
+{
+ int ret;
+ int value;
+
+ mutex_lock(rdev-mutex);
+ ret = regmap_read(rdev-regmap, reg, value);
+ mutex_unlock(rdev-mutex);
+
+ return ret ? ret : value;
+}
+EXPORT_SYMBOL_GPL(retu_read);
+
+int retu_write(struct retu_dev *rdev, u8 reg, u16 data)
+{
+ int ret;
+
+ mutex_lock(rdev-mutex);
+ ret = regmap_write(rdev-regmap, reg, data);
+
[RESEND PATCH v3 4/4] input: misc: introduce retu-pwrbutton
Add Retu power button driver.
Cc: linux-in...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/input/misc/Kconfig | 10
drivers/input/misc/Makefile |1 +
drivers/input/misc/retu-pwrbutton.c | 102 +++
3 files changed, 113 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/retu-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..e5be189 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -367,6 +367,16 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_RETU_PWRBUTTON
+ tristate Retu Power button Driver
+ depends on MFD_RETU
+ help
+ Say Y here if you want to enable power key reporting via the
+ Retu chips found in Nokia Internet Tablets (770, N800, N810).
+
+ To compile this driver as a module, choose M here. The module will
+ be called retu-pwrbutton.
+
config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 83fe6f5..4fbee0d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
diff --git a/drivers/input/misc/retu-pwrbutton.c
b/drivers/input/misc/retu-pwrbutton.c
new file mode 100644
index 000..043a12b
--- /dev/null
+++ b/drivers/input/misc/retu-pwrbutton.c
@@ -0,0 +1,102 @@
+/*
+ * Retu power button driver.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Original code written by Ari Saastamoinen, Juha Yrjölä and Felipe Balbi.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * 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/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/input.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+
+#define RETU_STATUS_PWRONX (1 5)
+
+static irqreturn_t retu_pwrbutton_irq(int irq, void *_pwr)
+{
+ bool state;
+ struct input_dev *idev = _pwr;
+ struct retu_dev *rdev = input_get_drvdata(idev);
+
+ state = !(retu_read(rdev, RETU_REG_STATUS) RETU_STATUS_PWRONX);
+ input_report_key(idev, KEY_POWER, state);
+ input_sync(idev);
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit retu_pwrbutton_probe(struct platform_device *pdev)
+{
+ struct retu_dev *rdev = dev_get_drvdata(pdev-dev.parent);
+ struct input_dev *idev;
+ int ret;
+
+ idev = input_allocate_device();
+ if (!idev)
+ return -ENOMEM;
+
+ idev-evbit[0] = BIT_MASK(EV_KEY);
+ idev-keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+ idev-name = retu-pwrbutton;
+
+ platform_set_drvdata(pdev, idev);
+ input_set_drvdata(idev, rdev);
+
+ ret = input_register_device(idev);
+ if (ret 0) {
+ input_free_device(idev);
+ return ret;
+ }
+
+ ret = devm_request_threaded_irq(pdev-dev, platform_get_irq(pdev, 0),
+ NULL, retu_pwrbutton_irq, 0,
+ retu-pwrbutton, idev);
+ if (ret 0)
+ input_unregister_device(idev);
+
+ return ret;
+}
+
+static int __devexit retu_pwrbutton_remove(struct platform_device *pdev)
+{
+ struct input_dev *idev = platform_get_drvdata(pdev);
+
+ disable_irq(platform_get_irq(pdev, 0));
+ input_unregister_device(idev);
+
+ return 0;
+}
+
+static struct platform_driver retu_pwrbutton_driver = {
+ .probe = retu_pwrbutton_probe,
+ .remove = __devexit_p(retu_pwrbutton_remove),
+ .driver = {
+ .name = retu-pwrbutton,
+ .owner = THIS_MODULE,
+ },
+};
[RESEND PATCH v3 1/4] i2c: introduce i2c-cbus driver
Add i2c driver to enable access to devices behind CBUS on Nokia Internet
Tablets.
The patch also adds CBUS I2C configuration for N8x0 which is one of the
users of this driver.
Cc: linux-...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wolfram Sang w.s...@pengutronix.de
---
arch/arm/mach-omap2/board-n8x0.c | 42 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-cbus.c | 300
include/linux/platform_data/i2c-cbus.h | 27 +++
5 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cbus.c
create mode 100644 include/linux/platform_data/i2c-cbus.h
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index d95f727..8e8a09d 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -16,10 +16,12 @@
#include linux/gpio.h
#include linux/init.h
#include linux/io.h
+#include linux/irq.h
#include linux/stddef.h
#include linux/i2c.h
#include linux/spi/spi.h
#include linux/usb/musb.h
+#include linux/platform_data/i2c-cbus.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/platform_data/mtd-onenand-omap2.h
#include sound/tlv320aic3x.h
@@ -39,6 +41,45 @@
#define TUSB6010_GPIO_ENABLE 0
#define TUSB6010_DMACHAN 0x3f
+#if defined(CONFIG_I2C_CBUS) || defined(CONFIG_I2C_CBUS_MODULE)
+static struct i2c_cbus_platform_data n8x0_cbus_data = {
+ .clk_gpio = 66,
+ .dat_gpio = 65,
+ .sel_gpio = 64,
+};
+
+static struct platform_device n8x0_cbus_device = {
+ .name = i2c-cbus,
+ .id = 3,
+ .dev= {
+ .platform_data = n8x0_cbus_data,
+ },
+};
+
+static struct i2c_board_info n8x0_i2c_board_info_3[] __initdata = {
+ {
+ I2C_BOARD_INFO(retu-mfd, 0x01),
+ },
+};
+
+static void __init n8x0_cbus_init(void)
+{
+ const int retu_irq_gpio = 108;
+
+ if (gpio_request_one(retu_irq_gpio, GPIOF_IN, Retu IRQ))
+ return;
+ irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ n8x0_i2c_board_info_3[0].irq = gpio_to_irq(retu_irq_gpio);
+ i2c_register_board_info(3, n8x0_i2c_board_info_3,
+ ARRAY_SIZE(n8x0_i2c_board_info_3));
+ platform_device_register(n8x0_cbus_device);
+}
+#else /* CONFIG_I2C_CBUS */
+static void __init n8x0_cbus_init(void)
+{
+}
+#endif /* CONFIG_I2C_CBUS */
+
#if defined(CONFIG_USB_MUSB_TUSB6010) ||
defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
/*
* Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
@@ -677,6 +718,7 @@ static void __init n8x0_init_machine(void)
gpmc_onenand_init(board_onenand_data);
n8x0_mmc_init();
n8x0_usb_init();
+ n8x0_cbus_init();
}
MACHINE_START(NOKIA_N800, Nokia N800)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e9df461..fdfc222 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -337,6 +337,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CBUS
+ tristate CBUS I2C driver
+ depends on GENERIC_GPIO
+ help
+ Support for CBUS access using I2C API. Mostly relevant for Nokia
+ Internet Tablets (770, N800 and N810).
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cbus.
+
config I2C_CPM
tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
depends on (CPM1 || CPM2) OF_I2C
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 395b516..0a71da5 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CBUS) += i2c-cbus.o
obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
obj-$(CONFIG_I2C_DESIGNWARE_CORE) += i2c-designware-core.o
diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
new file mode 100644
index 000..e6086cf
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cbus.c
@@ -0,0 +1,300 @@
+/*
+ * CBUS I2C driver for Nokia Internet Tablets.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall, Mikko Ylinen and
+ * Felipe Balbi. Converted to I2C driver by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/11/2012 05:28 AM, Igor Grinberg wrote: On 11/08/12 21:16, Jon Hunter wrote: On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote: On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: On 11/08/2012 01:59 AM, Igor Grinberg wrote: [snip] There is no reliable way to determine which source should be used in runtime for boards that do not have the 32k oscillator wired. So thinking about this some more and given that we are moving away from board files, if a board does not provide a 32kHz clock source, then this should be reflected in the device-tree source file for that board. Hence, at boot time we should be able to determine if a 32kHz clock source can be used. Let me feed some more thoughts here :) The way it is being detected currently is based on timer idle status bit. I am worried that, this is the only option we have. Why not use device-tree to indicate the presence of a 32k clock source? This seems like a board level configuration and so device-tree seems to be the perfect place for this IMO. Well, that is what my commit message says... Sorry, but that was not clear to me from whats in the commit message. Should we be doing this now instead of adding all these static timer init functions? Are there any boards today (supported in the kernel that is), that don't support a 32k? If not, then this becomes simpler for the non-DT case and given that boards such as the AM335x will only support DT boot then we can figure out how to detect the presence of the 32k for DT only. Jon -- 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: add get_user() support for 8 byte types
On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
From: Rob Clark r...@ti.com
A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).
NAK.
(I did write a better email explaining all the ins and outs of why this
won't work and why 64-bit get_user isn't possible, but my editor crapped
out and lost all that well written message; I don't fancy typing it all
out again.)
Nevertheless,
int test_ptr(unsigned int **v, unsigned int **p)
{
return get_user(*v, p);
}
produces a warning, and you can't get away from that if you stick 64-bit
support into get_user().
Sorry, 64-bit get_user() is a no-no.
--
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
OMAP baseline test results for v3.7-rc5
Here are some basic OMAP test results for Linux v3.7-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc5/2012081034/ Passing tests - Boot to userspace (9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle (2/4): 3730beaglexm, 37xxevm Failing tests: fixed by posted patches -- Boot tests: * 3530ES3 Beagle: I2C timeouts during userspace init - Intermittent, appears on 5 out of 6 boots here - Aaro Koskinen observes this also on N900 - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc - http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 - http://marc.info/?l=linux-omapm=135197877112220w=2 - Revert posted, pending I2C maintainers: - http://marc.info/?l=linux-arm-kernelm=135221953727077w=2 PM tests: * 3530es3beagle: hangs during off-mode dynamic idle test - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c: - http://marc.info/?l=linux-omapm=135075364705188w=2 - Fixed by http://www.spinics.net/lists/arm-kernel/msg202116.html Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 * 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3) - clock source is from an external I2C-controlled source - must skip reset until the switchover to hwmod late init - http://www.spinics.net/lists/arm-kernel/msg178138.html Failing tests: needing investigation Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierarchical enable/disable in hwmod code - Jon Hunter reports this does not appear with the same X-loader/bootloader on his 4430ES2.3 Panda, so could be ES-level dependent Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test * 4460pandaes: boot fails early - Appears to be due to X-loader problems here - Need to note the X-loader version so we know it's broken PM tests: * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown - Pending re-test vmlinux object size (delta in bytes from test_v3.7-rc4 (3d70f8c617a436c7146ecb81df2265b4626dfe89)): text data bsstotal kernel +500 -80 +492 am33xx_only +456 +160 +472 n800_multi_omap2xxx +424 +160 +440 n800_only_a +16400 +164 omap1_defconfig +16400 +164 omap1_defconfig_1510innovator_only +16400 +164 omap1_defconfig_5912osk_only +940 -80 +932 omap2plus_defconfig +796 -80 +788 omap2plus_defconfig_2430sdp_only +940 +240 +964 omap2plus_defconfig_cpupm +940 -80 +932 omap2plus_defconfig_no_pm +940 +160 +956 omap2plus_defconfig_omap2_4_only +820 +160 +836 omap2plus_defconfig_omap3_4_only +20 +8 +48 +76 rmk_omap3430_ldp_allnoconfig +12400 +124 rmk_omap3430_ldp_oldconfig +20 +8 +48 +76 rmk_omap4430_sdp_allnoconfig +124 +80 +132 rmk_omap4430_sdp_oldconfig - Paul -- 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: add get_user() support for 8 byte types
On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
From: Rob Clark r...@ti.com
A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).
NAK.
(I did write a better email explaining all the ins and outs of why this
won't work and why 64-bit get_user isn't possible, but my editor crapped
out and lost all that well written message; I don't fancy typing it all
out again.)
Nevertheless,
int test_ptr(unsigned int **v, unsigned int **p)
{
return get_user(*v, p);
}
produces a warning, and you can't get away from that if you stick 64-bit
support into get_user().
Actually, it seems like using 'register typeof(x) __r2 asm(r2);'
does avoid that warning..
I don't know if that was the only argument against 64-bit get_user().
But it will at least be inconvenient that get_user() works for 64bit
on x86 but not arm..
BR,
-R
Sorry, 64-bit get_user() is a no-no.
--
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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Mon, Nov 12, 2012 at 3:23 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Grant, Sorry for the late comments, travelling... On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Interesting. This just came up internally at NVIDIA within the last couple weeks, and was discussed on the U-Boot mailing list very recently too: http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227 (it spills into the November archive too) For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at I don't know if you're maintaining this as a document and taking patches to it, but if so: Sure, why not... http://git.secretlab.ca/?p=devicetree-overlays.git;a=summary for the so split across those two lines. fixed - SHOULD reliably handle changes between different underlying overlays (ie. what happens to existing .dtb overly files if the structure of the dtb it is layered over changes. If not possible, then SHALL detect when the base tree doesn't match and refuse to apply the overlay. Perhaps use (versioned) DT bindings to represent the interface between the two .dts files? See the links to the U-Boot mailing list discussions below? Implementing versioning is conceptually a lot more complex than plain overlays since it means either the kernel or u-boot needs to start filtering the data that it's given. This can get really complex in a hurry. Mitch makes a valid point later in this thread that when it comes to manipulating the data depending on the board then the data overlay model alone doesn't handle it well. I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Suggestions and proposals are definitely welcome here. I didn't find versioning all that difficult TBH. Making the property access functions work sanely with versioning should cover most (if not all) kernel users. Keep non versioned property access function available to possibly users with a prefix for those that need it. - What is the model for overlays? - Can an overlay modify existing properties? - Can an overlay add new properties to existing nodes? - Can an overlay delete existing nodes/properties? This proposal is very oriented at an overlay-based approach. I'm not totally convinced that a pure overlay approach (as in how dtc does overlayed DT nodes) will be flexible enough, but would love to be persuaded. Again see below. The way I'm currently thinking about the overlay approach is as a discrete set of changes that all can be applied at once.* That certainly doesn't preclude the change being generated with a script or other tool in either firmware or userspace. For most changes it works really well. Of the scenarios that don't work well, I can think of two. The first is it moving or renaming existing nodes, and the second is if the structure of the base tree changes (say due to a firmware update). Although the second limitation is specifically with binary .dtb overlays. Recompiling the dts overlay against the new tree would work fine.** Atomicity should be handled correctly. I can't imagine how hard would be to back out a semi-applied overlay without some kind of core DT tracking support. Leaving it to the driver/user is too difficult to get right. About moving and renaming nodes, I can't think of a user-case today that needs it. Perhaps it can be handled by removal re-insertion? *with the caveat that not all types of changes are a good idea and we may disallow. For example, is changing properties in existing nodes a good idea? Yes, changing properties is something that we need. One such change is the change of the bus controller 'status' properties to enabled upon insertion of a child device node, and change back to 'on-demand' when all the child device nodes are gone. Some devices will probably have to support on the fly changes that they may not have otherwise supported. An example of a driver that needs to modify it's device based on DT would be an I²C bus speed change. -- 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 00/13] ARM: OMAP: DMTIMER fixes
* Jon Hunter jon-hun...@ti.com [121112 10:22]: This series includes several fixes for the OMAP DMTIMER driver. This is based upon Tony Lindgren's current master branch [1]. You should be able to use omap-for-v3.8/dt as the base now with the cleanup merged there. The master branch is just a merge of the various topic branches, and can't be used as a base for pull requests. Regards, Tony [1] http://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git -- 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 12/11] ARM: OMAP: Fix relative includes for fpga.h
* Benoit Cousson b-cous...@ti.com [121112 02:49]: Hi Tony, After rebasing on top of your omap-for-v3.8/tmp-merge, I realized that this patch is generating a build break due to removal of the fpga.h include from debug-leds.c. arch/arm/plat-omap/debug-leds.c: In function 'fpga_probe': arch/arm/plat-omap/debug-leds.c:114:9: error: 'H2P2_DBG_FPGA_SIZE' undeclared (first use in this function) arch/arm/plat-omap/debug-leds.c:114:9: note: each undeclared identifier is reported only once for each function it appears in It does not appear with the omap2plus_config but will appear if you enable the NEW_LEDS support that enable OMAP_DEBUG_LEDS. I'm not sure why the size is still hard coded. In theory, assuming the resource is properly initialized, resource_size should be usable. The patch below is fixing that. Thanks looks like I missed that one. Applying into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3. 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 V3 00/13] ARM: OMAP: DMTIMER fixes
On 11/12/2012 02:34 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121112 10:22]: This series includes several fixes for the OMAP DMTIMER driver. This is based upon Tony Lindgren's current master branch [1]. You should be able to use omap-for-v3.8/dt as the base now with the cleanup merged there. The master branch is just a merge of the various topic branches, and can't be used as a base for pull requests. Ok, great will base on top of that branch. Cheers Jon -- 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: [GIT PULL 1/1] omap fixes for v3.7-rc4
On Wednesday 07 November 2012, Tony Lindgren wrote: The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc4/fixes-signed for you to fetch changes up to 5dfcb3b58c6c8934dec8898827736a1e26732cdd: Merge tag 'omap-fixes-b2-for-3.7-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.7-rc4/fixes (2012-11-06 09:55:20 -0800) Pulled into fixes branch, sorry for the delay. Arnd -- 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: OMAP3+: DPLL: drop !CONFIG_COMMON_CLK sections
Remove all of the code that is compiled when CONFIG_COMMON_CLK=n in the
OMAP3+ DPLL handling code.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Mike Turquette mturque...@ti.com
Cc: Rajendra Nayak rna...@ti.com
---
This will be merged as part of the OMAP CCF conversion set.
arch/arm/mach-omap2/dpll3xxx.c | 231 +---
1 file changed, 3 insertions(+), 228 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f72dedb..fafb28c 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -43,11 +43,7 @@
/* Private functions */
/* _omap3_dpll_write_clken - write clken_bits arg to a DPLL's enable bits */
-#ifdef CONFIG_COMMON_CLK
static void _omap3_dpll_write_clken(struct clk_hw_omap *clk, u8 clken_bits)
-#else
-static void _omap3_dpll_write_clken(struct clk *clk, u8 clken_bits)
-#endif
{
const struct dpll_data *dd;
u32 v;
@@ -61,11 +57,7 @@ static void _omap3_dpll_write_clken(struct clk *clk, u8
clken_bits)
}
/* _omap3_wait_dpll_status: wait for a DPLL to enter a specific state */
-#ifdef CONFIG_COMMON_CLK
static int _omap3_wait_dpll_status(struct clk_hw_omap *clk, u8 state)
-#else
-static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
-#endif
{
const struct dpll_data *dd;
int i = 0;
@@ -73,11 +65,7 @@ static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
const char *clk_name;
dd = clk-dpll_data;
-#ifdef CONFIG_COMMON_CLK
clk_name = __clk_get_name(clk-hw.clk);
-#else
- clk_name = __clk_get_name(clk);
-#endif
state = __ffs(dd-idlest_mask);
@@ -101,11 +89,7 @@ static int _omap3_wait_dpll_status(struct clk *clk, u8
state)
}
/* From 3430 TRM ES2 4.7.6.2 */
-#ifdef CONFIG_COMMON_CLK
static u16 _omap3_dpll_compute_freqsel(struct clk_hw_omap *clk, u8 n)
-#else
-static u16 _omap3_dpll_compute_freqsel(struct clk *clk, u8 n)
-#endif
{
unsigned long fint;
u16 f = 0;
@@ -150,22 +134,14 @@ static u16 _omap3_dpll_compute_freqsel(struct clk *clk,
u8 n)
* locked successfully, return 0; if the DPLL did not lock in the time
* allotted, or DPLL3 was passed in, return -EINVAL.
*/
-#ifdef CONFIG_COMMON_CLK
static int _omap3_noncore_dpll_lock(struct clk_hw_omap *clk)
-#else
-static int _omap3_noncore_dpll_lock(struct clk *clk)
-#endif
{
const struct dpll_data *dd;
u8 ai;
u8 state = 1;
int r = 0;
-#ifdef CONFIG_COMMON_CLK
pr_debug(clock: locking DPLL %s\n, __clk_get_name(clk-hw.clk));
-#else
- pr_debug(clock: locking DPLL %s\n, __clk_get_name(clk));
-#endif
dd = clk-dpll_data;
state = __ffs(dd-idlest_mask);
@@ -203,11 +179,7 @@ done:
* DPLL3 was passed in, or the DPLL does not support low-power bypass,
* return -EINVAL.
*/
-#ifdef CONFIG_COMMON_CLK
static int _omap3_noncore_dpll_bypass(struct clk_hw_omap *clk)
-#else
-static int _omap3_noncore_dpll_bypass(struct clk *clk)
-#endif
{
int r;
u8 ai;
@@ -216,11 +188,7 @@ static int _omap3_noncore_dpll_bypass(struct clk *clk)
return -EINVAL;
pr_debug(clock: configuring DPLL %s for low-power bypass\n,
-#ifdef CONFIG_COMMON_CLK
__clk_get_name(clk-hw.clk));
-#else
-__clk_get_name(clk));
-#endif
ai = omap3_dpll_autoidle_read(clk);
@@ -243,22 +211,14 @@ static int _omap3_noncore_dpll_bypass(struct clk *clk)
* code. If DPLL3 was passed in, or the DPLL does not support
* low-power stop, return -EINVAL; otherwise, return 0.
*/
-#ifdef CONFIG_COMMON_CLK
static int _omap3_noncore_dpll_stop(struct clk_hw_omap *clk)
-#else
-static int _omap3_noncore_dpll_stop(struct clk *clk)
-#endif
{
u8 ai;
if (!(clk-dpll_data-modes (1 DPLL_LOW_POWER_STOP)))
return -EINVAL;
-#ifdef CONFIG_COMMON_CLK
pr_debug(clock: stopping DPLL %s\n, __clk_get_name(clk-hw.clk));
-#else
- pr_debug(clock: stopping DPLL %s\n, __clk_get_name(clk));
-#endif
ai = omap3_dpll_autoidle_read(clk);
@@ -282,19 +242,11 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
* XXX This code is not needed for 3430/AM35xx; can it be optimized
* out in non-multi-OMAP builds for those chips?
*/
-#ifdef CONFIG_COMMON_CLK
static void _lookup_dco(struct clk_hw_omap *clk, u8 *dco, u16 m, u8 n)
-#else
-static void _lookup_dco(struct clk *clk, u8 *dco, u16 m, u8 n)
-#endif
{
unsigned long fint, clkinp; /* watch out for overflow */
-#ifdef CONFIG_COMMON_CLK
clkinp = __clk_get_rate(__clk_get_parent(clk-hw.clk));
-#else
- clkinp = __clk_get_rate(__clk_get_parent(clk));
-#endif
fint = (clkinp / n) * m;
if (fint 10)
@@ -315,20 +267,12 @@ static void _lookup_dco(struct clk *clk, u8 *dco, u16 m,
u8 n)
* XXX This code is not needed for 3430/AM35xx; can it be optimized
* out in non-multi-OMAP builds for those chips?
*/
-#ifdef
Re: [GIT PULL 1/1] omap plat header removal for v3.8 merge window, part4
On Wednesday 07 November 2012, Tony Lindgren wrote: The following changes since commit a0212796b58061a9716178d261f318925c246643: Merge tag 'omap-cleanup-fixes-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-headers (2012-10-26 13:18:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3-signed for you to fetch changes up to 6ba54ab4a49bbad736b0254aa6bdf0cb83013815: ARM: OMAP: Remove omap_init_consistent_dma_size() (2012-11-06 16:01:19 -0800) These changes deal with the issues of relative includes introduced by the earlier clean-up and clean up few more things for enabling multiplatform support. The multiplatform kernel has been booted on omaps on top of this branch with the work-in-progress patches applied manually. We cannot yet enable the multiplatform support though. We still need the common clock framework patches, some solution for dma-omap.h, and serial-omap.h moved before we can enable it. Pulled into next/headers branch now, sorry for the delay. Arnd -- 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 0/6] Move rest of omap-iommu to live in drivers/iommu
* Omar Ramirez Luna omar.l...@linaro.org [121112 10:42]: Hi, On 11 November 2012 03:39, Ohad Ben-Cohen o...@wizery.com wrote: On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren t...@atomide.com wrote: We need to move the iommu code to live under drivers for arm common zImage support. For the iommu changes in the entire series: Acked-by: Ohad Ben-Cohen o...@wizery.com Joerg, it might relieve some pain if this will go through Tony's tree, as there are some OMAP platform iommu changes coming in from Omar as well (part of which might have already been merged in the omap branches). Hope it's ok with both of you guys? Omar, do you still have any iommu changes coming in ? Yes, I have the hwmod and runtime pm changes for iommu, I was waiting for Tony to publish a branch with these changes to submit (as per Tony's suggestion), but I already have the patches rebased onto these. I will submit them. Assuming Joerg is OK with these changes, I can push them into an immutable branch that Joerg can merge in as needed. Further patches on top of this series can then be queued by Joerg as arch/arm/*omap* and me are then out of the way of iommu development. 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 -next] ARM: OMAP2+: remove duplicated include from board-overo.c
* Wei Yongjun weiyj...@gmail.com [121107 04:55]: From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Thanks applying into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3. 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] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
* Igor Grinberg grinb...@compulab.co.il [12 01:18]: On 11/08/12 18:20, Tony Lindgren wrote: I guess what I'm after is just to avoid renaming the existing timers in the board-*.c files and only rename the ones that need gp timer only. This means: get rid of the 32k to gptimer fall back. I've got your point, will cook something shortly. Thanks that sounds reasonable to me. 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] ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC
* Nishanth Menon n...@ti.com [121108 12:12]:
On 21:28-20121108, Felipe Balbi wrote:
Hi,
On Thu, Nov 08, 2012 at 11:08:50AM -0800, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC. This signal
controls the secure-mode operation of the PMIC. If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.
For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.
To fix, ensure the signal is properly mux'd as output when TWL is
intialized.
This fix is required when using recent versions of u-boot (= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: Kevin Hilman khil...@ti.com
---
Based on v3.7-rc4. Targetted as a fix for v3.7.
A correponding DT fix for this is needed as well, but that will be part
of
a bigger series to get PM working with DT boot and needs to include other
pins like sys_nirq1.
arch/arm/mach-omap2/twl-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 635e109..96cae8b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -73,6 +73,7 @@ void __init omap4_pmic_init(const char *pmic_type,
{
/* PMIC part*/
omap_mux_init_signal(sys_nirq1, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
+ omap_mux_init_signal(fref_clk0_out.sys_drm_msecure, OMAP_PIN_OUTPUT);
omap_pmic_init(1, 400, pmic_type, 7 + OMAP44XX_IRQ_GIC_START,
pmic_data);
/* Register additional devices on i2c1 bus if needed */
not entirely related to $SUBJECT but this essentially means we're
dropping the security feature whenever Linux runs.
Unless we intend to remove RTC driver in it's entirety and implement RTC
time change update in secure driver, current twl rtc driver was never
meant to exist with RTC time updates only in trustzone mode. Neither does
it drop any security feature when ever Linux runs- msecure pin has not
been used for any other purpose to my knowledge with Linux. So, this
change does not change the status quo we are currently in,
Shouldn't we try to change that pin at register write boundaries so we
keep the secure feature enabled until we know we're going to write to
the HW ?
Maybe it could even be done later through pinctrl, perhaps ?
That might be a better solution I agree. We might be locking down to a
specific pin name here, which could potentially change in a future SoC.
The right approach IMHO would be omap_gpio_mux equivalent.
Example change for OMAP5 purely from a board perspective(gerrit warning):
http://review.omapzoom.org/#/c/23819/5/arch/arm/mach-omap2/board-omap5evm.c,unified
Further, depending on how it is hooked on a different board (not that I
have seen any different other than msecure), it might even be hooked on
to another GPIO, making this scenario not scaling to theoretical board
configuration.
Sounds like the discussion is planning for further work and not affecting
this patch. So applying into omap-for-v3.7-rc4/fixes-part2.
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 02/26] ARM: OMAP: hwmod: Fix up hwmod based clkdm accesses
This patch needed to be modified to avoid some sparse warnings; updated
patch follows.
- Paul
ARM: OMAP: hwmod: Fix up hwmod based clkdm accesses
From: Rajendra Nayak rna...@ti.com
hwmod uses deferencing the clk pointer to acccess the clkdm.
With COMMON clk hwoever this will need to be deferenced through
the clk_hw_omap pointer, so do the necessary changes.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 70 ++
1 file changed, 56 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 139adca..f38e4ce 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -130,7 +130,11 @@
#include linux/kernel.h
#include linux/errno.h
#include linux/io.h
+#ifdef CONFIG_COMMON_CLK
+#include linux/clk-provider.h
+#else
#include linux/clk.h
+#endif
#include linux/delay.h
#include linux/err.h
#include linux/list.h
@@ -614,6 +618,23 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
return 0;
}
+static struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
+{
+ if (oh-clkdm) {
+ return oh-clkdm;
+ } else if (oh-_clk) {
+#ifdef CONFIG_COMMON_CLK
+ struct clk_hw_omap *clk;
+
+ clk = to_clk_hw_omap(__clk_get_hw(oh-_clk));
+ return clk-clkdm;
+#else
+ return oh-_clk-clkdm;
+#endif
+ }
+ return NULL;
+}
+
/**
* _add_initiator_dep: prevent @oh from smart-idling while @init_oh is active
* @oh: struct omap_hwmod *
@@ -629,13 +650,18 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
*/
static int _add_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod
*init_oh)
{
- if (!oh-_clk)
+ struct clockdomain *clkdm, *init_clkdm;
+
+ clkdm = _get_clkdm(oh);
+ init_clkdm = _get_clkdm(init_oh);
+
+ if (!clkdm || !init_clkdm)
return -EINVAL;
- if (oh-_clk-clkdm oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
+ if (clkdm clkdm-flags CLKDM_NO_AUTODEPS)
return 0;
- return clkdm_add_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
+ return clkdm_add_sleepdep(clkdm, init_clkdm);
}
/**
@@ -653,13 +679,18 @@ static int _add_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh)
*/
static int _del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod
*init_oh)
{
- if (!oh-_clk)
+ struct clockdomain *clkdm, *init_clkdm;
+
+ clkdm = _get_clkdm(oh);
+ init_clkdm = _get_clkdm(init_oh);
+
+ if (!clkdm || !init_clkdm)
return -EINVAL;
- if (oh-_clk-clkdm oh-_clk-clkdm-flags CLKDM_NO_AUTODEPS)
+ if (clkdm clkdm-flags CLKDM_NO_AUTODEPS)
return 0;
- return clkdm_del_sleepdep(oh-_clk-clkdm, init_oh-_clk-clkdm);
+ return clkdm_del_sleepdep(clkdm, init_clkdm);
}
/**
@@ -693,7 +724,7 @@ static int _init_main_clk(struct omap_hwmod *oh)
*/
clk_prepare(oh-_clk);
- if (!oh-_clk-clkdm)
+ if (!_get_clkdm(oh))
pr_debug(omap_hwmod: %s: missing clockdomain for %s.\n,
oh-name, oh-main_clk);
@@ -1276,6 +1307,7 @@ static void _enable_sysc(struct omap_hwmod *oh)
u8 idlemode, sf;
u32 v;
bool clkdm_act;
+ struct clockdomain *clkdm;
if (!oh-class-sysc)
return;
@@ -1283,11 +1315,9 @@ static void _enable_sysc(struct omap_hwmod *oh)
v = oh-_sysc_cache;
sf = oh-class-sysc-sysc_flags;
+ clkdm = _get_clkdm(oh);
if (sf SYSC_HAS_SIDLEMODE) {
- clkdm_act = ((oh-clkdm
- oh-clkdm-flags CLKDM_ACTIVE_WITH_MPU) ||
-(oh-_clk oh-_clk-clkdm
- oh-_clk-clkdm-flags CLKDM_ACTIVE_WITH_MPU));
+ clkdm_act = (clkdm clkdm-flags CLKDM_ACTIVE_WITH_MPU);
if (clkdm_act !(oh-class-sysc-idlemodes
(SIDLE_SMART | SIDLE_SMART_WKUP)))
idlemode = HWMOD_IDLEMODE_FORCE;
@@ -3556,10 +3586,17 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct
omap_hwmod *oh)
{
struct clk *c;
struct omap_hwmod_ocp_if *oi;
+ struct clockdomain *clkdm;
+#ifdef CONFIG_COMMON_CLK
+ struct clk_hw_omap *clk;
+#endif
if (!oh)
return NULL;
+ if (oh-clkdm)
+ return oh-clkdm-pwrdm.ptr;
+
if (oh-_clk) {
c = oh-_clk;
} else {
@@ -3569,11 +3606,16 @@ struct powerdomain *omap_hwmod_get_pwrdm(struct
omap_hwmod *oh)
c = oi-_clk;
}
- if (!c-clkdm)
+#ifdef CONFIG_COMMON_CLK
+ clk = to_clk_hw_omap(__clk_get_hw(c));
+ clkdm = clk-clkdm;
+#else
+
