Tony Lindgren wrote:
> * Venkatraman S [100426 07:46]:
>> Tony Lindgren wrote:
>> > * Venkatraman S [100419 03:47]:
>> >> Hi Tony,
>> >> > Venkatraman S wrote:
>> >> > From 2799506180649cbb61d24cf2b4171425b2e1fa80 Mon Sep 17 00:00:00 2001
>> >> > From: Venkatraman S
>> >> > Date: Mon, 5 Apr 2
On Fri, Apr 30, 2010 at 07:49:20PM +0530, Govindarajan, Sriramakrishnan
wrote:
> >
> [Sriram] Dmitry, once you have reviewed the changes, should I re-post
> the patch series with your patch added to the series?
>
Sriram,
Thank you for reviewing my changes.
I folded my changes into your origina
Hello Lesly,
On Mon, Apr 19, 2010 at 01:43:00PM +0200, ext Lesly A M wrote:
> This patch will fix the TRITON sleep/wakeup sequence.
OK.
>
> Since the function to populate the sleep script is getting called always
> irrespective of the flag "TWL4030_SLEEP_SCRIPT", other scripts data
> is getting
On Thu, Apr 22, 2010 at 12:09 PM, Russell King wrote:
> On Wed, Apr 21, 2010 at 11:50:56PM +0530, kishore kadiyala wrote:
>> This patch adds dummy Interface clocks for MMC controllers
>
> Looks to me as if it changes the formatting; it doesn't seem to be adding
> anything.
I have already asked to
>> - Original Message -
>> From: "Datta, Shubhrajyoti"
>> >
>> > From: Datta, Shubhrajyoti
>> > Sent: Monday, May 03, 2010 11:07 AM
>> > To: Datta, Shubhrajyoti
>> > Subject: [RFC][PATCH1/2] SFH7741: proximity sensor driver support
>> >
>>
>> > +
>> > +static irqreturn_t sfh7741_isr(int ir
On Thu, Apr 22, 2010 at 12:38 AM, Tony Lindgren wrote:
> * kishore kadiyala [100421 11:16]:
>> Since OMAP4's card detection doesn't support GPIO,this patch
>> basically moves card detection API from driver to Board file so
>> that it can handle in both GPIO and NON-GPIO case.
>> This Patch also a
From: "ext Kanigeri, Hari"
Subject: RE: [RFC/PATCH 6/8] omap: mailbox: more more stuff to omap2_mbox_init
Date: Mon, 3 May 2010 20:50:39 +0200
> Felipe,
>
>> > Small suggestion...if we are re-organizing can we make it look similar
>> to how iommu is structured? This way we can maintain consisten
On Thu, Apr 22, 2010 at 2:30 AM, Tony Lindgren wrote:
> * kishore kadiyala [100421 11:16]:
>> This patch adds PBIAS Configuration during POWER ON and OFF.
>> Also it adds MMC1 Card detect configuration on Phoenix
>>
>> Signed-off-by: Kishore Kadiyala
>> ---
>> arch/arm/mach-omap2/hsmmc.c
Tony,
Would you please check if there are no further comments and could you pull them
in?
1/8: https://patchwork.kernel.org/patch/92220/
2/8: https://patchwork.kernel.org/patch/92232/
3/8: https://patchwork.kernel.org/patch/92221/
4/8: https://patchwork.kernel.org/patch/92230/
5/8: https://patchw
Ghorai, Sukumar would like to recall the message, "[PATCH] nand support on
omap3 boards".--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 22, 2010 at 12:17 AM, Tony Lindgren wrote:
> * kishore kadiyala [100421 11:15]:
>> This patch adds MMC1 and MMC2 Controller support for OMAP4430 Board
>> file.
>>
>> Signed-off-by: Kishore Kadiyala
>> ---
>> arch/arm/mach-omap2/Makefile | 3 +-
>> arch/arm/mach-omap2/board
Tony,
Would you please check if there are no further comments and could you pull them
in?
1/8: https://patchwork.kernel.org/patch/92220/
2/8: https://patchwork.kernel.org/patch/92232/
3/8: https://patchwork.kernel.org/patch/92221/
4/8: https://patchwork.kernel.org/patch/92230/
5/8: https://patchw
From: "ext Aguirre, Sergio"
Subject: RE: [Query][omap iommu] Consulting iommu if a physical region is
"mappable" before actually mapping it
Date: Mon, 3 May 2010 21:23:46 +0200
>
>
>> -Original Message-
>> From: Kanigeri, Hari
>> Sent: Monday, May 03, 2010 2:09 PM
>> To: Aguirre, Sergi
Hi,
> >> -Original Message-
> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> >> ow...@vger.kernel.org] On Behalf Of Cliff Brake
> >> Sent: Wednesday, April 28, 2010 7:40 PM
> >> To: Linux OMAP Users
> >> Subject: omap_musb_board_data -- trouble specifying 500mA supply
> >>
Hi,
> >> Kroah-Hartman; Subbrathnam, Swaminathan
> >> Subject: Re: [PATCH 2/2 v2] USB: musb: disable double buffering for
> older
> >> RTL versions
> >>
> >> On Tue, Apr 06, 2010 at 01:46:29PM +0200, ext Gadiyar, Anand wrote:
> >> >With g_zero, do you see a hang or do you have data corruption?
> >>
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: cbus
Initial commit ID (Likely to change): 749c6d8eaac8cd49b3d53eb7fb708ce61787a3a1
PatchWorks
http://patchwork.kernel.org/patch/96299/
Git (Likely to change, and takes a while to get mirrored)
htt
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: cbus
Initial commit ID (Likely to change): f746c048052046009eafd6f71041204967e231a3
PatchWorks
http://patchwork.kernel.org/patch/96298/
Git (Likely to change, and takes a while to get mirrored)
htt
And here's this patch one more time. Both 2a and 2b are needed
for zoom debug uart to work.
Regards,
Tony
>From 1ed9c6a7dc9dea18ab1f5dd07ecec7e89ffa1ec5 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Fri, 30 Apr 2010 12:57:14 -0700
Subject: [PATCH] omap2/3: Fix DEBUG_LL for omap zoom2/3
Zoo
Here's this patch one more time. I updated the comments
for what I think the new shortcomings are.
I also changed #define OMAP_UART_INFO (PHYS_OFFSET + 0x3ffc)
instead of 0x3ff8 as it's set as u32.
Regards,
Tony
>From 96554d70775e936e870f61d9523c9bab3fd54ad6 Mon Sep 17 00:00:00 2001
From: Tony L
* Tony Lindgren [100430 13:47]:
> * Tony Lindgren [100430 13:32]:
> > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC
> > at least on zoom3 for multi-omap. Disable CONFIG_FB until the
> > omap FB code is fixed.
>
> This one I'll drop as soon as the problem is sorted out with
> CO
* Pandita, Vikram [100503 15:06]:
>
>
> >-Original Message-
> >From: Tony Lindgren [mailto:t...@atomide.com]
> >Sent: Friday, April 30, 2010 8:51 PM
> >To: Kevin Hilman
> >Cc: Pandita, Vikram; linux-arm-ker...@lists.infradead.org; linux-
> >o...@vger.kernel.org; Pais, Allen
> >Subject: R
Previosuly update_resource_level() would always call the change_level()
function, even if there was no change necessary.
Signed-off-by: Mike Chan
---
arch/arm/plat-omap/resource.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/resource.c b/arch/ar
Take the resource mutex when iterating over the resource user_list.
A race can occur if resource_request() adds a first time user to
the user_list while update_resource_level() is called.
Signed-off-by: Mike Chan
---
arch/arm/plat-omap/resource.c |9 +++--
1 files changed, 7 insertions(+
With per-resource mutexes, mulitple threads can call resource_request()
which can cause get_user() to concurrently allocate from the static pool.
Take the res_mutex when allocating from the static pool, which is used
in resouce_request() and resource_release() to guard against this.
Signed-off-by:
On Mon, May 3, 2010 at 4:35 PM, Kevin Hilman
wrote:
> Mike Chan writes:
>
>> IO events can also come from GPIO modules, which reside in the PER domain.
>> It is possible for the PER to enter RET while CORE is still in ON.
>> If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
>> w
Mike Chan writes:
> IO events can also come from GPIO modules, which reside in the PER domain.
> It is possible for the PER to enter RET while CORE is still in ON.
> If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
> wakeup in this case, unless we enable it.
>
> Signed-off-by:
A series of OMAP GPIO updates for 2.6.35 from the OMAP PM branch.
Series based on v2.6.34-rc5.
Kevin
Chunqiu Wang (1):
OMAP3: GPIO: Only enable WAKEUPEN for edge detection GPIOs
Kevin Hilman (3):
OMAP2/3: GPIO: generalize prepare for idle
OMAP3: GPIO: disable GPIO debounce clocks on idle
Currently, the GPIO 'prepare' hook is only called when going to
off-mode, while the function is called 'prepare_for_retention.' This
patch renames the function to 'prepare_for_idle' and calls it for any
powersate != PWRDM_POWER_ON passing in the powerstate.
The hook itself is then responsible for
The generic gpiolib provides a debugfs interface to GPIOs which
provides identical (but nicer looking) data as the OMAP specific one.
This patch completely drops the OMAP specific interface
(/debug/omap_gpio) in favor of using the generic one (/debug/gpio.)
Signed-off-by: Kevin Hilman
---
arch/
Ensure GPIO debounce clocks are disabled when idle. Otherwise,
clocks will prevent PER powerdomain from entering retention.
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/gpio.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/
From: Tero Kristo
setwkuena and setdataout are covered already by wake_en and dataout fields.
Signed-off-by: Tero Kristo
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/gpio.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arc
From: Chunqiu Wang
According to the GPIO 'Wakeup and Interrupt' section of the TRM[1],
wake-up requests can only be generated on edge transitions.
Also for OMAP3, only edge GPIOs may lose interrupts when PER enters
RET/OFF state, this is addressed by gpio prepare|resume idle functions
[1] Secti
From: Tero Kristo
Off mode is now using the omap2 retention fix code for scanning GPIOs
during off-mode transitions. All the *non_wakeup_gpios variables
are now used for off-mode transition tracking on OMAP3. This patch fixes
cases where GPIO state changes are missed during off-mode.
Signed-off-
We can remove this wakeup dependency since now, when
GPIO2-6 are enabled for IO-pad wakeup, PER domain is gauranteed
to be awake or be woken up to service.
The previous dependency did not handle all corner cases. Since there
was no sleep dependency between CORE and PER domains, if PER enters
RET a
IO events can also come from GPIO modules, which reside in the PER domain.
It is possible for the PER to enter RET while CORE is still in ON.
If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
wakeup in this case, unless we enable it.
Signed-off-by: Mike Chan
---
arch/arm/mach-o
On Mon, May 3, 2010 at 3:40 PM, Kevin Hilman
wrote:
> Mike Chan writes:
>
>> IO events can also come from GPIO modules, which reside in the PER domain.
>> It is possible for the PER to enter RET while CORE is still in ON.
>> If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
>> w
Mike Chan writes:
> IO events can also come from GPIO modules, which reside in the PER domain.
> It is possible for the PER to enter RET while CORE is still in ON.
> If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
> wakeup in this case, unless we enable it.
>
> Signed-off-by:
>-Original Message-
>From: Tony Lindgren [mailto:t...@atomide.com]
>Sent: Friday, April 30, 2010 8:51 PM
>To: Kevin Hilman
>Cc: Pandita, Vikram; linux-arm-ker...@lists.infradead.org; linux-
>o...@vger.kernel.org; Pais, Allen
>Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2
From: Ari Kauppi
Millisecond resolution is possible and there are use cases for it
(automatic testing).
Seconds-based interface is preserved for compatibility.
Signed-off-by: Ari Kauppi
Reviewed-by: Phil Carmody
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c |3 +++
arch
While handling PRCM IRQs, mask out interrupts that are not enabled in
PRM_IRQENABLE_MPU. If these are not masked out, non-enabled
interrupts are caught, a WARN() is printed due to no 'handler' and the
events are cleared. In addition to being noisy, this can also
interfere with independent polling
From: Tero Kristo
This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this will prevent
on-going transmission to be cut
- Smartidle is now enabled/disabled only while switching clocks, as havi
A small series of OMAP PM core updates for 2.6.35.
Series based on Tony's omap-fixes branch and also availailable here:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-next
Kevin
Ari Kauppi (1):
OMAP3: PM: Add milliseconds interface to suspend wakeup timer
Kevin
IO events can also come from GPIO modules, which reside in the PER domain.
It is possible for the PER to enter RET while CORE is still in ON.
If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not
wakeup in this case, unless we enable it.
Signed-off-by: Mike Chan
---
arch/arm/mach-o
We can remove this wakeup dependency since now, when
GPIO2-6 are enabled for IO-pad wakeup, PER domain is gauranteed
to be awake or be woken up to service.
The previous dependency did not handle all corner cases. Since there
was no sleep dependency between CORE and PER domains, if PER enters
RET a
* Mike Rapoport [100503 13:28]:
> On Mon, May 3, 2010 at 9:24 PM, Tony Lindgren wrote:
> > * Mike Rapoport [100429 01:44]:
> >> Signed-off-by: Mike Rapoport
> >
> > Please add a proper description to all the patches.
> >
> >> --- a/arch/arm/mach-omap2/gpmc-nand.c
> >> +++ b/arch/arm/mach-omap2/
On Mon, May 3, 2010 at 9:24 PM, Tony Lindgren wrote:
> * Mike Rapoport [100429 01:44]:
>> Signed-off-by: Mike Rapoport
>
> Please add a proper description to all the patches.
>
>> --- a/arch/arm/mach-omap2/gpmc-nand.c
>> +++ b/arch/arm/mach-omap2/gpmc-nand.c
>> @@ -116,6 +124,11 @@ int __init gp
On Mon, May 03, 2010 at 02:51:25PM -0500, Sergio Aguirre wrote:
> This should complement changes done in:
>
> commit e7db7b4270ed2a606b8c0b5f944a5f92ade0e84c
> Author: Albin Tonnerre
> Date: Fri Jan 8 14:42:43 2010 -0800
>
> arm: add support for LZO-compressed kernels
>
> It misse
This should complement changes done in:
commit e7db7b4270ed2a606b8c0b5f944a5f92ade0e84c
Author: Albin Tonnerre
Date: Fri Jan 8 14:42:43 2010 -0800
arm: add support for LZO-compressed kernels
It missed to do the respective changes in '.gitignore' file.
Also, add vmlinux to the lis
> -Original Message-
> From: Kanigeri, Hari
> Sent: Monday, May 03, 2010 2:09 PM
> To: Aguirre, Sergio; Hiroshi DOYU
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [Query][omap iommu] Consulting iommu if a physical region is
> "mappable" before actually mapping it
>
> Sergio,
>
> >
> >
On Mon, May 3, 2010 at 9:50 PM, Kanigeri, Hari wrote:
>> > Small suggestion...if we are re-organizing can we make it look similar
>> to how iommu is structured? This way we can maintain consistency.
>>
>> I thought I did. What exactly do you have in mind?
>
> 1. What Tony mentioned in anoth
Sergio,
>
> Can the iommu driver be "consulted" if a certain area (contiguous or not)
> can be mapped or not, before even trying to do it?
>
-- As long as there are physical pages backing the area it should be mappable
right ?
Thank you,
Best regards,
Hari
--
To unsubscribe from this list: se
> -Original Message-
From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de]
Sent: Monday, May 03, 2010 1:44 PM
> On Mon, May 03, 2010 at 10:24:07AM -0500, Aguirre, Sergio wrote:
> >
> >
> > From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de]
> > Sent: Sunday, May 02, 20
Felipe,
> > Small suggestion...if we are re-organizing can we make it look similar
> to how iommu is structured? This way we can maintain consistency.
>
> I thought I did. What exactly do you have in mind?
1. What Tony mentioned in another email about using #ifdefs for the
platforms. Th
On Mon, May 03, 2010 at 10:24:07AM -0500, Aguirre, Sergio wrote:
>
>
> From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de]
> Sent: Sunday, May 02, 2010 7:21 AM
> > On Thu, Feb 25, 2010 at 09:55:45AM -0600, Sergio Aguirre wrote:
> > > This should complements changes done in:
> > I think
* Kevin Hilman [100503 11:19]:
> Tony Lindgren writes:
>
> > * Kevin Hilman [100503 10:00]:
> >> Tony Lindgren writes:
> >>
> >> > * Kevin Hilman [100503 08:58]:
> >> >> Mika Westerberg writes:
> >> >>
> >> >> > If we are softbooting another kernel using kexec, DMA controller
> >> >> > st
* Mike Rapoport [100429 01:44]:
> Signed-off-by: Mike Rapoport
Please add a proper description to all the patches.
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
> @@ -116,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
> *_nand_data)
>
Tony Lindgren writes:
> * Kevin Hilman [100503 10:00]:
>> Tony Lindgren writes:
>>
>> > * Kevin Hilman [100503 08:58]:
>> >> Mika Westerberg writes:
>> >>
>> >> > If we are softbooting another kernel using kexec, DMA controller state
>> >> > is not
>> >> > known when we are performing omap
On Mon, May 3, 2010 at 9:10 PM, Tony Lindgren wrote:
> * Felipe Contreras [100502 16:58]:
>> Makes more sense to register in the mach file, plus it will allow more
>> functionality later on.
>>
>> Also, this probably enables multi-omap for real.
>>
>> Signed-off-by: Felipe Contreras
>
>
>
>> --
* Felipe Contreras [100502 16:58]:
> Makes more sense to register in the mach file, plus it will allow more
> functionality later on.
>
> Also, this probably enables multi-omap for real.
>
> Signed-off-by: Felipe Contreras
> --- a/arch/arm/mach-omap2/mailbox.c
> +++ b/arch/arm/mach-omap2/ma
* Ohad Ben-Cohen [100502 08:40]:
> Fix reverse likeliness
>
> Signed-off-by: Ohad Ben-Cohen
> ---
> If you want, you can also reach me at < ohadb at ti dot com >.
>
> arch/arm/plat-omap/mailbox.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-om
* Kevin Hilman [100503 10:00]:
> Tony Lindgren writes:
>
> > * Kevin Hilman [100503 08:58]:
> >> Mika Westerberg writes:
> >>
> >> > If we are softbooting another kernel using kexec, DMA controller state
> >> > is not
> >> > known when we are performing omap_init_dma(). It is possible that s
Tony Lindgren writes:
> * Kevin Hilman [100503 08:58]:
>> Mika Westerberg writes:
>>
>> > If we are softbooting another kernel using kexec, DMA controller state is
>> > not
>> > known when we are performing omap_init_dma(). It is possible that some DMA
>> > channels are already active. For ex
On Mon, May 03, 2010 at 06:54:57 -0500, Woodruff, Richard wrote:
> Hi Alex,
Hi,
> > From: virtu...@slind.org [mailto:virtu...@slind.org]
> > Sent: Saturday, May 01, 2010 12:38 PM
>
> Do you have a web viewable git tree where your full patch is applied? Or
> could you send me on the side files?
* Mika Westerberg [100503 05:52]:
> If we are softbooting another kernel using kexec, DMA controller state is not
> known when we are performing omap_init_dma(). It is possible that some DMA
> channels are already active. For example after kexec we get:
>
> <4>IRQ 0020 for non-allocated DMAchanne
* Kevin Hilman [100503 08:58]:
> Mika Westerberg writes:
>
> > If we are softbooting another kernel using kexec, DMA controller state is
> > not
> > known when we are performing omap_init_dma(). It is possible that some DMA
> > channels are already active. For example after kexec we get:
> >
>
* Venkatraman S [100426 07:46]:
> Tony Lindgren wrote:
> > * Venkatraman S [100419 03:47]:
> >> Hi Tony,
> >> > Venkatraman S wrote:
> >> > From 2799506180649cbb61d24cf2b4171425b2e1fa80 Mon Sep 17 00:00:00 2001
> >> > From: Venkatraman S
> >> > Date: Mon, 5 Apr 2010 20:56:27 +0530
> >> > Subje
Hi,
This is an update regarding the status on the patches needed to have KS8851 SNL
SPI based network controller in OMAP4430.
This patch has been accepted
0001-OMAP4-Clocks-Change-SPI-Instance-Names.patch
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26951.html
No comments for t
Nishanth Menon writes:
> init_opp is seen to crash, in resource34xx.c BUG() causes
> a kernel oops when OPP layer is not registered!
>
> Original Report:
> http://marc.info/?l=linux-omap&m=127268352116119&w=2
>
> Cc: Peter Tseng
> Cc: Kevin Hilman
> Reported-by: Peter Tseng
> Signed-off-by: Ni
Mika Westerberg writes:
> If we are softbooting another kernel using kexec, DMA controller state is not
> known when we are performing omap_init_dma(). It is possible that some DMA
> channels are already active. For example after kexec we get:
>
> <4>IRQ 0020 for non-allocated DMAchannel 5
> <4>I
Upcoming change to tlv320aic3x codec driver require four supplies.
Implement this by connecting analogic supplies to TWL4030 VMMC2 and digital
supplies to TWL4030 VIO.
Signed-off-by: Jarkko Nikula
Cc: Eduardo Valentin
---
Analogic supplies were able to find from Maemo kernel sources and earlie
This makes possible to probe the audio codec and add another i2c2
components in the future.
Fix also indentation for the first omap_register_i2c_bus.
Signed-off-by: Jarkko Nikula
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-
I believe the VMMC2 constraints must be the same than with VAUX3. Older
boards are using TWL4030 VMMC2 supply for internal MMC whereas newer are
using VAUX3 that has more limited constraints defined in this same file.
More over, the VMMC2 supply is used also for analog audio domain and the
miminum
From: Uwe Kleine-König [mailto:u.kleine-koe...@pengutronix.de]
Sent: Sunday, May 02, 2010 7:21 AM
> On Thu, Feb 25, 2010 at 09:55:45AM -0600, Sergio Aguirre wrote:
> > This should complements changes done in:
> I think this should read "complement" only, that is, no 's' at the end.
> Other than t
On Mon, May 3, 2010 at 4:42 PM, Kanigeri, Hari wrote:
> Small suggestion...if we are re-organizing can we make it look similar to how
> iommu is structured? This way we can maintain consistency.
I thought I did. What exactly do you have in mind?
Also, I noticed that since you made omap3-iommu n
On Thu, 2010-04-22 at 10:23 +0200, ext Koen Kooi wrote:
> This patch adds DSS2 support to the beagleboard boardfile. DVI and TV-out are
> supported.
>
> Signed-off-by: Koen Kooi
Acked-by: Tomi Valkeinen
> ---
> Changes since v1:
> * removed beagle_panel_enable_tv() and beagle_panel_disab
Am Samstag, 1. Mai 2010 04:12:19 schrieb Ashwin Bihari:
> On Thu, Apr 29, 2010 at 1:18 PM, Zygo Blaxell
>
> wrote:
> > On Thu, Aug 20, 2009 at 06:02:06PM +0200, Stephan Linz wrote:
> >> Am Mittwoch, 19. August 2009 schrieb Peter Barada:
> >> > 1) Does anyone have a URL of the format patches should
Felipe,
Small suggestion...if we are re-organizing can we make it look similar to how
iommu is structured? This way we can maintain consistency.
Thank you,
Best regards,
Hari
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On
If we are softbooting another kernel using kexec, DMA controller state is not
known when we are performing omap_init_dma(). It is possible that some DMA
channels are already active. For example after kexec we get:
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel
Hi Alex,
> From: virtu...@slind.org [mailto:virtu...@slind.org]
> Sent: Saturday, May 01, 2010 12:38 PM
Do you have a web viewable git tree where your full patch is applied? Or could
you send me on the side files?
Main bit I was looking to check was that you have bug fix which came late in my
OMAP3530 TRM section 7.4.4.4.2 requires OFFOUTENABLE to be set (active low)
if wakeup capabilities are enabled on a pad. During OFF mode testing
on OMAP3530 EVM, it was observed that the device was not residing in
the OFF state. The device enters into the OFF state and immediately exits
from that s
The underlying buffering implementation of mailbox
is converted from block API to kfifo due to the simplicity
and speed of kfifo.
The default size of the kfifo buffer is set to 256 bytes.
This value is configurable at compile time (via
CONFIG_OMAP_MBOX_KFIFO_SIZE), and can be changed at
runtime (v
On Mon, May 3, 2010 at 9:07 AM, Hiroshi DOYU wrote:
> From: Hiroshi DOYU
> Subject: Re: [PATCH v2 4/4] omap: mailbox: convert block api to kfifo
> Date: Mon, 03 May 2010 08:30:36 +0300 (EEST)
>
>> Hi Ohad,
>>
>> From: ext Ohad Ben-Cohen
>> Subject: [PATCH v2 4/4] omap: mailbox: convert block api
> -Original Message-
> From: V, Hemanth
> Sent: Monday, May 03, 2010 1:27 PM
> To: Datta, Shubhrajyoti; linux-in...@vger.kernel.org; linux-
> o...@vger.kernel.org
> Subject: Re: [RFC][PATCH1/2] SFH7741: proximity sensor driver support
>
> - Original Message -
> From: "Datta, Shub
- Original Message -
From: "Datta, Shubhrajyoti"
From: Datta, Shubhrajyoti
Sent: Monday, May 03, 2010 11:07 AM
To: Datta, Shubhrajyoti
Subject: [RFC][PATCH1/2] SFH7741: proximity sensor driver support
Driver support for the proximity sensor SFH7741.
Signed-off-by: Shubhro
---
drivers
On Sat, 1 May 2010 21:01:10 +0300
Felipe Balbi wrote:
> From: Felipe Balbi
>
> no functional changes, just using kzalloc().
>
> compile tested with n8x0_defconfig and n770_defconfig
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/cbus/retu-user.c |6 +++---
> drivers/cbus/tahvo-usb.c
On Sat, 1 May 2010 21:01:09 +0300
Felipe Balbi wrote:
> From: Felipe Balbi
>
> commit 5a0e3ad6af8660be21ca98a971cd00f331318c05 broke
> compilation of the retu-pwrbutton driver when it dropped
> implicit inclusion of slab.h and gfp.h.
>
> Fix it by including slab.h on retu-pwrbutton.c, while a
86 matches
Mail list logo
