Hi Thomas, Jason,
I noticed that both devkit8000 and omap3stalker boards use the generic
dpi driver for LCD. Why is that? If the boards have a normal fixed
resolution LCD, the timings for the LCD should be added to the
panel-generic-dpi.c.
Tomi
--
To unsubscribe from this list: send the line
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Define new HDMI timings structure to replace the OMAP DSS timing strucutre in
hdmi.c to have the HDMI include defintion out of DSS.
structure and definition typoed. And the point is not to remove hdmi
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data strtucure.Also the functions are modified
accordingly to take care of this movement.
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Instead of DSS knowing of the interior IP driver function provide
a wrapper API to configure.
This commit message doesn't make much sense. What you do in this patch
is just rename the functions, and
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
To make the current hdmi DSS driver compatible with future OMAP with different
IP blocks , add HDMI as a feature in dss_features and abstract the internal
function in hdmi dss driver.
No space before
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Some of the header file definitions of HDMI IP are needed by audio driver thus
moving the common defintion to more generic Include/video.
Signed-off-by: Mythri P K mythr...@ti.com
---
On Wed, Aug 31, 2011 at 12:56:26PM -0400, Laurent Pinchart wrote:
True, but if we implement address rounding transparently in the IOMMU layer
Ohad's concern can be valid, depending on whether the device is trusted. If
we
decide to push address rounding to the drivers that decision can be
Hi Marc,
On 31/08/11 17:55, Marc Dietrich wrote:
Am Mittwoch 31 August 2011, 18:12:48 schrieb Marc Zyngier:
[...]
Oddly enough, this patch doesn't do anything on my Tegra setup. In both
cases, I get around 17MB/s from a crap SD card plugged in a USB reader.
This leads me to suspect that
Hi Marc,
^dito,
On 31/08/11 17:55, Marc Dietrich wrote:
Am Mittwoch 31 August 2011, 18:12:48 schrieb Marc Zyngier:
[...]
Oddly enough, this patch doesn't do anything on my Tegra setup. In both
cases, I get around 17MB/s from a crap SD card plugged in a USB reader.
This leads me to
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove
On 9/1/2011 12:20 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
From: Nishanth Menonn...@ti.com
An API which translates a standard hwmod name to corresponding
omap_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back
On 9/1/2011 12:23 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
From: Nishanth Menonn...@ti.com
Provide a quick set of access functions:
a) Convert omap_device to platform_device - This is the flip of
to_omap_device for equivalent usage
b) Convert omap_device to device
On 9/1/2011 12:31 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
Remove all these duplicated structures since a default one is now
available.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Kevin Hilmankhil...@ti.com
---
arch/arm/mach-omap2/devices.c| 46
Some systems (such as OMAP) preserve the L2 cache across a suspend/
resume cycle. This means they do not perform L2 cache maintanence
in their suspend finisher function.
However, the side effect is that the saved CPU state is not readable
by the resume code because it is sitting in the L2 cache.
r1 stores the v:p offset from the CPU invariant resume code, and is
expected to be preserved by the CPU specific code. Overwriting it is
not a good idea.
We've managed to get away with it on sa1100 platforms because most
happen to have PHYS_OFFSET == PAGE_OFFSET, but that may not be the
case
Am 01.09.2011 08:42, schrieb Tomi Valkeinen:
Hi Thomas, Jason,
I noticed that both devkit8000 and omap3stalker boards use the generic
dpi driver for LCD. Why is that? If the boards have a normal fixed
resolution LCD, the timings for the LCD should be added to the
panel-generic-dpi.c.
Tomi
Add support for Innolux AT070TN83, a 7 inch LCD
with RGB-Interface and touch panel to panel-generic-dpi.
Tested with Devkit8000.
Signed-off-by: Thomas Weber we...@corscience.de
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 insertions(+),
Change lcd driver from generic to AT070TN83.
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index
On Tue, 2011-08-30 at 16:21 +0530, Archit Taneja wrote:
Add initial support for DSI video mode panels:
- Add a new structure omap_dss_dsi_videomode_data in the member panel in
omap_dss_device struct. This allows panel driver to configure dsi video_mode
specific parameters.
- Configure
-Original Message-
From: Maupin, Chase
Sent: Friday, August 26, 2011 11:10 AM
To: linux-omap@vger.kernel.org
Cc: Maupin, Chase
Subject: [PATCH] omap_vout: fix section mismatch in probe function
Building the OMAP vout driver resulted in the following message:
WARNING:
Hi Ohad,
On Thursday 01 September 2011 13:47:26 Ohad Ben-Cohen wrote:
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures
On Thu, Sep 01, 2011 at 09:31:13AM -0400, Laurent Pinchart wrote:
Hi Ohad,
On Thursday 01 September 2011 13:47:26 Ohad Ben-Cohen wrote:
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm
Hi Ohad,
On Thursday 01 September 2011 13:47:26 Ohad Ben-Cohen wrote:
On Wed, Aug 31, 2011 at 1:52 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures
Hey Paul,
I've been looking at this now and got one question below. Otherwise your
comments look okay to me and I can work with those.
On Fri, 2011-08-26 at 11:12 +0200, Paul Walmsley wrote:
Hello Tero,
a few comments on this patch:
On Mon, 25 Jul 2011, Tero Kristo wrote:
Introduce a
We need to ensure that state is pushed out from the L2 cache when
suspending so that the resume paths can access their data before the
MMU and caches have been re-initialized. Add the necessary calls to
__cpu_suspend_save().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Convert some of the sleep.S guts to C code, which makes it easier to
use our macros and to add L2 cache handling. We provide a helper
function, __cpu_suspend_save(), which deals with saving the common
state, setting up for resume, and flushing caches.
The remainder left as assembly code is the
Preallocate a page table and setup an identity mapping for the MMU
enable code. This means we don't have to borrow a page table to
do this, avoiding complexities with L2 cache coherency.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/suspend.h | 17
We don't require cpu_resume_turn_mmu_on as we can combine the ldr
instruction with the following code provided we ensure that
cpu_resume_mmu is aligned for older CPUs. Note that we also align
to a 32-byte boundary to ensure that the code can't cross a section
boundary.
Signed-off-by: Russell
There is no need to save and restore the context ID register on ARMv6
and ARMv7 with a temporary page table as we write the context ID
register when we switch back to the real page tables for the thread.
Moreover, the temporary page tables do not contain any non-global
mappings, so the context ID
Only use the preallocated page table during the resume, not while
suspending. This avoids the overhead of having to switch unnecessarily
to the resume page table in the suspend path.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/sleep.S | 19 +--
Ensure that the return value from __cpu_suspend is non-zero when
aborting. Zero indicates a successful suspend occurred.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/sleep.S |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
ARM920 and ARM926 save four registers, not three. Fix the size of
the suspend region required.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/proc-arm920.S |2 +-
arch/arm/mm/proc-arm926.S |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
For ARMv7 kernels running in the non-secure world, writing to the
auxillary control register causes an abort, so we must avoid directly
writing the auxillary control register. If the ACR has already been
reinitialized by SoC code, don't try to restore it.
Signed-off-by: Russell King
On Thursday 01 September 2011 16:02:35 Ohad Ben-Cohen wrote:
On Thu, Sep 1, 2011 at 4:59 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
It looks good to me.
Thanks.
I haven't tested it though.
I did, but I always get aligned buffers so my testing is a bit moot. I
Cousson, Benoit b-cous...@ti.com writes:
On 9/1/2011 12:23 AM, Hilman, Kevin wrote:
Benoit Coussonb-cous...@ti.com writes:
From: Nishanth Menonn...@ti.com
Provide a quick set of access functions:
a) Convert omap_device to platform_device - This is the flip of
to_omap_device for
javier Martin javier.mar...@vista-silicon.com writes:
I am trying to enable cpuidle and cpufreq support in latest stable
kernel (3.0.4) in the Beagleboard xM.
OMAP CPUfreq driver is still not in mailine. I plan to rectify that
(finally) for v3.2. In the mean time, feel free to try the
Hi Russell,
On Thu, Sep 01, 2011 at 01:47:52PM +0100, Russell King - ARM Linux wrote:
Some systems (such as OMAP) preserve the L2 cache across a suspend/
resume cycle. This means they do not perform L2 cache maintanence
in their suspend finisher function.
However, the side effect is that
Hi Kevin,
thanks for your help.
CPU is staying in C0 probably because UARTs are not being idled, so SoC
cannot hit deeper idle states. Try the following at the command line to
to enable UART idle timeouts, so the SoC can attempt idle after the
timeout period
# UART timeouts: omap-serial
On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote:
This is also the case on i.MX6Q, which L2 cache is retained during a
suspend/resume cycle. Currently, I have to call into the following
before calling generic cpu_suspend() to clean/invalidate the entire
L2 cache.
On Thu, Sep 01, 2011 at 04:34:51PM +0100, Russell King - ARM Linux wrote:
On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote:
This is also the case on i.MX6Q, which L2 cache is retained during a
suspend/resume cycle. Currently, I have to call into the following
before calling
On Thursday 25 August 2011, Kevin Hilman wrote:
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -622,7 +622,8 @@ static struct dev_pm_domain omap_device_pm_domain = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
Benoit Cousson b-cous...@ti.com writes:
Hi Kevin,
Here are a couple of cleanups on top of your for_3.2/omap_device series
rebased on top of 3.1-rc2 to get your pm-fixes.
OK, my for_3.2/omap_device is now based on v3.1-rc4 which has my
pm-fixes merged.
The goal is to help building core
Hi Grant, Tony,
This is a rework of the original series done by Manju:
http://www.spinics.net/lists/linux-omap/msg55827.html
It fixes the main issue of the previous series that was not booting at all
due to the lack of twl support. That fix is mandatory to allow further
work on the regulators DT
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.
Signed-off-by: Benoit
Hi Grant, Tony,
This is second part of the rework of the original series done by Manju:
http://www.spinics.net/lists/linux-omap/msg55827.html
It introduces the OMAP3 DT support incrementaly like it was done for OMAP4.
Patches are based on for_3.2/5_omap_dt_i2c_twl + devicetree/test
and are
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Add required clock frequencies for the i2c client devices existing
on beagle board.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson
Create an OMAP3 generic board to start the DT migration.
This file is doing the minimal initialization needed to boot
properly on a RAMDISK filesystem.
As soon as the OMAP3 specifics will be removed, that board will
be converted to an even more generic board-dt.c that will support
every OMAP2+
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.
Any DT work for OMAP3 will have to be done on the generic DT
board file to avoid breaking the legacy board support until
DT migration is done.
Based on orginal patch
Hi Manju,
On 8/23/2011 5:46 PM, G, Manjunath Kondaiah wrote:
Hi Grant,
[...]
This function calls of_i2c_register_devices which attaches all the required
parameters reg, irq, archdata etc into i2c adapter. But it will not attach
platform_data which results empty pdata pointer in i2c child
javier Martin javier.mar...@vista-silicon.com writes:
Hi Kevin,
thanks for your help.
CPU is staying in C0 probably because UARTs are not being idled, so SoC
cannot hit deeper idle states. Try the following at the command line to
to enable UART idle timeouts, so the SoC can attempt idle
Arnd Bergmann a...@arndb.de writes:
On Thursday 25 August 2011, Kevin Hilman wrote:
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -622,7 +622,8 @@ static struct dev_pm_domain omap_device_pm_domain = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend,
The suspend/resume _noirq handlers were #ifdef'd out in the
!CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops
struct. Fix by defining them to NULL in the !CONFIG_SUSPEND case.
Reported-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies to
On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote:
/*
+* XXX: The cpus node is mandatory, but since the CPUs are as well
part
+* of the mpu subsystem below, it is not clear where the information
+* should be. Maybe here with a phandle inside the
On Thursday 01 September 2011 11:12:02 Kevin Hilman wrote:
The suspend/resume _noirq handlers were #ifdef'd out in the
!CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops
struct. Fix by defining them to NULL in the !CONFIG_SUSPEND case.
Reported-by: Arnd Bergmann a...@arndb.de
On Thursday 01 September 2011 19:21:20 Benoit Cousson wrote:
+#ifdef CONFIG_OF
+#define MODALIAS_SIZE 32
+
+static int add_of_children(struct i2c_client *client, unsigned long features)
+{
+ u32 reg;
+ struct device *child, *dev = client-dev;
+ struct device_node *node,
Benoit Cousson b-cous...@ti.com writes:
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already alocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with
Benoit Cousson b-cous...@ti.com writes:
Add two helpers function to parse a property that contains multiple
strings.
These functions might be exported and moved to a common place if they
can to be useful elsewhere.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman
Reuse omap_hsmmc_dma_cleanup even for normal dma teardown in
omap_hsmmc_dma_cb. Consolidate multiple points of dma unmap into a
single location in post_req function, to prevent double unmapping.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 20
The first patch substitutes the dma_cleanup function in place of
the body of the code which does the same thing. The dma unmap
operation is now restricted just to the post_req function.
The second patch minimizes holding spin lock during dma
configuration, where it is not necessary.
Venkatraman
No need to hold the spinlock during a rather long dma configuration
sequence inside dma callback, which doesn't need it.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Marc Dietich wrote at Thursday, September 01, 2011 5:14 AM:
I'll add Stephen Warren from NVIDIA to the CC list. He has more HW to test on.
Here are the results I found:
Harmony:
Tegra USB3 - SMSC9514 hub: NOT affected
(Unplugging LAN cable, or disabling SMSC9514 LAN driver doesn't change this)
On Thursday 01 September 2011 19:21:16 Benoit Cousson wrote:
This is a rework of the original series done by Manju:
http://www.spinics.net/lists/linux-omap/msg55827.html
It fixes the main issue of the previous series that was not booting at all
due to the lack of twl support. That fix is
On Thu, Sep 1, 2011 at 06:48, Cousson, Benoit b-cous...@ti.com wrote:
Nishanth,
Do you have any objection to replace that API with omap_hwmod_name_get_pdev?
None.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Thursday, September 01, 2011, Arnd Bergmann wrote:
On Thursday 01 September 2011 11:12:02 Kevin Hilman wrote:
The suspend/resume _noirq handlers were #ifdef'd out in the
!CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops
struct. Fix by defining them to NULL in the
Mark Salter msalter at redhat.com writes:
On Wed, 2011-08-31 at 00:03 +0800, ming.lei at canonical.com wrote:
...
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
...
Benoit Cousson b-cous...@ti.com writes:
Add a notifier called during device_add phase. If a of_node is present,
retrieve the hwmod entry in order to populate propely the omap_device
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource
On Tue, 30 Aug 2011, Paul Walmsley wrote:
On Tue, 23 Aug 2011, Paul Walmsley wrote:
The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6
Remove the OMAP_CHIP bitmasks from the powerdomain and clockdomain
code. In their place, use lists of powerdomains and clockdomains to
register for particular chips and chip families.
The intention of this change is to reduce the number of lines that
need to be patched to add support for new
In preparation for OMAP_CHIP() removal, split clkdm_init() into four
functions. This allows some of them to be called multiple times: for
example, clkdm_register_clkdms() can be called once to register
clockdomains that are common to a group of SoCs, and once to register
clockdomains that are
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three
functions. This allows some of them to be called multiple times: for
example, pwrdm_register_pwrdms() can be called once to register
powerdomains that are common to a group of SoCs, and once to register
powerdomains that are
At Tony's request, remove the omap_chip bitmasks from the powerdomain
definitions. Instead, initialize powerdomains based on one or more
lists that are applicable to a particular SoC family, variant, and
silicon revision.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/io.c
Hi Benoit,
On Thu, Sep 01, 2011 at 07:34:11PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/23/2011 5:46 PM, G, Manjunath Kondaiah wrote:
Hi Grant,
[...]
This function calls of_i2c_register_devices which attaches all the required
parameters reg, irq, archdata etc into i2c adapter. But
Hi,
On Thu, Sep 1, 2011 at 1:44 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Define new HDMI timings structure to replace the OMAP DSS timing strucutre in
hdmi.c to have the HDMI include defintion
Hi,
On Thu, Sep 1, 2011 at 1:57 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data
On Fri, 2011-09-02 at 10:41 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 1, 2011 at 1:57 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
As the pll and the video configuration info are part of the
Hi,
On Thu, Sep 1, 2011 at 2:30 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Some of the header file definitions of HDMI IP are needed by audio driver
thus
moving the common defintion to more
Hi,
On Thursday 01 September 2011 06:44 PM, Valkeinen, Tomi wrote:
On Tue, 2011-08-30 at 16:21 +0530, Archit Taneja wrote:
Add initial support for DSI video mode panels:
- Add a new structure omap_dss_dsi_videomode_data in the member panel in
omap_dss_device struct. This allows panel driver
Hi,
On Fri, Sep 2, 2011 at 10:43 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 10:41 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 1, 2011 at 1:57 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K
On Fri, 2011-09-02 at 10:45 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 1, 2011 at 2:30 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Some of the header file definitions of HDMI IP are needed by
Hi,
On Fri, Sep 2, 2011 at 10:54 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-09-02 at 10:45 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 1, 2011 at 2:30 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2011-08-29 at 11:44 +0530, mythr...@ti.com wrote:
From: Mythri P K
On Fri, 2011-09-02 at 10:45 +0530, Archit Taneja wrote:
Hi,
On Thursday 01 September 2011 06:44 PM, Valkeinen, Tomi wrote:
On Tue, 2011-08-30 at 16:21 +0530, Archit Taneja wrote:
Add initial support for DSI video mode panels:
- Add a new structure omap_dss_dsi_videomode_data in the
81 matches
Mail list logo
