headers
Kevin Hilman | 1 Jul 2009 01:05

Re: [ARM][OMAP] TWL4030 IRQ

"Shilimkar, Santosh" <santosh.shilimkar <at> ti.com> writes:

> Kevin/Vikram,
> Can this patch be included on omap_pm branch to check for any regression?

Sure, I have it applied to the PM branch locally, but before I push,
can you (or Russell) send me a descriptive changelog for this patch.

Thanks,

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Alan Cox | 1 Jul 2009 01:20
Picon

Re: [PATCH v1 6/6][ARM] new ARM SoC support: BCMRing

On Tue, 30 Jun 2009 20:41:01 +0200
Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com> wrote:

> On 16:30 Fri 26 Jun     , Leo (Hao) Chen wrote:
> > Hi,
> > 
> > The last patch. This big patch includes the minimal set of our CSP (chip support package), which is our OS
independent chip supporting code and headers.  All the codes are under arch/arm/mach-bcmring directory.
> This patch is unreadable
> you need
> 1) Respect the Linux coding Style

For an OS independant set of chip support defines that usually makes no
sense

> 2) to split in small changeset

For a new submission that generally doesn't make much sense either - not
for all the new files stuff.
Permalink | Reply | 0 comments |
headers
Jean-Christophe PLAGNIOL-VILLARD | 1 Jul 2009 01:37

Re: [PATCH v1 6/6][ARM] new ARM SoC support: BCMRing

On 00:20 Wed 01 Jul     , Alan Cox wrote:
> On Tue, 30 Jun 2009 20:41:01 +0200
> Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com> wrote:
> 
> > On 16:30 Fri 26 Jun     , Leo (Hao) Chen wrote:
> > > Hi,
> > > 
> > > The last patch. This big patch includes the minimal set of our CSP (chip support package), which is our OS
independent chip supporting code and headers.  All the codes are under arch/arm/mach-bcmring directory.
> > This patch is unreadable
> > you need
> > 1) Respect the Linux coding Style
> 
> For an OS independant set of chip support defines that usually makes no
> sense
here it's really unreadable
IMHO as you will have to rewrite it to use the kernel API so it make sense
> 
> > 2) to split in small changeset
> 
> For a new submission that generally doesn't make much sense either - not
> for all the new files stuff.
here you have mixed timer, dma, irq, clock, and other new files in the same
patch, it's really hard to follow the patch. Split it a few will be easier
to review IMHO

Best Regards,
J.
Permalink | Reply | 0 comments |
headers
Leo (Hao) Chen | 1 Jul 2009 01:54
Favicon

RE: [PATCH v1 6/6][ARM] new ARM SoC support: BCMRing


> -----Original Message-----
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagnioj <at> jcrosoft.com] 
> Sent: Tuesday, June 30, 2009 4:38 PM
> To: Alan Cox
> Cc: Leo (Hao) Chen; linux-arm-kernel <at> lists.arm.linux.org.uk; 
> Linux Kernel
> Subject: Re: [PATCH v1 6/6][ARM] new ARM SoC support: BCMRing
> 
> On 00:20 Wed 01 Jul     , Alan Cox wrote:
> > On Tue, 30 Jun 2009 20:41:01 +0200
> > Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com> wrote:
> > 
> > > On 16:30 Fri 26 Jun     , Leo (Hao) Chen wrote:
> > > > Hi,
> > > > 
> > > > The last patch. This big patch includes the minimal set 
> of our CSP (chip support package), which is our OS 
> independent chip supporting code and headers.  All the codes 
> are under arch/arm/mach-bcmring directory.
> > > This patch is unreadable
> > > you need
> > > 1) Respect the Linux coding Style
> > 
> > For an OS independant set of chip support defines that 
> usually makes no
> > sense
> here it's really unreadable
> IMHO as you will have to rewrite it to use the kernel API so 
> it make sense
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Branden | 1 Jul 2009 01:57
Favicon

RE: [PATCH v1 6/6][ARM] new ARM SoC support: BCMRing

Alan,

We would really like to know what needs to change in our patchset.  We have a large codebase of drivers for
multiple chipsets already written that we have been maintaining internally and releasing for customer
development.  For code that patches existing linux code we follow the style dictated in those files.  But
for our new code we do not.

For our new code we have many developers who have written the code and thus a few "linux standard" coding
styles have not been followed.  Much driver code is split into an os-less portion and a linux wrapper
portion.  People have written following ISO/IEC 9899:1999 coding which allows such things as //
comments.  Also using tabs in our code is not a requirement.  

My question is do we need to change our entire codebase over to match linux coding standards for comments and
whitespace so it can pass a checkpatch script?  I'm sure there is a standard linux kernel community
response to this but I need to forward that answer (whatever it is) to our many developers so we know what it
is required to get our existing code integrated into the standard linux kernel.

Thanks,
 Scott

-----Original Message-----
From: linux-arm-kernel-bounces <at> lists.arm.linux.org.uk
[mailto:linux-arm-kernel-bounces <at> lists.arm.linux.org.uk] On Behalf Of Alan Cox
Sent: June 30, 2009 4:21 PM
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Leo (Hao) Chen; linux-arm-kernel <at> lists.arm.linux.org.uk; Linux Kernel
Subject: Re: [PATCH v1 6/6][ARM] new ARM SoC support: BCMRing

On Tue, 30 Jun 2009 20:41:01 +0200
Jean-Christophe PLAGNIOL-VILLARD <plagnioj <at> jcrosoft.com> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Miao | 1 Jul 2009 03:45
Picon
Gravatar

Re: [RFC PATCH 1/3] update defconfig for pxa3xx

Haojian Zhuang wrote:
> Add pxa3xx_defconfig.
> 
> Use one default config file to support all marvell PXA3xx platform.
> zylonite_defconfig & littleton_defconfig isn't necessary any more.
> 
> Signed-off-by: Haojian Zhuang <haojian.zhuang <at> marvell.com>

Haojian,

Sorry - busy on trip last several days. This sounds like a good idea
to me, could you check again and make sure all the previous CONFIG_*
options are included in this single _defconfig, and possibly merge
all the three patches into one, and using 'git format-patch -M' to
generate the patch?

Thanks
- eric

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply | 1 comment |
headers
David Brownell | 1 Jul 2009 04:36

Re: [PATCH 1/2] MMC/pxamci: workaround regulator framework bugs

On Monday 29 June 2009, Mark Brown wrote:
> At the minute the regulator API actually copes pretty well with this -
> the only problem I'm aware of is with drivers like the MMC driver which
> require exclusive control of the regulator.

Which is a fairly typical situation for power-aware drivers.

Which belies your claim that the regulator API "copes pretty well".
It'd be more accurate to say "broken-as-designed", since you have
rejected numerous attempts to fix this, yet not fixed it yourself.

> With other drivers the core 
> API can clean up after startup and the drivers never need to worry about
> fixing things up.

MMC isn't particularly unusual.  It's just the first place this
type problem tends to come up.  Expect more such problelms as
folkl actually try to *use* the regulator framework.
Permalink | Reply | 0 comments |
headers
Shilimkar, Santosh | 1 Jul 2009 07:03
Picon
Favicon

RE: [ARM][OMAP] TWL4030 IRQ

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman <at> deeprootsystems.com] 
> Sent: Wednesday, July 01, 2009 4:36 AM
> To: Shilimkar, Santosh
> Cc: Russell King - ARM Linux; 
> linux-arm-kernel <at> lists.arm.linux.org.uk; linux-omap <at> vger.kernel.org
> Subject: Re: [ARM][OMAP] TWL4030 IRQ
> 
> "Shilimkar, Santosh" <santosh.shilimkar <at> ti.com> writes:
> 
> > Kevin/Vikram,
> > Can this patch be included on omap_pm branch to check for 
> any regression?
> 
> Sure, I have it applied to the PM branch locally, but before I push,
> can you (or Russell) send me a descriptive changelog for this patch.

(Here is the patch with some description.)

From 67d399fd88629f37b8debea1aa51bf20ff8957f6 Mon Sep 17 00:00:00 2001
From: Russell King <rmk+kernel <at> arm.linux.org.uk>
Date: Wed, 1 Jul 2009 10:31:17 +0530
Subject: [PATCH] ARM: OMAP: TWL4030 IRQ

The TWL4030 IRQ handler has a bug which leads to spinlock lock-up. It is
calling the 'unmask' function in a process context. The mask/unmask/ack
functions are only designed to be called from the IRQ handler code,
or the proper API interfaces found in linux/interrupt.h.

Also there is no need to have IRQ chaining mechanism. The right way to
(Continue reading)

Permalink | Reply | 2 comments |
headers
melwyn lobo | 1 Jul 2009 07:42
Picon

Re: Query on L2 Cache

> My point was that I do not fully understand the reason for this
> requirement. I don't say it isn't a valid requirement but maybe you can
> be more explicit.
>

We have observed that while rebooting if we do not flush the l2cache
(executed as a reboot notifier), we are facing issues.
Also another requirement is for power management while entering deep
sleep we need to flush and disable the cache.
Btw I have observed that v6 architectre code contains L1 cache
flushing API at cpu_v6_proc_fin but such logic is not present in
cpu_v7_proc_fin. Why?

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Jul 2009 08:00
Picon

Mailing List Etiquette

This message is sent to this mailing list once a week.

This can also be found (with html links) at:
   http://www.arm.linux.org.uk/mailinglists/etiquette.php

             The list below are specific to the lists.arm.linux.org.uk mailing
             lists. Where they differ with respect to RFC1855, these points
             override those in RFC1855:

              1. [12]Subscription requirements.
              2. [13]Sending a new message to the list.
              3. [14]Replying to a message from the list.
              4. [15]Sending a message to multiple linux-arm* lists.
              5. [16]HTML encoded messages.
              6. [17]Email attachments.
              7. [18]Commercial email.
              8. [19]Searching the archives.
              9. [20]Support for commercial products.
             10. [21]Cross-posting between linux-arm* lists and other lists.
             11. [22]Automatic replies.
             12. [23]Virus scanners and email sanitisers.

             1. Subscription requirements. [[24]rmk]
                Recently, we have had to impose a restriction on the mailing lists.
                You must be subscribed to the mailing list in order to post
                messages to that mailing list. This is because of the UK Data
                Protection laws. Only subscribe to these lists if you accept the
                legal notice displayed on the relevant pages; by subscribing, you
                accept the terms laid out in the legal notice. Answers will be
                copied to you.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane