On Tue, 2012-07-31 at 18:56 -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
> write/read
> the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5
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
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
On 07/31/2012 06:52 PM, Ricardo Neri wrote:
From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
From: Ricardo Neri
Date: Mon, 30 Jul 2012 17:54:59 -0500
Subject: [PATCH v3] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
A small issue while sending the patch. I r
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 not
>From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
From: Ricardo Neri
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 the
external
sync
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 DSS_CONTROL[1
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
> >
> > I thought you would :-p Then I guess Tony, maybe ?
>
> Greg, will you pick this patchset?
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
>
> 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 look
like be
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
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
> +
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.
>
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
---
drivers/mfd/tps65217.c| 71 +
drivers/video/backlight/Kconfig
Op 26 jul. 2012, om 19:46 heeft Daniel Mack het volgende
geschreven:
> On 26.07.2012 18:09, Koen Kooi wrote:
>>
>> Op 26 jul. 2012, om 17:58 heeft Daniel Mack het
>> volgende geschreven:
>>
>>> On 26.07.2012 17:00, Koen Kooi wrote:
>>>
With Ajay's usb patches you can easily boot from a
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson wrote:
> On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote:
>> On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson
>> wrote:
>> > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote:
>> >> From: Rob Clark
>> >>
>> >> This simplifies drm fb lifetime,
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 ca
On 31 July 2012 15:27, Tomi Valkeinen wrote:
> On Tue, 2012-07-31 at 14:27 +0530, Jassi Brar wrote:
>> On 31 July 2012 14:12, Tomi Valkeinen wrote:
>> > On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
>> >> On 31 July 2012 13:44, Tomi Valkeinen wrote:
>> >> > On Tue, 2012-07-31 at 13:33 +05
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: clockd
Hi Mike,
On Mon, 30 Jul 2012, Turquette, Mike wrote:
> On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley 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 clk_prepar
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson wrote:
> On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote:
>> On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson
>> wrote:
>> > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote:
>> >> From: Rob Clark
>> >>
>> >> This simplifies drm fb lifetime,
On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote:
> On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson
> wrote:
> > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold
> >> a ref to the fb when
On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson wrote:
> On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> 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 ma
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote:
> From: Rob Clark
>
> 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 tha
From: Rob Clark
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
implement a hw c
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 an
On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Fri, 2012-07-27 at 20:07 -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> 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 th
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 CONFIG_
> Hi,
>
> On Fri, Jul 27, 2012 at 02:01:59PM +0530, Ravi B wrote:
> > From: Ajay Kumar Gupta
> >
> > 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,
On Fri, Jul 27, 2012 at 02:01:59PM +0530, Ravi B wrote:
> From: Ajay Kumar Gupta
>
> 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 local variab
Hi,
On Fri, 2012-07-27 at 20:07 -0500, Rob Clark wrote:
> From: Rob Clark
>
> 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 biggest pla
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
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 omap2plus
Hi Santosh,
On Tue, Jul 31, 2012 at 6:02 PM, Shilimkar, Santosh
wrote:
> On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi 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
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] ehci_hc
Hi,
On Tue, Jul 31, 2012 at 02:32:43PM +0200, Shilimkar, Santosh wrote:
> On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi 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
> > >
On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi 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/o
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 f
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 ne
On Tue, 2012-07-31 at 14:27 +0530, Jassi Brar wrote:
> On 31 July 2012 14:12, Tomi Valkeinen wrote:
> > On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
> >> On 31 July 2012 13:44, Tomi Valkeinen wrote:
> >> > On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
> >> >> On 31 July 2012 13:21,
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 a
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
> 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 wrote:
> >> > So if we make a change like
On 31 July 2012 14:12, Tomi Valkeinen wrote:
> On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
>> On 31 July 2012 13:44, Tomi Valkeinen wrote:
>> > On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
>> >> On 31 July 2012 13:21, Tomi Valkeinen wrote:
>> >>
>> >> > 2) Have the configuration
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
> ---
> drivers/video/omap2/dss/dispc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Thanks, applied.
As a side note
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
> ---
> drivers/video/omap2/dss/hdmi.c |3 ++-
> 1 files changed, 2 insertions(+), 1 dele
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 th
On Tue, 2012-07-31 at 13:57 +0530, Jassi Brar wrote:
> On 31 July 2012 13:44, Tomi Valkeinen wrote:
> > On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
> >> On 31 July 2012 13:21, Tomi Valkeinen wrote:
> >>
> >> > 2) Have the configuration for countless panels specified in the DT data
> >> >
On 31 July 2012 13:44, Tomi Valkeinen wrote:
> On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
>> On 31 July 2012 13:21, Tomi Valkeinen 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 co
On 07/30/2012 05:31 PM, Turquette, Mike wrote:
On Mon, Jul 30, 2012 at 4:02 PM, Russell King - ARM Linux
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 wrote:
So if we make a change like this one, it seems like we would
On Tue, 2012-07-31 at 13:33 +0530, Jassi Brar wrote:
> On 31 July 2012 13:21, Tomi Valkeinen 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 generally, for all
On 31 July 2012 13:21, Tomi Valkeinen 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 of a message to m
On Tue, 2012-07-17 at 21:57 +0530, Jassi Brar wrote:
> [CC'ing OMAPDSS matinainer]
>
> On 17 July 2012 19:31, Raphael Assenat 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 that
51 matches
Mail list logo
