headers
Grant Likely | 1 Apr 2011 01:05
Picon

Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers

On Wed, Feb 02, 2011 at 08:08:12PM -0800, Andres Salomon wrote:
> 
> No need to explicitly set the cell's platform_data/data_size.
> 
> In this case, move the various platform_data pointers
> to driver_data.  All of the clients which make use of it
> are also changed.
> 
> Signed-off-by: Andres Salomon <dilinger <at> queued.net>
> ---
>  drivers/dma/timb_dma.c           |    2 +-
>  drivers/gpio/timbgpio.c          |    5 +-
>  drivers/i2c/busses/i2c-ocores.c  |    2 +-
>  drivers/i2c/busses/i2c-xiic.c    |    2 +-
>  drivers/media/radio/radio-timb.c |    2 +-
>  drivers/media/video/timblogiw.c  |    2 +-
>  drivers/mfd/timberdale.c         |   81 +++++++++++++-------------------------
>  drivers/net/ks8842.c             |    2 +-
>  drivers/spi/xilinx_spi.c         |    2 +-
>  9 files changed, 36 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
> index 3b88a4e..aa06ca4 100644
> --- a/drivers/dma/timb_dma.c
> +++ b/drivers/dma/timb_dma.c
>  <at>  <at>  -684,7 +684,7  <at>  <at>  static irqreturn_t td_irq(int irq, void *devid)
>  
>  static int __devinit td_probe(struct platform_device *pdev)
>  {
> -	struct timb_dma_platform_data *pdata = pdev->dev.platform_data;
(Continue reading)

Permalink | Reply | 29 comments |
headers
Paul E. McKenney | 1 Apr 2011 01:24
Picon

Re: [RFC PATCH 1/5] Move task's RCU code to rcupdate.h

On Thu, Mar 31, 2011 at 01:31:36PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-03-28 at 10:58 +0800, Lai Jiangshan wrote:
> > +struct task_rcu_struct {
> > +#ifdef CONFIG_PREEMPT_RCU
> > +       int rcu_read_lock_nesting;
> > +       char rcu_read_unlock_special;
> 
> Is there a good reason that's a char? It'll leave a 3 byte hole in this
> location.

No good reason.  Lai just copied the existing char from the task
struct into his task_rcu_struct, so not his fault.  ;-)

							Thanx, Paul

> > +       struct list_head rcu_node_entry;
> > +#ifdef CONFIG_TREE_PREEMPT_RCU
> > +       struct rcu_node *rcu_blocked_node;
> > +#endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
> > +#ifdef CONFIG_RCU_BOOST
> > +       struct rt_mutex *rcu_boost_mutex;
> > +#endif /* #ifdef CONFIG_RCU_BOOST */
> > +#endif /* #ifdef CONFIG_PREEMPT_RCU */
> > +};
Permalink | Reply | 0 comments |
headers
Paul E. McKenney | 1 Apr 2011 01:30
Picon

Re: [RFC PATCH 4/5] RCU: Add TASK_RCU_OFFSET

On Thu, Mar 31, 2011 at 09:53:21AM +0800, Lai Jiangshan wrote:
> On 03/31/2011 09:21 AM, Paul E. McKenney wrote:
> > On Thu, Mar 31, 2011 at 09:02:20AM +0800, Lai Jiangshan wrote:
> >> On 03/30/2011 07:46 PM, Michal Marek wrote:
> >>> On 30.3.2011 12:57, Peter Zijlstra wrote:
> >>>> On Wed, 2011-03-30 at 12:55 +0200, Michal Marek wrote:
> >>>>> Subject: [PATCH] headers: Allow for lightweight inclusion of task_struct definition
> >>>>>
> >>>>> Factor out a couple of type definitions to <header>_types.h to allow
> >>>>> using task_struct without pulling tons of new dependencies via sched.h.
> >>>>
> >>>> Urgh, not pretty.. so why not clean up sched.h properly? There's way too
> >>>> much cruft in there.
> >>>
> >>> It was a proof-of-concept to show that it is doable to have proper
> >>> definition of task_struct in rcupdate.h. Not an entry for any code
> >>> beauty contest.
> >>>
> >>> Michal
> >>>
> >>
> >> I like this cleanup, could you continue for this hard job? I will help you if required.
> >>
> >> Ingo & Peter - will you accept the patches when it is done.
> >>
> >> Acked-by: Lai Jiangshan <laijs <at> cn.fujitsu.com>
> > 
> > I certainly like the idea of being able to inline TREE_PREEMPT_RCU's
> > rcu_read_lock() and rcu_read_unlock() using normal C code!
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Frysinger | 1 Apr 2011 02:09
Picon

Re: [PATCH] media/radio/wl1273: fix build errors

On Sun, Feb 27, 2011 at 12:51, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap <at> oracle.com>
>
> RADIO_WL1273 needs to make sure that the mfd core is built to avoid
> build errors:
>
> ERROR: "mfd_add_devices" [drivers/mfd/wl1273-core.ko] undefined!
> ERROR: "mfd_remove_devices" [drivers/mfd/wl1273-core.ko] undefined!

2.6.38 stable worthy ?

now in mainline as 1b149bbe9156d2eb2afd5a072bd61ad0d4bfaca7 ...
-mike
Permalink | Reply | 1 comment |
headers
Mark Brown | 1 Apr 2011 02:53
Favicon
Gravatar

Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, Mar 31, 2011 at 06:49:11PM -0400, Nicolas Pitre wrote:
> On Thu, 31 Mar 2011, Linus Torvalds wrote:

> > The only way to get quality code is to try to improve the quality from
> > the "leaf nodes", because otherwise you'll always end up playing
> > catch-up. You'll get new bad code faster than you can clean it up.
> 
> Leaf nodes on ARM are people coming from corporate background with the 
> old school software development methodologies.  They do it as a _job_ 
> first and foremost.  They only work on Linux because that's what their 
> boss assigned them to. Don't get me wrong: that doesn't mean they are 
> bad people.  Simply that they are not into it for the public recognition 
> (or flaming) from their peers.  Once their code works they lose interest 
> and move on.  That mindset is extremely hard to change and take time, on 
> a scale of years.  Much more time than required to produce the code 
> needed to support that new SOC out of the pipeline.  There are notable 
> exceptions obviously.  But this is still a scalability problem in 
> itself.  So we need men-in-the-middle attacks.

It's also often the case that the leaf maintainers are themselves
overloaded with work, especially those who don't have much code in tree
already or who have advanced power management features in their devices
that they're trying to support (which tend to be the area that requires
most work as they're system wide in impact).  

> > This really isn't the argument. The argument should be that if they
> > want their code up-stream, they need to do a good job. If they don't,
> > why should you take it at all?

> Embedded vendors did keep their code out of the kernel before.  We've
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Gardner | 1 Apr 2011 03:30
Favicon

Re: [PATCH V2] Raise default hard ulimit on number of files to 4096

On 03/31/2011 03:35 PM, Andrew Morton wrote:
>
> ^^ how not to write a changelog.
>

It seemed like plagiarism to just copy Dan's argument, but now here you 
have it.

rtg
--

-- 
Tim Gardner tim.gardner <at> canonical.com
Attachment (0001-Raise-default-hard-ulimit-on-number-of-files-to-4096.patch): text/x-patch, 2316 bytes
Permalink | Reply | 1 comment |
headers
Kelly Anderson | 1 Apr 2011 03:33

Re: Linux 2.6.38 freeze because of sound/core/pcm_lib.c commit 59ff878ffb26bc0be812ca8295799164f413ae88

On 03/31/11 15:50, Kelly Anderson wrote:
>
> Just to let you know.  I'm using a gtx460 also.  I haven't had a 
> chance to reboot into the newly patched kernel yet.  It is interesting 
> that we both have gtx460's.  I have a machine with a gtx430 that 
> doesn't seem to exhibit the problem.
>
> cat /etc/modprobe.d/snd_hda_intel.conf
>
> options snd-hda-intel probe_mask=-1,0xa
>
OK, I debugged the problem and came up with a solution.  The bottom line 
is that it's a problem with a signed to unsigned compare.  First the fix:

--- ./sound/core/pcm_lib.c.orig    2011-03-27 12:37:20.000000000 -0600
+++ ./sound/core/pcm_lib.c    2011-03-31 19:01:35.392739127 -0600
 <at>  <at>  -379,17 +379,17  <at>  <at>  static int snd_pcm_update_hw_ptr0(struct
           * Without regular period interrupts, we have to check
           * the elapsed time to detect xruns.
           */
-        jdelta = jiffies - runtime->hw_ptr_jiffies;
-        if (jdelta < runtime->hw_ptr_buffer_jiffies / 2)
+        jdelta = (snd_pcm_sframes_t)(jiffies - runtime->hw_ptr_jiffies);
+        if (jdelta < (snd_pcm_sframes_t)runtime->hw_ptr_buffer_jiffies / 2)
              goto no_delta_check;
          hdelta = jdelta - delta * HZ / runtime->rate;
-        while (hdelta > runtime->hw_ptr_buffer_jiffies / 2 + 1) {
+        while (hdelta > 
(snd_pcm_sframes_t)runtime->hw_ptr_buffer_jiffies / 2 + 1) {
              delta += runtime->buffer_size;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Brown | 1 Apr 2011 03:42
Favicon
Gravatar

Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, Mar 31, 2011 at 12:56:33AM +0200, Thomas Gleixner wrote:
> On Wed, 30 Mar 2011, Tony Lindgren wrote:
> > * Thomas Gleixner <tglx <at> linutronix.de> [110330 15:22]:
> > > On Wed, 30 Mar 2011, Tony Lindgren wrote:

> > > > One thing that will help here and distribute the load is to move
> > > > more things under drivers/ as then we have more maintainers looking
> > > > at the code.

> > > Guess what's that going to solve? Nothing, nada.

> > > Really, you move the problem to people who are not prepared to deal
> > > with the wave either. So what's the gain?

> > I guess my point is that with creating more common frameworks people
> > will be using common code. Some examples that come to mind are clock
> > framework, gpiolib, dma engine, runtime PM and so on.

> For all that to happen you need a really experienced team with a
> strong team lead to fight that through and go through the existing
> horror while dealing  with the incoming flood at the same time.

My experience is that it's not that bad doing this providing you can
convince people to actually show their code to the relevant subsystem
maintainers and they have time to look at the code.  The first step is
reasonably tractable since it's a fairly basic level of review and as a
subsystem maintainer you're well enough motivated to at least ensure
that people aren't breaking the abstractions enough to cause problems
for anyone but the people directly working with the drivers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Glass | 1 Apr 2011 03:47

Re: [PATCH] ARM: BUG() dies silently

You might try the generic bug patch and see if it also fixes this
problem - Simon

On Thu, Mar 31, 2011 at 1:15 PM, Omar Ramirez Luna <omar.ramirez <at> ti.com> wrote:
> There are some cases where the code generated for BUG() results
> into an infinite while loop without causing a null dereference,
> this ends on a kernel being stuck on a loop and the user without
> a clue of what happened.
>
> E.g.: lib/scatterlist.c : __sg_alloc_table
>
>        BUG_ON(nents > max_ents);
>  438:   9a000000        bls     440 <__sg_alloc_table+0x20>
>  43c:   eafffffe        b       43c <__sg_alloc_table+0x1c>
>
> Adding volatile makes the compiler to avoid optimizations on this
> code, which makes the panic to occur:
>
>        BUG_ON(nents > max_ents);
>  438:   9a000002        bls     448 <__sg_alloc_table+0x28>
>  43c:   e3a03000        mov     r3, #0
>  440:   e5833000        str     r3, [r3]
>  444:   eafffffc        b       43c <__sg_alloc_table+0x1c>
>
> Seen with gnu/linux cs arm-2010q1-202 and arm2010.09-50.
>
> Signed-off-by: Omar Ramirez Luna <omar.ramirez <at> ti.com>
> ---
>
> If needed I can change:
(Continue reading)

Permalink | Reply | 9 comments |
headers
Lai Jiangshan | 1 Apr 2011 03:57
Favicon

Re: [RFC PATCH 4/5] RCU: Add TASK_RCU_OFFSET

On 03/31/2011 07:18 PM, Peter Zijlstra wrote:
> On Thu, 2011-03-31 at 17:50 +0800, Lai Jiangshan wrote:
>> On 03/31/2011 04:04 PM, Peter Zijlstra wrote:
>>> On Thu, 2011-03-31 at 09:02 +0800, Lai Jiangshan wrote:
>>>> I like this cleanup, could you continue for this hard job? I will help
>>>> you if required.
>>>>
>>>> Ingo & Peter - will you accept the patches when it is done.
>>>>
>>> No, like I said, I think the proposed patch is utterly horrid.
>>>
>>
>> But how about my kernel-offset.c patch? It is clean & simple,
>> it just seems not so normal.
>>
>> If the proposed splitting patch is horrid, I think we will try to
>> update it as you expect.
>>
>> If splitting sched.h is wrong, I will try to persuade more people
>> accept the kernel-offset.c patch.
> 
> Well, I'm all for cleaning up sched.h, it includes way too much things
> not strongly related to kernel/sched*.c like a lot of the signal things
> and the misnamed signal_struct (should be called process_struct or
> somesuch).
> 
> That also causes the inversion between sched.h and wait.h
> 
> What I don't like is those _types.h headers, and definitely not the
> massive explosion of those as per the proposed patch.
(Continue reading)

Permalink | Reply | 31 comments |

Gmane