> ps: you really think that adding more and more ifdefs is better than
> Amit's patch ??
We can avoid using #ifdefs by introducing '.neednop' flag to board_data.
Here is the patch for this which can be used on top of my earlier patch.
--- cut here ---
diff --git a/arch
On Tue, 25 May 2010 13:21:27 +0100, Jonathan Cameron wrote:
> On 05/25/10 13:12, Datta, Shubhrajyoti wrote:
> >
> > Adds the driver support for the TMP105 temperature sensor device. The
> > interface is I2C.The driver supports the read of the temperature values.
> >
> Still on the wrong list... c
Hi,
> On Mon, May 24, 2010 at 09:07:37AM +0200, ext Gupta, Ajay Kumar wrote:
> >> Attempting to remove usb_nop_xceiv_register() completely will require
> >> someone
> >> with more knowledge of davinci and blackfin archs to comment on what
> >> boards
> >> need the platform_device defined.
> >
> >NA
On Mon, May 24, 2010 at 09:07:37AM +0200, ext Gupta, Ajay Kumar wrote:
Hi,
Here is a compile-tested patch since I haven't seen this fixed in mainline
yet. It applies to the tip of Linus' tree.
Attempting to remove usb_nop_xceiv_register() completely will require
someone
with more knowledge of
Hi,
On Sun, May 23, 2010 at 01:53:10AM +0200, ext Amit Kucheria wrote:
From 3df714f995b0895e905090760482194233f66a1d Mon Sep 17 00:00:00 2001
Message-Id:
<3df714f995b0895e905090760482194233f66a1d.1274570700.git.amit.kuche...@canonical.com>
From: Amit Kucheria
Date: Sun, 23 May 2010 01:35:00 +0
Le mardi 25 mai 2010 à 21:02 -0500, Arce, Abraham a écrit :
> Thanks David,
>
> > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > > index f8abf68..eb81f76 100644
> > > --- a/net/core/skbuff.c
> > > +++ b/net/core/skbuff.c
> > > @@ -334,7 +334,7 @@ static void skb_release_data(struct sk_bu
Thanks David,
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index f8abf68..eb81f76 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -334,7 +334,7 @@ static void skb_release_data(struct sk_buff *skb)
> > if (!skb->cloned ||
> > !atomic_sub_return(skb->n
From: "Arce, Abraham"
Date: Tue, 25 May 2010 20:48:02 -0500
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index f8abf68..eb81f76 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -334,7 +334,7 @@ static void skb_release_data(struct sk_buff *skb)
> if (!skb->cloned ||
Hi,
I am able to avoid the NULL pointer dereference but not sure if the handling
is the correct one... find the patch below...
> I have 2 scenarios in which I am getting a NULL pointer dereference:
>
> 1) root filesystem over nfs
> 2) telnet connection
>
> The issue appeared on this commit
>
>
* Russell King - ARM Linux [100522 14:53]:
> I'm going to take a slightly different approach to LMB given the
> (unique) problems that OMAP has with converting over to LMB. I've
> been re-ordering my patchset so that we do as many changes as
> possible to sanitize the code before introducing LMB.
--- On Tue, 5/25/10, Kevin Hilman wrote:
> >> > This is a load of crap. If probe() fails that
> means that driver does not
> >> > manage the device
And thus, dev->driver shouldn't be assigned ...
That probe() looks very odd, lately, yes. It seems
to have changed a lot over the past few years
* Tomi Valkeinen [100521 01:03]:
> On Thu, 2010-05-20 at 00:33 +0200, ext Steve Sakoman wrote:
> > I did a quick test build of the current linux-omap head and get a
> > failure very early on in the boot process in
> > drivers/video/omap2/vram.c code:
> >
> > Illegal SDRAM size for VRAM
> >
>
On Tue, May 25, 2010 at 03:18:13PM -0700, Kevin Hilman wrote:
> Mike Frysinger writes:
>
> > On Tue, May 25, 2010 at 17:46, Kevin Hilman wrote:
> >> After digging into the driver core and realizing that it seemed to
> >> have sane error handling itself, I took a closer look at
> >> ads7846_probe(
* Amit Kucheria [100522 17:05]:
> Tony,
>
> I see the following build failure with the latest tip from Linus. I'm not
> sure if something is yet to be merged for other subsystem trees before -rc1,
> but a patch to fix the build is attached.
Thanks, adding into omap-fixes queue for the -rc series
Mike Frysinger writes:
> On Tue, May 25, 2010 at 17:46, Kevin Hilman wrote:
>> After digging into the driver core and realizing that it seemed to
>> have sane error handling itself, I took a closer look at
>> ads7846_probe() and discovered it doesn't actually return an error
>> code for certain f
On Tue, May 25, 2010 at 17:46, Kevin Hilman wrote:
> After digging into the driver core and realizing that it seemed to
> have sane error handling itself, I took a closer look at
> ads7846_probe() and discovered it doesn't actually return an error
> code for certain failure cases! That was the roo
Dmitry Torokhov writes:
> On Tue, May 25, 2010 at 12:52:12PM -0700, Kevin Hilman wrote:
>> Dmitry Torokhov writes:
>>
>> > On Tue, May 18, 2010 at 04:46:53PM -0700, Kevin Hilman wrote:
>> >> If the _probe() method fails, the 'ts' struct is freed, yet it is
>> >> still used as the drvdata passed
On Tue, May 25, 2010 at 12:52:12PM -0700, Kevin Hilman wrote:
> Dmitry Torokhov writes:
>
> > On Tue, May 18, 2010 at 04:46:53PM -0700, Kevin Hilman wrote:
> >> If the _probe() method fails, the 'ts' struct is freed, yet it is
> >> still used as the drvdata passed to suspend/resume/remove methods
Dmitry Torokhov writes:
> On Tue, May 18, 2010 at 04:46:53PM -0700, Kevin Hilman wrote:
>> If the _probe() method fails, the 'ts' struct is freed, yet it is
>> still used as the drvdata passed to suspend/resume/remove methods.
>> Even though the input device does not get registerd, the driver's
>
On Tue, May 25, 2010 at 02:39:17PM +0530, DebBarma, Tarun Kanti wrote:
> #ifdef CONFIG_VFPv3
> @ d16 - d31 registers
> - .irpdr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
> -1: mrrcp11, 3, r0, r1, c\dr@ fmrrd r0, r1, d\dr
> + .irpdr,16,17,18,19,20,21,22,23,24,25,26,27,28
Hello,
On Tue, May 25, 2010 at 8:49 AM, Felipe Balbi wrote:
> On Mon, May 24, 2010 at 09:14:24PM +0200, ext Felipe Contreras wrote:
>> Now, I am pretty sure that platform_device.h will always depend on
>> device.h that's why I removed them, but I can add them again if
>> somebody wants to, but ag
Monday 24 May 2010 09:26:03 Tomi Valkeinen napisał(a):
> Hi,
>
> On Sun, 2010-05-23 at 14:09 +0200, ext Janusz Krzysztofik wrote:
> > Monday 17 May 2010 03:20:13 Janusz Krzysztofik wrote:
> > > I was observing the following error messages on my OMAP1 based Amstrad
> > > Delta board when first chang
"Govindraj.R" writes:
> Rebased on latest pm/wip-uart branch.
Still doesn't apply for me, either on pm-wip/uart or on top of your
series: [pm-wip/uart][PATCH 0/6]: Serial HWMOD updation and cleanup.
Please just include in your updates series which should include the
get_resource_byname() chang
Tero Kristo writes:
> From: Tero Kristo
>
> The kernel timer queue is being run currently from a GP timer running in a one
> shot mode, which works in a way that when it expires, it will also stop.
> Usually during this situation, the interrupt handler will ack the interrupt,
> load a new value
Felipe Contreras writes:
> On Tue, May 25, 2010 at 5:49 PM, Kevin Hilman
> wrote:
>> Felipe Contreras writes:
>>
>>> On Tue, May 25, 2010 at 3:00 AM, Kevin Hilman
>>> wrote:
Felipe Contreras writes:
[...]
> -static struct platform_device mbox_device = {
> - .name
Hi,
I am working on adding the support of an omap3 based board in the
kernel. This board uses an ADS7843 touchscreen controller, on the SPI
bus. The in-kernel driver (drivers/input/touchscreen/ads7646.c) works
fine with the 2.6.33 kernel. When updating to the 2.6.34 kernel the
values reported by t
Hello Siarhei Siamashka,
Thanks for the inputs. Please see my comments.
-Original Message-
From: Siarhei Siamashka [mailto:siarhei.siamas...@gmail.com]
Sent: Tuesday, May 25, 2010 5:57 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subjec
On Tue, May 25, 2010 at 8:07 PM, Ghorai, Sukumar wrote:
[...]
>> > c. And how to know that ECC engine is in used other driver should not
>> use it? Any bit to know that ecc engine is busy, as we check for prefetch?
>> Do not really remember config registers. Perhaps there is no way.
>> But I guess
On Tue, May 25, 2010 at 5:49 PM, Kevin Hilman
wrote:
> Felipe Contreras writes:
>
>> On Tue, May 25, 2010 at 3:00 AM, Kevin Hilman
>> wrote:
>>> Felipe Contreras writes:
>>>
Only OMAP3 would work.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/devices.c
Felipe Contreras writes:
> On Tue, May 25, 2010 at 3:00 AM, Kevin Hilman
> wrote:
>> Felipe Contreras writes:
>>
>>> Only OMAP3 would work.
>>>
>>> Signed-off-by: Felipe Contreras
>>> ---
>>> arch/arm/mach-omap2/devices.c | 103
>>> +--
>>> arch/arm/mach
Vimal,
> -Original Message-
> From: Vimal Singh [mailto:vimal.neww...@gmail.com]
> Sent: Thursday, May 20, 2010 12:01 AM
> To: Ghorai, Sukumar
> Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
> t...@atomide.com; sako...@gmail.com; m...@compulab.co.il;
> artem.bityuts...@nok
On Tue, May 25, 2010 at 3:09 AM, Benoit Cousson wrote:
> Hi Govindraj,
>
> On 5/20/2010 3:38 PM, Govindraj.R wrote:
>>
>> With this patch we retain uart name and just "uart"
>> rather than uart_hwmod as per autogenerated file for
>> omap4 just to retain common names across hwmod data files.
>> Als
On Mon, 2010-05-24 at 19:02 +0200, ext Robert Nelson wrote:
> After 10mins, the display enters dpms mode (suspend) neither ssh or
> serial activity will resume the display. (not a bug, usb
> mouse/keyboard will of course awaken it..)
>
> But when reboot is called, it doesn't handle the display co
From: Tero Kristo
The kernel timer queue is being run currently from a GP timer running in a one
shot mode, which works in a way that when it expires, it will also stop.
Usually during this situation, the interrupt handler will ack the interrupt,
load a new value to the timer and start it again.
On Tuesday 25 May 2010, DebBarma, Tarun Kanti wrote:
> (Including ARM mailing list)
>
> From: Tarun Kanti Debbarma
>
> This patch attempts to fix two related problems:
>
> (1) vfp_get_double(), vfp_put_double() functions have VFPv3 specific
> implementation guarded within CONFIG_VFPv3 macro. The i
On 05/25/10 13:12, Datta, Shubhrajyoti wrote:
>
> Adds the driver support for the TMP105 temperature sensor device. The
> interface is I2C.The driver supports the read of the temperature values.
>
Still on the wrong list... cc'ing lm-sensors...
Please check MAINTAINERS for the correct mailing lis
Adds the driver support for the TMP105 temperature sensor device. The
interface is I2C.The driver supports the read of the temperature values.
Signed-off-by: Shubhrajyoti D
---
drivers/hwmon/Kconfig |3 ++-
drivers/hwmon/lm75.c |2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
d
Paul,
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, May 19, 2010 6:03 AM
> To: Reddy, Teerth
> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
> Subject: Re: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR
> stall in SDRC after a Warm
> From: Kevin Hilman [khil...@deeprootsystems.com]
> Sent: Monday, May 24, 2010 7:07 PM
> To: Raja, Govindraj; Aguirre, Sergio
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [pm-wip/uart][PATCH 2/6] Serial: Add UART4 hwmod data.
>
> "Govindraj.R" writes:
> not in my
> > This happening because
(Including ARM mailing list)
From: Tarun Kanti Debbarma
This patch attempts to fix two related problems:
(1) vfp_get_double(), vfp_put_double() functions have VFPv3 specific
implementation
guarded within CONFIG_VFPv3 macro. The intent is to access {d16-d31} additional
registers
provided in VF
From: Tarun Kanti Debbarma
This patch attempts to fix two related problems:
(1) vfp_get_double(), vfp_put_double() functions have VFPv3 specific
implementation
guarded within CONFIG_VFPv3 macro. The intent is to access {d16-d31} additional
registers
provided in VFPv3. However, it still wrongly
Hi Abraham,
On Tue, May 18, 2010 at 06:13:48PM -0500, Arce, Abraham wrote:
> Hi,
>
> Here you have the list of changes done so far for OMAP4 Keyboard
> Controller Support v2. I'll appreciate if someone else has more comments
> to share.
>
I finally had a chance to review the patches and I do n
On Thu 2010-05-13 21:08:14, Matthew Garrett wrote:
> On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote:
>
> > The system stays running because there's something to do. The system
> > won't suspend until all the processors hit the kernel idle loop and
> > the next_timer_interrupt_critic
Hi!
> > There are several general problems with the design of opportunistic
> > suspend and suspend-blocks.
> >
> > 1. The opportunistic suspend code bypasses existing Linux kernel code,
> >such as timers and the scheduler, that indicates when code
> >needs to run, and when the system is
Hi Enric,
I am facing the exact same problem with my board. I am using a Marvell 8686
SDIO module connected to OMAP3 on MMC2. It works in 2.6.27 but when upgrading
to 2.6.32 I am seeing CMD5 timing out. Could you please guide me to the
solution?
Best regards,
Neil
--
To unsubscribe f
45 matches
Mail list logo
