RE: [RFC] omap: hwspinlock: Added hwspinlock driver
( Using Web-mail so please excuse me for the email format) From: Que, Simon Sent: Friday, June 25, 2010 3:31 PM To: Shilimkar, Santosh; linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Ohad Ben-Cohen Subject: RE: [RFC] omap: hwspinlock: Added hwspinlock driver >Santosh, >> This reservation KCONFIG isn't necessary. HWSPINLOCK IP is not really for >> very generic use >> but specific usages where you need to protect the data between independent >> softwares >>running on different masters. >>For other Linux only side software even with dual core, kernel spinlock >>library >>is sufficient. >We will consider this. >> Are you building this for all OMAP's ?? >>Move this base address to plat/omap44xx.h and use it from there >>" OMAP2_L4_IO_ADDRESS" this should not be used anymore. Rather, use >>"ioremap and readl/writel" >Good points, we'll implement these. >> Why do you have two files ? This IP is not part of OMAP1 and all the code >> can >> go in mach-omap and can be exported from there. >Are you suggesting we use a library approach instead of a driver approach? We >want to make this expandable in the future. If something in the underlying >hardware changes with OMAP5, OMAP6, etc, we only need to update the device >>initialization file. The driver can remain unchanged. No I am not suggesting the library approach. What you have done is correct except that "you should just make it as early platform driver" using HWMOD. This isn't so difficult considering you have already created a platform driver. Only the initializations part will change. HW spin-lock doesn't have any direct clock control so it's even simpler. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pm_debug/voltage_off_while_idle has gone?
Kevin Hilman wrote: Mike Rapoport writes: There used to be 'voltage_off_while_idle' attribute in the PM-enabled kernels that allowed to put PMIC into OFF mode. In the current tip of the linux-omap-pm tree this attribute seem to be gone Is there possibility to make PMIC enter the OFF mode when suspending to RAM? Hi Mike, We are currently in the middle of a major rewrite of the SmartReflex and voltage layers of the PM branch. The previous voltage-related work (like voltage_off_while_idle) are still available in the pm-vc branch of my tree, but are not currently merged with the new voltage work due to conflicts. For this particular feature, I suspect you could just apply the first patch in my pm-vc branch to add back this feature. Let me know if that works, I've cherry-picked two commits from your pm-vc and it failed to compile :) After fixing it, I did several small tests, but is seems that PMIC does not execute the power scripts... I'll continue to work on it. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- 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] mm: iommu: An API to unify IOMMU, CPU and device memory management
On Thu, 24 Jun 2010 23:48:50 -0700 Zach Pfeffer wrote: > Andi Kleen wrote: > > Zach Pfeffer writes: > > > >> This patch contains the documentation for and the main header file of > >> the API, termed the Virtual Contiguous Memory Manager. Its use would > >> allow all of the IOMMU to VM, VM to device and device to IOMMU > >> interoperation code to be refactored into platform independent code. > > > > I read all the description and it's still unclear what advantage > > this all has over the current architecture? > > > > At least all the benefits mentioned seem to be rather nebulous. > > > > Can you describe a concrete use case that is improved by this code > > directly? > > Sure. On a SoC with many IOMMUs (10-100), where each IOMMU may have > its own set of page-tables or share page-tables, and where devices > with and without IOMMUs and CPUs with or without MMUS want to > communicate, an abstraction like the VCM helps manage all conceivable > mapping topologies. In the same way that the Linux MM manages pages > apart from page-frames, the VCMM allows the Linux MM to manage ideal > memory regions, VCMs, apart from the actual memory region. > > One real scenario would be video playback from a file on a memory > card. To read and display the video, a DMA engine would read blocks of > data from the memory card controller into memory. These would > typically be managed using a scatter-gather list. This list would be > mapped into a contiguous buffer of the video decoder's IOMMU. The > video decoder would write into a buffer mapped by the display engine's > IOMMU as well as the CPU (if the kernel needed to intercept the > buffers). In this instance, the video decoder's IOMMU and the display > engine's IOMMU use different page-table formats. > > Using the VCM API, this topology can be created without worrying about > the device's IOMMUs or how to map the buffers into the kernel, or how > to interoperate with the scatter-gather list. The call flow would would go: Can you explain how you can't do the above with the existing API? > The general point of the VCMM is to allow users a higher level API > than the current IOMMU abstraction provides that solves the general > mapping problem. This means that all of the common mapping code would > be written once. In addition, the API allows all the low level details > of IOMMU programing and VM interoperation to be handled at the right > level. > > Eventually the following functions could all be reworked and their > users could call VCM functions. There are more IOMMUs (e.g. x86 has calgary, gart too). And what is the point of converting old IOMMUs (the majority of the below)? are there any potential users of your API for such old IOMMUs? -- 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: [linux-pm] wait_for_completion_interruptible does not wait !!
On Sun, Jun 20, 2010 at 8:52 AM, Alan Stern wrote:
>
> What happens if the variable is completed while nobody is waiting for
> it? The next time somebody tries to wait, won't the wait terminate
> immediately?
>
Haven't tested it but will reply with the answer once I get a chance to test it.
>> I tried wait_for_completion instead, but now the kernel refuses to suspend.
>>
>> I have tried wait queues and mutexs with no success.
>>
>> Could anyone please point me how I can resolve this issue? Is there
>> any construct which can block inside the kernel during suspend/resume?
>
> Yes: The freezer.
>
>> Can there be a blocking call active while we suspend?
>
> Yes, in theory. In practice it's not a good idea, since the call
> wouldn't be able to distinguish between an actual signal and the onset
> of a suspend. You might end up with a call that ignores all signals
> and hence cannot be interrupted.
>
Just for the information of others on the list, here is what we did to
solve this issue, we designed a freezer-friendly wrapper around
wait_for_completion_interruptible()
#define wait_for_completion_freezable(ptr_completion) \
({ \
int __retval;\
do { \
__retval = wait_for_completion_interruptible(\
ptr_completion); \
if (__retval && !freezing(current)) \
break; \
} while (try_to_freeze()); \
__retval;\
})
Thanks
Suresh
--
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: On the APIs for Enabling and Disabling Wakeup capability.
> >> I wanted to close on the introduction of two new > OMAP device APIs > >> omap_device_enable_wakeup () & > omap_device_disable_wakeup() in > >> omap_device layer. What's the relationship between these and the sysfs attribute which manages the per-device wakeup enable? Should there be driver model calls, into which these OMAP errata-oriented calls would hook? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 10/13] OMAP: create omap_devices for MPU, DSP, L3
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, June 25, 2010 5:15 AM
> To: linux-omap@vger.kernel.org
> Cc: p...@pwsan.com
> Subject: [PATCH v2 10/13] OMAP: create omap_devices for MPU, DSP, L3
>
> Create simple omap_devices for the main processors and busses.
>
> This is required to support the forth-coming device-based OPP
> approach, where OPPs are managed and tracked at the device level.
>
> So that these primary devices are available for early PM initialization,
> they are created as early platform_devices.
>
> Cc: Paul Walmsley
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/devices.c|2 +
> arch/arm/mach-omap2/io.c | 58
> +-
> arch/arm/plat-omap/include/plat/common.h |4 ++
> 3 files changed, 63 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 03e6c9e..62920ac 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -29,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mux.h"
>
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 3cfb425..407498d 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -45,7 +45,7 @@
>
> #include
> #include "clockdomains.h"
> -#include
> +#include
>
> /*
> * The machine specific code may provide the extra mapping besides the
> @@ -313,6 +313,61 @@ static int __init _omap2_init_reprogram_sdrc(void)
> return v;
> }
>
> +static struct omap_device_pm_latency *pm_lats;
> +
> +static struct device *mpu_dev;
> +static struct device *dsp_dev;
> +static struct device *l3_dev;
> +
> +struct device *omap_get_mpuss_device(void)
> +{
> + WARN_ON_ONCE(!mpu_dev);
> + return mpu_dev;
> +}
> +
> +struct device *omap_get_dsp_device(void)
> +{
> + WARN_ON_ONCE(!dsp_dev);
> + return dsp_dev;
> +}
> +
> +struct device *omap_get_l3_device(void)
> +{
> + WARN_ON_ONCE(!l3_dev);
> + return l3_dev;
> +}
> +
> +/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
> +static int _init_omap_device(char *name, struct device **new_dev)
> +{
> + struct omap_hwmod *oh;
> + struct omap_device *od;
> +
> + oh = omap_hwmod_lookup(name);
> + if (WARN(!oh, "%s: could not find omap_hwmod for %s\n",
> + __func__, name))
> + return -ENODEV;
> +
> + od = omap_device_build(oh->name, 0, oh, NULL, 0, pm_lats, 0, true);
[Tarun Kanti DebBarma]
I am new to hwmod and just trying to catch up. In omap_device_build(...) we
anyway pass (oh) and so why also pass (oh->name)? If so we can reduce a
parameter.
> + if (WARN(IS_ERR(od), "%s: could not build omap_device for %s\n",
> + __func__, name))
> + return -ENODEV;
> +
> + *new_dev = &od->pdev.dev;
> +
> + return 0;
> +}
> +
> +/*
> + * Build omap_devices for processors and bus.
> + */
> +static void omap_init_processor_devices(void)
> +{
> + _init_omap_device("mpu", &mpu_dev);
> + _init_omap_device("iva", &dsp_dev);
> + _init_omap_device("l3_main", &l3_dev);
> +}
> +
> void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>struct omap_sdrc_params *sdrc_cs1)
> {
> @@ -342,6 +397,7 @@ void __init omap2_init_common_hw(struct
> omap_sdrc_params *sdrc_cs0,
> omap_serial_early_init();
> if (cpu_is_omap24xx() || cpu_is_omap34xx()) /* FIXME: OMAP4 */
> omap_hwmod_late_init();
> + omap_init_processor_devices();
> omap_pm_if_init();
> if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
> omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-
> omap/include/plat/common.h
> index d265018..9cdd9cd 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -87,4 +87,8 @@ void omap2_set_globals_uart(struct omap_globals *);
> } \
> })
>
> +struct device *omap_get_mpuss_device(void);
> +struct device *omap_get_dsp_device(void);
> +struct device *omap_get_l3_device(void);
> +
> #endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
> --
> 1.7.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [pm-wip/uart][PATCH] Serial: Avoid populating uart_list in early init phase
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Govindraj.R
> Sent: Friday, June 25, 2010 7:12 PM
> To: linux-omap@vger.kernel.org
> Cc: Kevin Hilman
> Subject: [pm-wip/uart][PATCH] Serial: Avoid populating uart_list in early
> init phase
>
> Leave the uart_list empty and keep the omap hwmod info
> in a seperate uart_oh list and if board file calls
> serial init use this uart_oh list info to fill uart_list.
> The board file can also call just init_port to initialise
> a single uart instance, so make init_port flexible to handle
> individual uart instance by avoiding filling uart_list
> in any non port_init function.
>
> Cc: Kevin Hilman
> Signed-off-by: Govindraj.R
> ---
> As per earlier dicussion:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31157.html
>
> arch/arm/mach-omap2/serial.c | 60 +
>
> 1 files changed, 36 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 24b8c60..246ae02 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -97,6 +97,13 @@ struct omap_uart_state {
> #endif
> };
>
> +struct uart_oh {
> + struct list_head node;
> + struct omap_hwmod *oh;
> + int uart_num;
> +};
> +
> +static LIST_HEAD(uart_oh_list);
> static LIST_HEAD(uart_list);
> static u8 num_uarts;
>
> @@ -593,39 +600,32 @@ static void serial_out_override(struct uart_port
> *up, int offset, int value)
>
> void __init omap_serial_early_init(void)
> {
> - int i = 0;
> + struct omap_hwmod *oh;
> + struct uart_oh *uoh;
> + char oh_name[MAX_UART_HWMOD_NAME_LEN];
>
> do {
> - char oh_name[MAX_UART_HWMOD_NAME_LEN];
> - struct omap_hwmod *oh;
> - struct omap_uart_state *uart;
> + uoh = kzalloc(sizeof(struct uart_oh), GFP_KERNEL);
> + if (WARN_ON(!uoh))
> + return;
>
> snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
> - "uart%d", i + 1);
> + "uart%d", num_uarts + 1);
> oh = omap_hwmod_lookup(oh_name);
> if (!oh)
> break;
[Tarun Kanti DebBarma]
What happens to the successfully allocated memory (uoh)? Are we not supposed to
free it before breaking?
In fact, is there any problem if we do the allocation at this point?
+ uoh = kzalloc(sizeof(struct uart_oh), GFP_KERNEL);
+ if (WARN_ON(!uoh))
+ return;
This would mean that we allocate and do the rest of initialization only when
omap_hwmod_lookup() is successful.
> -
> - uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
> - if (WARN_ON(!uart))
> - return;
> -
> - uart->oh = oh;
> - uart->num = i++;
> - list_add_tail(&uart->node, &uart_list);
> - num_uarts++;
> -
> /*
>* NOTE: omap_hwmod_init() has not yet been called,
> - * so no hwmod functions will work yet.
> - */
> -
> - /*
> + * so no hwmod functions will work yet.
>* During UART early init, device need to be probed
>* to determine SoC specific init before omap_device
> - * is ready. Therefore, don't allow idle here
> + * is ready. Therefore, don't allow idle here
>*/
> - uart->oh->flags |= HWMOD_INIT_NO_IDLE;
> + oh->flags |= HWMOD_INIT_NO_IDLE;
> + uoh->oh = oh;
> + uoh->uart_num = num_uarts;
> + list_add_tail(&uoh->node, &uart_oh_list);
> + num_uarts++;
> } while (1);
> }
>
> @@ -645,6 +645,7 @@ void __init omap_serial_init_port(int port)
> struct omap_uart_state *uart;
> struct omap_hwmod *oh;
> struct omap_device *od;
> + struct uart_oh *uoh;
> void *pdata = NULL;
> u32 pdata_size = 0;
> char *name;
> @@ -663,6 +664,17 @@ void __init omap_serial_init_port(int port)
> if (WARN_ON(port >= num_uarts))
> return;
[Tarun Kanti DebBarma]
I am not sure if this check is needed at all since this is called for all valid
ports in uart_oh_list. In other words validation of port number has happened
already while creating the uart_oh_list.
>
> + uart = kzalloc(sizeof(struct omap_uart_state), GFP_KERNEL);
> + if (WARN_ON(!uart))
> + return;
> +
> + uart->num = port;
> + list_add_tail(&uart->node, &uart_list);
> + list_for_each_entry(uoh, &uart_oh_list, node)
> + if (port == uoh->uart_num)
> + break;
> +
[Tarun Kanti DebBarma]
BTW, why can't we pass (uoh) to this function instead of port number? In that
case we would any way get the port number using uoh->uart_num
RE: [PATCH] OMAP1: PM: add simple runtime PM layer to manage clocks
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, June 18, 2010 4:38 AM
> To: linux-omap@vger.kernel.org
> Subject: [PATCH] OMAP1: PM: add simple runtime PM layer to manage clocks
>
> On OMAP1, we do not have omap_device + omap_hwmod to manage the
> device-specific idle, enable and shutdown. Instead, just
> enable/disable device clocks automatically at the runtime PM level.
>
> This allows drivers to not have any OMAP1 specific clock management
> and allows them to simply use the runtime PM API to manage clocks.
>
> Signed-off-by: Kevin Hilman
> ---
> This patch applies on top of the initial runtime PM support series:
>
> [PATCH 0/4] runtime PM support at the bus level
>
> posted to linux-omap on May 27th. It is also now included in
> my pm-wip/runtime branch in my git tree.
>
> arch/arm/mach-omap1/Makefile |2 +-
> arch/arm/mach-omap1/pm_bus.c | 77
> ++
> 2 files changed, 78 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap1/pm_bus.c
>
> diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
> index ea231c7..fd4df71 100644
> --- a/arch/arm/mach-omap1/Makefile
> +++ b/arch/arm/mach-omap1/Makefile
> @@ -12,7 +12,7 @@ obj-$(CONFIG_OMAP_MPU_TIMER)+= time.o
> obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
>
> # Power Management
> -obj-$(CONFIG_PM) += pm.o sleep.o
> +obj-$(CONFIG_PM) += pm.o sleep.o pm_bus.o
>
> # DSP
> obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o
> diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
> new file mode 100644
> index 000..46a34fc
> --- /dev/null
> +++ b/arch/arm/mach-omap1/pm_bus.c
> @@ -0,0 +1,77 @@
> +/*
> + * Runtime PM support code for OMAP1
> + *
> + * Author: Kevin Hilman, Deep Root Systems, LLC
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#ifdef CONFIG_PM_RUNTIME
> +int platform_pm_runtime_suspend(struct device *dev)
> +{
> + struct clk *iclk, *fclk;
> +
> + dev_dbg(dev, "%s\n", __func__);
> +
> + if (dev->driver->pm && dev->driver->pm->runtime_suspend)
> + ret = dev->driver->pm->runtime_suspend(dev);
I do not see "ret" declaration. I hope this is not a global variable.
> +
> + fclk = clk_get(dev, "fck");
> + if (!IS_ERR(fclk)) {
> + clk_disable(fclk);
> + clk_put(fclk);
> + }
> +
> + iclk = clk_get(dev, "ick");
> + if (!IS_ERR(iclk)) {
> + clk_disable(iclk);
> + clk_put(iclk);
> + }
> +
> + return 0;
Why not return "ret" instead of 0?
> +};
> +
> +int platform_pm_runtime_resume(struct device *dev)
> +{
> + int r, ret = 0;
> + struct clk *iclk, *fclk;
> +
> + iclk = clk_get(dev, "fck");
> + if (!IS_ERR(iclk)) {
> + clk_enable(iclk);
> + clk_put(iclk);
> + }
> +
> + fclk = clk_get(dev, "fck");
> + if (!IS_ERR(fclk)) {
> + clk_enable(fclk);
> + clk_put(fclk);
> + }
> +
> + if (dev->driver->pm && dev->driver->pm->runtime_resume)
> + ret = dev->driver->pm->runtime_resume(dev);
> +
> + return ret;
> +};
> +
> +int platform_pm_runtime_idle(struct device *dev)
> +{
> + ret = pm_runtime_suspend(dev);
Unless "ret" is global, we have to declare this locally?
> + dev_dbg(dev, "%s [%d]\n", __func__, ret);
> +
> + return 0;
How about returning "ret" instead of 0?
> +};
> +#endif /* CONFIG_PM_RUNTIME */
> --
> 1.7.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] OMAP:DSS: Enable TV Detection support
Enabled TVDET and created a sysfs entry for TV Detection
To detect if tv set is connected run this command
cat /sys/devices/platform/omapdss/display1/device_state
1: TV set connected
0: TV set disconnected
Signed-off-by: Axel Castaneda Gonzalez
Signed-off-by: Kishore Y
Signed-off-by: Mukund Mittal
Signed-off-by: Rajkumar N
---
arch/arm/plat-omap/include/plat/display.h |2 +
drivers/video/omap2/dss/display.c | 23 +
drivers/video/omap2/dss/venc.c| 52 +
3 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 7842efa..522240b 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -464,6 +464,8 @@ struct omap_dss_device {
enum omap_dss_display_state state;
+ u32 (*get_device_state)(struct omap_dss_device *dssdev);
+
/* platform specific */
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index ef8c852..2b937fe 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -278,6 +278,26 @@ static ssize_t display_wss_store(struct device *dev,
return size;
}
+static ssize_t device_state_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct omap_dss_device *dssdev = to_dss_device(dev);
+ unsigned int device_state;
+
+ if (!dssdev->get_device_state)
+ return -ENOENT;
+
+ device_state = dssdev->get_device_state(dssdev);
+
+ return snprintf(buf, PAGE_SIZE, "%u\n", device_state);
+}
+
+static ssize_t device_state_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ return size;
+}
+
static DEVICE_ATTR(enabled, S_IRUGO|S_IWUSR,
display_enabled_show, display_enabled_store);
static DEVICE_ATTR(update_mode, S_IRUGO|S_IWUSR,
@@ -290,6 +310,8 @@ static DEVICE_ATTR(rotate, S_IRUGO|S_IWUSR,
display_rotate_show, display_rotate_store);
static DEVICE_ATTR(mirror, S_IRUGO|S_IWUSR,
display_mirror_show, display_mirror_store);
+static DEVICE_ATTR(device_state, S_IRUGO|S_IWUSR,
+ device_state_show, device_state_store);
static DEVICE_ATTR(wss, S_IRUGO|S_IWUSR,
display_wss_show, display_wss_store);
@@ -301,6 +323,7 @@ static struct device_attribute *display_sysfs_attrs[] = {
&dev_attr_rotate,
&dev_attr_mirror,
&dev_attr_wss,
+ &dev_attr_device_state,
NULL
};
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index eff3505..3b5093b 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -33,12 +33,15 @@
#include
#include
#include
+#include
#include
#include
#include "dss.h"
+#define TV_INT_GPIO33
+#define TV_DETECT_DELAY40 /*Delay for TV detection
logic*/
#define VENC_BASE 0x48050C00
/* Venc registers */
@@ -612,6 +615,46 @@ static int venc_set_wss(struct omap_dss_device *dssdev,
u32 wss)
return 0;
}
+/**
+ * Enables TVDET pulse generation
+ */
+static void venc_enable_tv_detect(void)
+{
+ u32 l;
+
+ l = venc_read_reg(VENC_GEN_CTRL);
+ /* TVDET Active High Setting */
+ l |= FLD_VAL(1, 16, 16);
+ /* Enable TVDET pulse generation */
+ l |= FLD_VAL(1, 0, 0);
+ venc_write_reg(VENC_GEN_CTRL, l);
+}
+
+/**
+ * Disables TVDET pulse generation
+ */
+static void venc_disable_tv_detect(void)
+{
+ u32 l;
+
+ /* Disable TVDET pulse generation */
+ l = venc_read_reg(VENC_GEN_CTRL);
+ l |= FLD_VAL(0, 0, 0);
+ venc_write_reg(VENC_GEN_CTRL, l);
+}
+
+static u32 venc_detect_device(struct omap_dss_device *dssdev)
+{
+ u32 tv_state;
+
+ venc_enable_tv_detect();
+ mdelay(TV_DETECT_DELAY);
+ tv_state = gpio_get_value(TV_INT_GPIO);
+ venc_disable_tv_detect();
+
+ return tv_state;
+}
+
static struct omap_dss_driver venc_driver = {
.probe = venc_panel_probe,
.remove = venc_panel_remove,
@@ -646,6 +689,7 @@ static struct omap_dss_driver venc_driver = {
int venc_init(struct platform_device *pdev)
{
u8 rev_id;
+ int ret;
mutex_init(&venc.venc_lock);
@@ -671,7 +715,14 @@ int venc_init(struct platform_device *pdev)
venc_enable_clocks(0);
+ ret = gpio_request(TV_INT_GPIO, "tv_detect");
+ if (ret)
+ pr_err("Failed to get TV_INT_GPIO gpio_33.\n");
+ else
+ gpio_direction_input(TV_INT_GPIO);
+
return omap_dss_register_driver(&venc_driver);
+
}
void venc_exit(void)
@@ -684,6 +735
Re: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
On Sat, Jun 26, 2010 at 12:51:33PM +0200, Uwe Kleine-König wrote: > Hello, > > On Fri, Jun 25, 2010 at 07:46:05PM -0400, Nicolas Pitre wrote: > > On Fri, 25 Jun 2010, Russell King - ARM Linux wrote: > > > > > Does anyone know where we are on the defconfig problem? From what I > > > can see, it's mostly stalled for the time being, which is not good > > > news for us. > > > > What looked to be promizing is the work by Uwe Kleine-König according to > > the preview he posted on June 10: > > > > Message-id: <20100610063234.ga22...@pengutronix.de> > I think Linus is still away?! I plan to ping him again asking for an > opinion regarding my idea when he will be back. It looks that 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: [PATCH v2 1/3] OMAP: PM: initial runtime PM core support
Hello, On Fri, Jun 25, 2010 at 07:46:05PM -0400, Nicolas Pitre wrote: > On Fri, 25 Jun 2010, Russell King - ARM Linux wrote: > > > Does anyone know where we are on the defconfig problem? From what I > > can see, it's mostly stalled for the time being, which is not good > > news for us. > > What looked to be promizing is the work by Uwe Kleine-König according to > the preview he posted on June 10: > > Message-id: <20100610063234.ga22...@pengutronix.de> I think Linus is still away?! I plan to ping him again asking for an opinion regarding my idea when he will be back. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
