* Mike Rapoport [110504 09:35]:
> On 05/04/11 07:10, Oleg Drokin wrote:
> > Ok, so here's a simple patch to save everyone trouble, I guess.
> >
> > Though on the other hand I can imagine that perhaps including this generic
> > common-board-devices.c
> > might not be desirable for people that don
On 05/04/11 07:10, Oleg Drokin wrote:
> Ok, so here's a simple patch to save everyone trouble, I guess.
>
> Though on the other hand I can imagine that perhaps including this generic
> common-board-devices.c
> might not be desirable for people that don't use anything from that file.
Since the co
* Linus Walleij [110504 00:37]:
> 2011/5/3 Kevin Hilman :
>
> > Are you OK with a move of the current OMAP GPIO drivers (rather ugly)
> > into drivers/gpio first, followed by the cleanup/restructure patches?
>
> In my case I actually did some cleanup after moving the driver for
> U300, but I thi
On Wed, May 4, 2011 at 9:41 AM, Steve Sakoman wrote:
> On Tue, May 3, 2011 at 12:49 PM, J, KEERTHY wrote:
>> Hello Steve,
>>
>> Can you try adding this patch?
>
> Thanks!
>
> I tried the patch and it did indeed fix the issue. We should try to
> get this in mainline since the hwmon driver won't w
On Tue, May 3, 2011 at 12:49 PM, J, KEERTHY wrote:
> Hello Steve,
>
> Can you try adding this patch?
Thanks!
I tried the patch and it did indeed fix the issue. We should try to
get this in mainline since the hwmon driver won't work without it.
Steve
--
To unsubscribe from this list: send the l
Ok, so here's a simple patch to save everyone trouble, I guess.
Though on the other hand I can imagine that perhaps including this generic
common-board-devices.c
might not be desirable for people that don't use anything from that file.
Would it be a better idea to split it to a file-per-feature?
Hello!
This patch breaks compile for me:
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
> --- a/arch/arm/mach-omap2/common-board-devices.c
> +++ b/arch/arm/mach-omap2/common-board-devices.c
> @@ -29,6 +29,7 @@
...
> +void __init omap_nand_flash_init(int options, struct mtd_partition *part
Hello!
This patch breaks compile for me.
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
> --- /dev/null
> +++ b/arch/arm/mach-omap2/common-board-devices.c
> @@ -0,0 +1,85 @@
>
> +void __init omap_ads7846_init(int bus_num, int gpio_pendown, int
> gpio_debounce,
> +
Hi Charu,
"Varadarajan, Charulatha" writes:
> I tested the patch series in wip/gpio-cleanup branch.
Thanks so much for testing. It's a great help.
I've updated the branch based on some of your comments, and in
particular it should now boot on OMAP1.
Kevin
> Here are the results:
>
> Compile
Kevin Hilman writes:
> "Varadarajan, Charulatha" writes:
>
>> Kevin,
>>
>> On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
>>> Remove cpu_is_* checks from gpio_show_revision() by passing in the
>>> revision address offset from platform data. SoCs with no revision
>>> register (15xx, 7xx, an
2011/5/3 Kevin Hilman :
> Are you OK with a move of the current OMAP GPIO drivers (rather ugly)
> into drivers/gpio first, followed by the cleanup/restructure patches?
In my case I actually did some cleanup after moving the driver for
U300, but I think this is a question to the GPIO maintainer wh
Hello Steve,
Can you try adding this patch?
Regards,
Keerthy
On Tue, May 3, 2011 at 8:44 PM, Steve Sakoman wrote:
> On Wed, Mar 2, 2011 at 2:15 AM, Samuel Ortiz wrote:
>> Hi Keerthy,
>>
>> On Tue, Mar 01, 2011 at 07:12:06PM +0530, Keerthy wrote:
>>> MADC(Monitoring ADC) driver enables monitori
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> picodlp projector is supported by OMAP.
> OMAP4430 SDP and EVM boards have an on board projector called as picodlp
> projector.
> picodlp would be connected to display sub system as a display panel.
> It has a dlp processor dpp2600.
>
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> From: Mythri P K
>
> picodlp_i2c_client needs to send commands over i2c as a part of
> initialiazation.
> system controller dlp pico processor dpp2600 is used.
> It configures the splash screen of picodlp using a sequence of commands.
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> The configurations and data transfer with picodlp panel happens through i2c.
> An i2c client with name "picodlp_i2c_driver" is registered inside panel.
>
> dpp2600 requires 4 gpio lines for interfacing it with any processor,
> phy_reset
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> picodlp is a TI projector panel supported by OMAP
> picodlp makes use of i2c interface for transferring commands to the panel
> panel data is required for identifying i2c_adapter id and dlp GPIOs
>
> A new header file has been added for
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> From: Mythri P K
>
> A projector panel named picodlp is supported by OMAP.
> panel driver is required to be added with the name picodlp_panel.
>
> It is a WVGA panel with resolution 864 X 480 and panel timing data
> is defined in the
On Thu, Apr 28, 2011 at 12:47:25PM -0700, Greg KH wrote:
> On Thu, Apr 28, 2011 at 11:48:41AM -0700, Sutharsan wrote:
> > >From Sutharsan Ramamoorthy
> >
> > This patch replaces custom debug macros with Linux kernel's pr_...() macros.
>
> Why not use the dev_dbg() and other macros instead of the
Hi guys,
I'm thinking probably in a crazy idea, I hope someone can help me or
kill definitely this idea from my mind.
I'll explain a little more, the real problem is I don't know how to
add support for an expansion board for IGEP v2 board. I see most of
boards adds the support inside the board-xxx
"Varadarajan, Charulatha" writes:
> Kevin,
>
> On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
>> Remove cpu_is_* checks from gpio_show_revision() by passing in the
>> revision address offset from platform data. SoCs with no revision
>> register (15xx, 7xx, and all MPUIOs) use -1 to signify
"Varadarajan, Charulatha" writes:
> On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
>> Make _set_gpio_wakeup() generic by removing ifdefs. Code for the
>> various SoCs/bank-methods was already the same, except for the
>> non-wakeup GPIO checking. But that flag is set on a per-SoC basis, so
"Varadarajan, Charulatha" writes:
> Kevin,
>
> On Sat, Apr 23, 2011 at 04:31, Kevin Hilman wrote:
>> Remove the OMAP1 #ifdef and MPUIO special case for _clear_gpio_irqbank()
>>
>> The MPUIOs do not need a register access to ack/clear the IRQ status,
>> since reading the IRQ status clears it. In
"DebBarma, Tarun Kanti" writes:
> Kevin,
> [...]
>> >
>> > Here's an updated version of my work-in-progress GPIO cleanups.
>> >
>> > I now understand that others have some similar work in progress, so
>> > these are posted (to linux-omap only, for now) so that we can begin
>> > collaboration on t
Linus Walleij writes:
> 2011/4/26 Tony Lindgren :
>> * Linus Walleij [110423 01:32]:
>>> Since you'll probably be dependent on stuff happening in my patches
>>> to move stuff into drivers/gpio I'll be happy to carry the patches in my
>>> gpio-consolidation branch with Tony's ACKs if need be.
>>
On Fri, 2011-04-29 at 12:54 +0530, Santosh Shilimkar wrote:
Hi Santosh,
> On 4/21/2011 12:38 AM, Marc Zyngier wrote:
> > Use the normal interrupt scheme for the local timers by using
> > a remapped PPI interrupt.
> >
> > Tested on a Pandaboard.
> >
> > Cc: Tony Lindgren
> > Cc: Santosh Shilimkar
ping!
Just to make sure you haven't missed this one liner ;)
On 04/26/11 23:41, Igor Grinberg wrote:
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x11014): Section mismatch
> in reference from the function cm_t3517_init_usbh() to the (unknown
> reference) .init.data:(unknown)
> The function
Hi Kalle,
On Tuesday 03 May 2011 12:51:56 kalle.jokini...@nokia.com wrote:
> On 3. toukokuuta 2011 13:49 Laurent Pinchart wrote:
> > On Tuesday 03 May 2011 12:41:23 Kalle Jokiniemi wrote:
> > > The RX-51 uses the CSIb IO complex for camera operation. The
> > > board file is missing definition for
On Wed, Mar 2, 2011 at 2:15 AM, Samuel Ortiz wrote:
> Hi Keerthy,
>
> On Tue, Mar 01, 2011 at 07:12:06PM +0530, Keerthy wrote:
>> MADC(Monitoring ADC) driver enables monitoring analog signals using
>> analog-to-digital conversion (ADC) on the input source.
>> The previous discussion concluded in k
On Thu, Apr 14, 2011 at 2:27 PM, Lesly A M wrote:
> Patch series for TWL4030 power scripts and workaround for TWL erratum 27.
>
> Changes for implementing TWL4030 power scripts recommended by hardware team.
> Introduced a new TWL4030 power script file, which can be used by different
> OMAP3 board
Oleg Drokin wrote:
Hello!
Is there any special support needed for 3621, though?
My understanding is that's just 3630 without a "phone" part?
3621 is more or less a 3630 in a different package, less pins,
0.5mm ball pitch and no PoP option.
The .29 kernel they had only added is_omap3
For prefetch engine, read and write got broken in commit '2c01946c'.
We never hit a scenario of not getting 'gpmc_prefetch_enable'
call success.
When reading/writing a subpage with a non divisible by 4 ecc number
of bytes, the mis-aligned bytes gets handled first before enabling
the Prefetch engin
* Russell King - ARM Linux [110428 07:06]:
>
> This looks much better.
>
> Acked-by: Russell King
>
> It looks like Tony hasn't taken it... Tony, are you going to handle
> this patch?
I can add it into my devel-cleanup branch for next merge window
assuming it won't conflict with your sram ch
Hi,
> -Original Message-
> From: ext Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: 3. toukokuuta 2011 13:49
> To: Jokiniemi Kalle (Nokia-SD/Tampere)
> Cc: mauroche...@gmail.com; t...@atomide.com; linux-
> o...@vger.kernel.org; linux-me...@vger.kernel.org
> Subj
Hi Kalle,
Thanks for the patch.
On Tuesday 03 May 2011 12:41:23 Kalle Jokiniemi wrote:
> The RX-51 uses the CSIb IO complex for camera operation. The
> board file is missing definition for the regulator supplying
> the CSIb complex, so this is added for better power
> management.
>
> Signed-off-
The current omap3isp driver is missing regulator handling
for CSIb complex in omap34xx based devices. This patch
adds a mechanism for this to the omap3isp driver.
Signed-off-by: Kalle Jokiniemi
Acked-by: Laurent Pinchart
---
drivers/media/video/omap3isp/ispccp2.c | 27 +++
The RX-51 uses the CSIb IO complex for camera operation. The
board file is missing definition for the regulator supplying
the CSIb complex, so this is added for better power
management.
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++
1 files changed
The CSIb block is used in rx-51 to handle camera ccp2 IO. Adding
support to omap3isp driver for managing the power supply for the
CSIb IO complex via regulator framework. Also create the
apropriate regulator definitions in the rx-51 board file.
I propose to push this set through the linux-media, s
* Igor Grinberg [110428 00:13]:
> On 04/27/11 18:58, Grazvydas Ignotas wrote:
>
> > On Wed, Apr 27, 2011 at 5:01 PM, Tony Lindgren wrote:
> >> * Igor Grinberg [110427 02:02]:
> >>> use gpio_request_() instead of multiple gpiolib calls,
> >>> remove unneeded variables, etc.
> >> Great :)
> > I t
* Tony Lindgren [110502 07:18]:
> * Mike Rapoport [110502 06:54]:
> > ping?
>
> Looks OK to me, let's wait on Felipe's comments on the
> musb related stuff.
Applying this series into devel-cleanup for next merge
window.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscrib
On 5/3/2011 3:41 PM, Catalin Marinas wrote:
[...]
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index e9c2ff8..80b3d3c 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -89,7 +89,8 @@ static void gic_mask_irq(struct irq_data *d)
u32 mask = 1<< (d->irq % 32)
On Fri, 2011-04-29 at 07:22 +0100, Santosh Shilimkar wrote:
> The GIC register accesses today make use of readl()/writel()
> which prove to be very expensive when used along with mandatory
> barriers. This mandatory barriers also introduces an un-necessary
> and expensive l2x0_sync() operation. On
* gr...@linuxhacker.ru [110428 08:55]:
> From: Oleg Drokin
>
> Bare-bones board file, comes with serial console, gpio keys,
> MMC/SDCard and USB support.
Good to see that. Unfortunately you probably have to do few
more rebases on the devel-cleanup branch because of the code
consolidation effort
Hi,
> Most boards use exactly the same configuration for musb initialization.
> Create a default that can be shared amount different boards.
>
> Signed-off-by: Mike Rapoport
Acked-by: Felipe Balbi
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body o
On Tue, 2011-05-03 at 09:07 +0200, Enric Balletbo i Serra wrote:
> Hi all,
>
> These patches add support for two new panels to the generic-dpi-panel.
>
> The first patch adds support for the Seiko 70WVW1TZ3 LCD panel, and the second
> adds support for the Powertip PH480272T LCD panel.
>
> Tested
* Felipe Balbi [110502 07:22]:
> On Mon, May 02, 2011 at 07:20:52AM -0700, Tony Lindgren wrote:
> > * Oleg Drokin [110428 09:33]:
> > >
> > > So to me it looks like something totally in realm of musb driver itself.
> > > Nothing bad happens if you configure your MUSB as say OTG while in fact
>
* Menon, Nishanth [110426 14:05]:
> On Tue, Apr 26, 2011 at 11:25, Igor Grinberg wrote:
> >
> > replace "printk(KERN_ERR" by "pr_err("
> > and fix needlessly multi-lined #ifdef
> >
> > Signed-off-by: Igor Grinberg
>
> Acked-by: Nishanth Menon
Thanks, will queue this too. One line negative dif
* Mike Rapoport [110502 22:21]:
> Yeah, sorry about that.
> There's a fix at (1), I hope Tony will merge it soon.
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/56499/focus=56542
Will get merged soonish.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" i
* Igor Grinberg [110502 23:23]:
>
> > kobject (c06a4250): tried to init an initialized object, something is
> > seriously wrong.
> >
> > introduced by commit 66293989:
> > (omap: convert boards that use SMSC911x to use gpmc-smsc911x)
> >
> > fixed by allocating struct platform_device dynamically.
Add support for Powertip PH480242T, a LCD 4.3inch (480x242) display
type with 24-bit RGB interface, to panel-generic-dpi.
Tested with IGEP v2 board.
Signed-off-by: Enric Balletbo i Serra
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 inse
Add support for Seiko 70WVW1TZ3, a LCD 7.0inch WVGA (800x480) display
type with 24-bit RGB interface and Touch-Panel, to panel-generic-dpi
Tested with IGEP v2 board.
Signed-off-by: Enric Balletbo i Serra
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files
Hi all,
These patches add support for two new panels to the generic-dpi-panel.
The first patch adds support for the Seiko 70WVW1TZ3 LCD panel, and the second
adds support for the Powertip PH480272T LCD panel.
Tested with an IGEP v2 board.
Changes since v1:
- Change the names of both panels in
51 matches
Mail list logo