Hi,
On Mon, 2010-11-01 at 17:07 +0100, ext Grazvydas Ignotas wrote:
> hi,
>
> On Sat, Oct 30, 2010 at 11:40 AM, Maksim A. Boyko
> wrote:
> > Hi,
> >
> > I try to switch on "OMAP2/3 Display Subsystem Support" and "Omap frame
> > buffer support" on n810 (commit 8b4b01).
> >
> > In OMAP2/3 Display
On Mon, 2010-11-01 at 17:45 +0100, ext Bryan Wu wrote:
> On Mon, Nov 1, 2010 at 10:15 AM, Tomi Valkeinen
> wrote:
> > What we need is a common driver for all these dummy panels, and the
> > driver would contain configurations for all the supported panels. The
> > board file would pass the name of
On Mon, 2010-11-01 at 17:30 +0100, ext Namhyung Kim wrote:
> The MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937
> (memblock: Introduce default allocation limit and use it to replace
> explicit ones) so it breaks beagle board build as follows:
>
> CC drivers/video/omap2/vr
From: Shubhrajyoti D
At remove the free variable is wrongly updated.Attempting to solve the same.
Signed-off-by: Shubhrajyoti D
---
-[v2] Instead of using 0/1 use a macro
arch/arm/plat-omap/include/plat/mcbsp.h |3 +++
arch/arm/plat-omap/mcbsp.c | 10 +-
2 files cha
Hi Vishwa,
Thanks for your review
> -Original Message-
> From: Sripathy, Vishwanath
> Sent: Saturday, October 30, 2010 12:35 AM
> To: Datta, Shubhrajyoti; linux-omap@vger.kernel.org
> Cc: Pandita, Vikram; ABRAHAM, KISHON VIJAY
> Subject: RE: [PATCH] McBSP: Fix the free variable update at r
On Tue, 2 Nov 2010 15:54:48 +0530
shubhrajy...@ti.com wrote:
> From: Shubhrajyoti D
>
> At remove the free variable is wrongly updated.Attempting to solve the same.
>
> Signed-off-by: Shubhrajyoti D
> ---
> -[v2] Instead of using 0/1 use a macro
>
> arch/arm/plat-omap/include/plat/mcbsp.h |
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Datta, Shubhrajyoti
> Sent: Tuesday, November 02, 2010 3:55 PM
> To: linux-omap@vger.kernel.org
> Cc: Datta, Shubhrajyoti
> Subject: [PATCH v2] McBSP: Fix the free varia
From: Shubhrajyoti D
At remove the free variable is wrongly updated.Attempting to solve the same.
Signed-off-by: Shubhrajyoti D
Reported-by: Vikram Pandita
---
-[v2] Instead of using 0/1 use true/false
arch/arm/plat-omap/mcbsp.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions
> -Original Message-
> From: Jarkko Nikula [mailto:jhnik...@gmail.com]
> Sent: Tuesday, November 02, 2010 4:03 PM
> To: Datta, Shubhrajyoti
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH v2] McBSP: Fix the free variable update at remove.
>
> On Tue, 2 Nov 2010 15:54:48 +0530
> s
On 10/28/2010 5:27 PM, Gopinath, Thara wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Thursday, October 28, 2010 11:09 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
"Cousson, Benoit" writes:
> On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
>> This patch adds dev attributes for smartreflex modules
>> in the OMAP4 hwmod database. This patch also updates the
>> smartreflex rev in the smartreflex class data structure
>> in the OMAP4 hwmod database.
>>
>> Signed-of
On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
> config REGULATOR_TWL4030
> bool "TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC"
> depends on TWL4030_CORE
> + default y
> help
> This driver supports the voltage regulators provided by
> this fami
Omar Ramirez Luna writes:
> From: Paul Walmsley
>
> Update the DSP reset code in pm34xx.c to use one of the new SCM DSP
> boot control functions, omap2430_ctrl_set_dsp_bootmode().
>
> This reset code should be moved out to a separate function to be
> called by the hwmod reset process at some poi
MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937
(memblock: Introduce default allocation limit and use it to replace
explicit ones). This breaks build as below when CONFIG_TIDSPBRIDGE
is selected. Fix this.
CC arch/arm/plat-omap/devices.o
arch/arm/plat-omap/devices.c: In fu
Jean Pihet writes:
> The low power mode on the latest l-o master branch is broken, so I
> investigated a bit. Here are the results. This has been tested on
> OMAP3EVM and Beagleboard.
>
> The problem is that the CORE does not reach the desired mode (RET,
> OFF). It is caused by the I2C1 fclk that
Hi Kevin,
On 11/2/2010 10:10 AM, Kevin Hilman wrote:
"Cousson, Benoit" writes:
On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
wrote:
> On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
>
>> config REGULATOR_TWL4030
>> bool "TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC"
>> depends on TWL4030_CORE
>> + default y
>> help
>> This driver sup
#include directive, required for successfull
compilation of dependant boards (board-ams-delta for now), has been lost
somehow from arch/arm/mach-omap1/include/mach/camera.h on creation. Readd it.
Created and tested against linux-2.6.37-rc1.
Signed-off-by: Janusz Krzysztofik
---
arch/arm/mac
On Tue, Nov 2, 2010 at 3:31 PM, Anand Gadiyar wrote:
> MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937
> (memblock: Introduce default allocation limit and use it to replace
> explicit ones). This breaks build as below when CONFIG_TIDSPBRIDGE
> is selected. Fix this.
I would rath
On Tue, Nov 2, 2010 at 10:05 AM, Felipe Contreras
wrote:
> On Tue, Nov 2, 2010 at 3:31 PM, Anand Gadiyar wrote:
>> MEMBLOCK_REAL_LIMIT symbol was removed by the commit e63075a3c937
>> (memblock: Introduce default allocation limit and use it to replace
>> explicit ones). This breaks build as below
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote:
> On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
> wrote:
> > On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
> >
> >> config REGULATOR_TWL4030
> >> bool "TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC"
> >> dep
On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
> Add missing dependencies, and remove redundant ones, and select sensible
> defaults.
>
> This is more user-friendly, and logical.
>
> - TWL4030_CORE people should be able to compile without ARM
> - REGULATOR_TWL4030 if TWL4030_
2010/11/2 Uwe Kleine-König :
> On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote:
>> On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
>> wrote:
>> > On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
>> >
>> >> config REGULATOR_TWL4030
>> >> bool "TI TWL4030/TWL5030/
2010/11/2 Uwe Kleine-König :
> On Tue, Nov 02, 2010 at 02:14:13AM +0200, Felipe Contreras wrote:
>> Add missing dependencies, and remove redundant ones, and select sensible
>> defaults.
>>
>> This is more user-friendly, and logical.
>>
>> - TWL4030_CORE people should be able to compile without ARM
On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote:
> On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
> > This default is not suitable for non-OMAP platforms, it should be
> > conditional on OMAP or something if we're going to do this (though
> > generally we handle this with defconfigs r
On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote:
> 2010/11/2 Uwe Kleine-König :
> > Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by
> > default, too. (TWL4030_CORE doesn't depend on something omapish.)
> Yes, I think TWL4030_CORE should depend on OMAP3,
In the new code introduced with commit cf4c87abe238ec17cd0255b4e21abd949d7f811e,
"OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via
mach-omap2/mcbsp.c",
the way omap1 build is supposed to bypass omap2 specific functionality doesn't
optimize out all omap2 specific stuff. This breaks link
Hi,
On Wed, 2010-10-27 at 12:16 +0200, ext Samreen wrote:
> From: Rajkumar N
>
> Enable dss to process color formats with pre-mulitplied alpha.
> With this we can have alpha values defined for each pixel
> and hence can have different blending values for each pixel.
> sysfs entry has been create
On Tue, Nov 02, 2010 at 03:50:32PM +0100, Janusz Krzysztofik wrote:
> In the new code introduced with commit
> cf4c87abe238ec17cd0255b4e21abd949d7f811e,
> "OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via
> mach-omap2/mcbsp.c",
> the way omap1 build is supposed to bypass omap2 specific
On 10/26/2010 11:15 AM, Ramirez Luna, Omar wrote:
This is the patch series shared by Paul, for a short term fix to
a compile break due SCM layer layer violations from tidspbridge
driver, where the latter is used to write directly into registers
and use SCM layer macros, among other layer bypassin
There are 4 duplicated panel driver sin DSS2 display driver. They are similar
and dummy panel driver can support all them with specific panel configuration.
And new panel driver can be easily supported by adding panel configurations
into dummy panel driver.
This patchset introduces dummy panel dri
Still keep sharp_ls_panel driver, because it contains blacklight control driver.
Signed-off-by: Bryan Wu
---
drivers/video/omap2/displays/Kconfig | 18 -
drivers/video/omap2/displays/Makefile |3 -
drivers/video/omap2/displays/panel-generic.c | 174 ---
Dummy panel driver includes the driver and 4 similar panel configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With dummy panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just ad
Introduce some fields in struct panel, which will be used to match the right
panel configurations in dummy driver.
Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight
control driver code which will be moved out later. Then we can use dummy driver
for sharp_ls_panel.
Sig
On 11/2/2010 9:43 PM, Bryan Wu wrote:
There are 4 duplicated panel driver sin DSS2 display driver. They are similar
and dummy panel driver can support all them with specific panel configuration.
And new panel driver can be easily supported by adding panel configurations
into dummy panel driver.
On Tue, 2 Nov 2010, Janusz Krzysztofik wrote:
> In the new code introduced with commit
> cf4c87abe238ec17cd0255b4e21abd949d7f811e,
> "OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via
> mach-omap2/mcbsp.c",
> the way omap1 build is supposed to bypass omap2 specific functionality
> doe
On Tue, Nov 2, 2010 at 6:13 PM, Bryan Wu wrote:
> Still keep sharp_ls_panel driver, because it contains blacklight control
> driver.
>
> Signed-off-by: Bryan Wu
> ---
> drivers/video/omap2/displays/Kconfig | 18 -
> drivers/video/omap2/displays/Makefile | 3 -
>
On Tue, Nov 2, 2010 at 6:13 PM, Bryan Wu wrote:
> Dummy panel driver includes the driver and 4 similar panel configurations. It
> will match the panel name which is passed from platform data and setup the
> right configurations.
>
> With dummy panel driver, we can remove those 4 duplicated panel d
On Tue, Nov 2, 2010 at 12:53 PM, Anand Gadiyar wrote:
> On 11/2/2010 9:43 PM, Bryan Wu wrote:
>>
>> There are 4 duplicated panel driver sin DSS2 display driver. They are
>> similar
>> and dummy panel driver can support all them with specific panel
>> configuration.
>> And new panel driver can be e
On Tue, Nov 2, 2010 at 1:21 PM, Grazvydas Ignotas wrote:
> On Tue, Nov 2, 2010 at 6:13 PM, Bryan Wu wrote:
>> Dummy panel driver includes the driver and 4 similar panel configurations. It
>> will match the panel name which is passed from platform data and setup the
>> right configurations.
>>
>>
On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown
wrote:
> On Tue, Nov 02, 2010 at 04:02:18PM +0200, Felipe Contreras wrote:
>> On Tue, Nov 2, 2010 at 3:11 PM, Mark Brown
>
>> > This default is not suitable for non-OMAP platforms, it should be
>> > conditional on OMAP or something if we're going to do th
On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown
wrote:
> On Tue, Nov 02, 2010 at 04:18:18PM +0200, Felipe Contreras wrote:
>> 2010/11/2 Uwe Kleine-König :
>
>> > Well, all platforms that have TWL4030_CORE will get REGULATOR_TWL4030 by
>> > default, too. (TWL4030_CORE doesn't depend on something omapis
On Tue, Nov 02, 2010 at 09:43:30PM +0200, Felipe Contreras wrote:
> On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown
> > This solution doesn't seem like it scales so well either, it just shifts
> > it into the Kconfig files (where everything is all in central files
> > shared by everyone which has its o
On Tue, Nov 02, 2010 at 09:46:47PM +0200, Felipe Contreras wrote:
> On Tue, Nov 2, 2010 at 4:39 PM, Mark Brown
> > It did originally but that dependency was removed to allow build
> > coverage for non-OMAP users.
> I'm not sure removing that dependency is worth it. There's probably a
> lot of cod
There are 4 duplicated panel drivers in DSS2 display driver. They are similar
and generic panel driver can support all them with specific panel configuration.
And new panel driver can be easily supported by adding panel configurations
into generic panel driver.
This patchset introduces generic pan
Generic panel driver includes the driver and 4 similar panel configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us jus
Introduce some fields in struct panel, which will be used to match the right
panel configurations in generic panel driver.
Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight
control driver code which will be moved out later. Then we can use generic
driver
for sharp_ls_
Still keep sharp_ls_panel driver, because it contains blacklight control driver.
Signed-off-by: Bryan Wu
---
drivers/video/omap2/displays/Kconfig | 12 --
drivers/video/omap2/displays/Makefile |2 -
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 --
48 matches
Mail list logo
