On Tuesday 31 July 2012 12:26 AM, Paul Walmsley wrote:
On Mon, 30 Jul 2012, Rajendra Nayak wrote:
Are you sure you are using the v3 of this patch? You already mentioned
about these in the v2 [1] and I fixed all these in v3. I went back and
looked at the v3 of this patch, and it does not
Hi,
On Mon, Jul 30, 2012 at 01:36:47PM -0700, Kevin Hilman wrote:
little trimming
The device tree data for acquiring the above GPIO interrupt line looks
like this.
+++ linux-omap-storage/arch/arm/boot/dts/omap5-evm.dts 2012-07-30
14:11:08.931694001 +0530
@@ -42,7 +42,8 @@
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
The device tree data for acquiring the above GPIO interrupt line looks
like this.
+++ linux-omap-storage/arch/arm/boot/dts/omap5-evm.dts 2012-07-30
14:11:08.931694001 +0530
@@ -42,7 +42,8 @@
tsl2771@39 {
On Tue, 2012-07-17 at 21:57 +0530, Jassi Brar wrote:
[CC'ing OMAPDSS matinainer]
On 17 July 2012 19:31, Raphael Assenat r...@8d.com wrote:
Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
Display panels are board specific and there is no limit to the number
of panels
On 31 July 2012 13:21, Tomi Valkeinen tomi.valkei...@ti.com wrote:
2) Have the configuration for countless panels specified in the DT data
Why should a DT blob for a board contain more than 1 panel configuration?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
On 31 July 2012 13:21, Tomi Valkeinen tomi.valkei...@ti.com wrote:
2) Have the configuration for countless panels specified in the DT data
Why should a DT blob for a board contain more than 1 panel configuration?
I meant the DT data
On 07/30/2012 05:31 PM, Turquette, Mike wrote:
On Mon, Jul 30, 2012 at 4:02 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jul 30, 2012 at 03:42:13PM -0700, Turquette, Mike wrote:
On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley p...@pwsan.com wrote:
So if we make a change
On 31 July 2012 13:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
On 31 July 2012 13:21, Tomi Valkeinen tomi.valkei...@ti.com wrote:
2) Have the configuration for countless panels specified in the DT data
Why should a DT blob for a
On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
On 31 July 2012 13:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
On 31 July 2012 13:21, Tomi Valkeinen tomi.valkei...@ti.com wrote:
2) Have the configuration for countless panels
On Thu, 2012-07-19 at 16:04 -0400, Raphael Assenat wrote:
On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
and the framebuffer cannot be enabled. However, this check does not seem to
apply to AM3505/17 chips.
I am not the first facing this issue, see this thread
On Mon, 2012-07-30 at 19:12 -0500, Ricardo Neri wrote:
Small patch to disable the PLL appropriately before runtime_put in case
an error occurs while enabling the PHY.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c |3 ++-
1 files changed, 2
On Tue, 2012-07-24 at 19:33 +0530, Jassi Brar wrote:
We have no reason to block in the error handler workqueue, so use msleep.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/video/omap2/dss/dispc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Thanks,
On 31 July 2012 14:12, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
On 31 July 2012 13:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
On 31 July 2012 13:21, Tomi Valkeinen
On Mon, Jul 30, 2012 at 05:31:23PM -0700, Turquette, Mike wrote:
On Mon, Jul 30, 2012 at 4:02 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jul 30, 2012 at 03:42:13PM -0700, Turquette, Mike wrote:
On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley p...@pwsan.com wrote:
So
On Tue, Jul 31, 2012 at 01:21:24AM -0700, Saravana Kannan wrote:
I have heard this idea about removing the clk_prepare/unprepare API too
many times and it makes me uncomfortable. I would really prefer we (the
community) take this discussion to the end and put an end to it. We
either
On Tue, 2012-07-31 at 14:27 +0530, Jassi Brar wrote:
On 31 July 2012 14:12, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
On 31 July 2012 13:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar
On Thu, 2012-07-26 at 10:53 -0500, Jon Hunter wrote:
On 07/26/2012 06:28 AM, Vinod Koul wrote:
On Thu, 2012-07-26 at 07:14 +, Arnd Bergmann wrote:
On Thursday 26 July 2012, Vinod Koul wrote:
But from a client POV it makes sense as with the given direction you
would need a specific
On Thu, 2012-07-26 at 12:43 -0500, Jon Hunter wrote:
So yes I can see that a channel itself could be configured to
support a
given direction, but when we ask for a channel via
dma_request_channel()
we are going to get a channel that matches the criteria we pass
using
the filter
On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
The device tree data for acquiring the above GPIO interrupt line
looks
like this.
+++ linux-omap-storage/arch/arm/boot/dts/omap5-evm.dts
I have a GUMSTIX Overo AirSTORM (AM3703-based).
When running a 3.4 kernel the USB host works just fine!
However when switching to 3.5 I get a few new warning messages and USB host no
longer works.
dmesg log after successfully loading the module (modprobe echi-hcd) on 3.4:
[ 23.424499]
Hi Santosh,
On Tue, Jul 31, 2012 at 6:02 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
The device tree data for acquiring the above GPIO interrupt
Hi,
On Tuesday 31 July 2012 06:22 AM, Juha Kuikka wrote:
Hello,
I am running the l-o (55936cdfaaf11ac352b56bc58e42d6661e65ee13) with following:
- ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature
- ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503
- OMAPDSS: PM runtime fixes for 3.5-rc
Using
Hi Peter,
On Fri, Jul 27, 2012 at 14:40:52, Ujfalusi, Peter wrote:
Hi,
On 07/24/2012 06:45 PM, AnilKumar Ch wrote:
Adds basic pinctrl support for AM33XX family of devices. This patch
is based on the pinctrl-simple driver submitted by Tony Lindgren's
here: http://lwn.net/Articles/496075/
Hi,
On Fri, 2012-07-27 at 20:07 -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
I've been working for the better part of the week on solving some of
the omapdss vs kms mismatches, which is one of the bigger remaining
issues in the TODO before moving omapdrm out of staging.
The
Hi,
On Fri, Jul 27, 2012 at 02:01:59PM +0530, Ravi B wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static
Hi,
On Fri, Jul 27, 2012 at 02:01:59PM +0530, Ravi B wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved
Hi Samuel,
On Fri, Jul 27, 2012 at 18:18:17, Samuel Ortiz wrote:
Hi Anilkumar,
On Fri, Jul 20, 2012 at 03:00:01PM +0530, AnilKumar Ch wrote:
Regulator platform data handling was mistakenly added to MFD
driver. So we will see build errors if we compile MFD drivers
without
On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Fri, 2012-07-27 at 20:07 -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
I've been working for the better part of the week on solving some of
the omapdss vs kms mismatches, which is one of the bigger
On Thu, Jul 26, 2012 at 04:16:15PM +0100, Jon Hunter wrote:
On 07/26/2012 10:05 AM, Will Deacon wrote:
Ok, thanks for updating me. I've pushed the patches out onto my
perf/omap4-dev branch as that seems to be a good place to collate the
current state of things. I've not tried doing anything
From: Rob Clark r...@ti.com
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous. This is a
problem that shows up when userspace is using a drm plane to
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay
On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until
On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark rob.cl...@linaro.org wrote:
On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
This simplifies drm fb lifetime,
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark rob.cl...@linaro.org wrote:
On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark
Hi Mike,
On Mon, 30 Jul 2012, Turquette, Mike wrote:
On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley p...@pwsan.com wrote:
So if we make a change like this one, it seems like we would basically
expect it to break once we start doing anything meaningful with
clk_prepare(), like using
Hi Rajendra,
On 07/31/2012 12:41 AM, Rajendra Nayak wrote:
Hi Jon,
On Tuesday 31 July 2012 10:11 AM, Jon Hunter wrote:
Hi Paul, Rajendra,
On 07/27/2012 12:43 AM, Rajendra Nayak wrote:
On Friday 27 July 2012 02:34 AM, Paul Walmsley wrote:
Commit 4da71ae6 (OMAP: clockdomain: Arch specific
On 31 July 2012 15:27, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 14:27 +0530, Jassi Brar wrote:
On 31 July 2012 14:12, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
On 31 July 2012 13:44, Tomi Valkeinen
Hi Paul,
On 07/30/2012 11:36 PM, Jon Hunter wrote:
Hi Paul,
On 07/30/2012 06:26 PM, Jon Hunter wrote:
[...]
1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices
we simply return without doing anything. Not sure if it is safe to
remove this but I can do some
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark rob.cl...@linaro.org wrote:
On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark
Op 26 jul. 2012, om 19:46 heeft Daniel Mack zon...@gmail.com het volgende
geschreven:
On 26.07.2012 18:09, Koen Kooi wrote:
Op 26 jul. 2012, om 17:58 heeft Daniel Mack zon...@gmail.com het
volgende geschreven:
On 26.07.2012 17:00, Koen Kooi wrote:
With Ajay's usb patches you can
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights. Expose this functionality via the
backlight API.
Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net
---
drivers/mfd/tps65217.c| 71 +
On 31/07/12 04:45 AM, Tomi Valkeinen wrote:
On Thu, 2012-07-19 at 16:04 -0400, Raphael Assenat wrote:
On our AM3505 based board, dpi.c complains that there is no VDSS_DSI
regulator
and the framebuffer cannot be enabled. However, this check does not seem to
apply to AM3505/17 chips.
I am
Hi Paul,
On 07/12/2012 04:17 PM, Paul Walmsley wrote:
[snip]
@@ -170,6 +201,18 @@ static int omap2_clkdm_clk_enable(struct clockdomain
*clkdm)
if (!clkdm-clktrctrl_mask)
return 0;
+ /*
+ * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
+ *
Hi Will,
On 07/31/2012 10:14 AM, Will Deacon wrote:
On Thu, Jul 26, 2012 at 04:16:15PM +0100, Jon Hunter wrote:
On 07/26/2012 10:05 AM, Will Deacon wrote:
Ok, thanks for updating me. I've pushed the patches out onto my
perf/omap4-dev branch as that seems to be a good place to collate the
On Fri, Jul 27, 2012 at 10:04:44AM +0300, Felipe Balbi (ba...@ti.com) wrote:
Feel free to add my acked-by: Evgeniy Polyakov z...@ioremap.net
I thought you would :-p Then I guess Tony, maybe ?
Greg, will you pick this patchset?
It is fairly simple and without any behaviour changes, but things
On Wed, Aug 01, 2012 at 03:19:10AM +0400, Evgeniy Polyakov wrote:
On Fri, Jul 27, 2012 at 10:04:44AM +0300, Felipe Balbi (ba...@ti.com) wrote:
Feel free to add my acked-by: Evgeniy Polyakov z...@ioremap.net
I thought you would :-p Then I guess Tony, maybe ?
Greg, will you pick this
On 07/31/2012 12:46 AM, Tomi Valkeinen wrote:
On Mon, 2012-07-30 at 19:11 -0500, Ricardo Neri wrote:
DSS code wrongly assumes that VENC is always available as source for the
external
sync signal for the display controller DIGIT channel. One cannot blindly
rely only on the value of
From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
From: Ricardo Neri ricardo.n...@ti.com
Date: Mon, 30 Jul 2012 17:54:59 -0500
Subject: [PATCH v3] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
DSS code wrongly assumes that VENC is always available as source for
DSS code wrongly assumes that VENC is always available as source for the
external
sync signal for the display controller DIGIT channel. One cannot blindly
write/read
the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this
operation
may not be valid. If the the sync source is
On 07/31/2012 06:52 PM, Ricardo Neri wrote:
From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
From: Ricardo Neriricardo.n...@ti.com
Date: Mon, 30 Jul 2012 17:54:59 -0500
Subject: [PATCH v3] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
A small issue while
Hi Paul,
On 07/31/2012 01:16 PM, Jon Hunter wrote:
[snip]
So scratch item #1 above. As Rajendra pointed out in another thread this
is not right. The only other comment I have with your patch is maybe we
need to add the following to prevent the EMU PD being idled during
boot-up if enabled
Hi Samuel,
On Tue, Jul 31, 2012 at 20:00:21, AnilKumar, Chimata wrote:
Hi Samuel,
On Fri, Jul 27, 2012 at 18:18:17, Samuel Ortiz wrote:
Hi Anilkumar,
On Fri, Jul 20, 2012 at 03:00:01PM +0530, AnilKumar Ch wrote:
Regulator platform data handling was mistakenly added to MFD
driver.
52 matches
Mail list logo
