headers
Grant Likely | 1 Feb 2012 01:02
Picon

Re: [PATCH v3 1/2] irq: add irq_domain support to generic-chip

On Mon, Jan 30, 2012 at 11:31:38AM -0600, Rob Herring wrote:
> From: Rob Herring <rob.herring <at> calxeda.com>
> 
> Add irq domain support to irq generic-chip. This enables users of
> generic-chip to support dynamic irq assignment needed for DT interrupt
> binding.
> 
> Signed-off-by: Rob Herring <rob.herring <at> calxeda.com>
> Cc: Grant Likely <grant.likely <at> secretlab.ca>
> Cc: Thomas Gleixner <tglx <at> linutronix.de>
> ---
>  <at>  <at>  -39,7 +40,7  <at>  <at>  void irq_gc_noop(struct irq_data *d)
>  void irq_gc_mask_disable_reg(struct irq_data *d)
>  {
>  	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> -	u32 mask = 1 << (d->irq - gc->irq_base);
> +	u32 mask = 1 << d->hwirq;

As discussed on IRC, there needs to be a 1:N relationship between
an irq_domain and generic chips, but doing that means that hwirq no
longer directly maps to the bit in the register.

This could be solved however if a mod is applied to the hwirq number
and if we're careful to line up hwirqs to those mod boundaries:

u32 mask = 1 << (d->hwirq % gc->bank_size);

>  	}
>  	gc->irq_cnt = i - gc->irq_base;
>  }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ryan Mallon | 1 Feb 2012 01:04
Picon

Re: [PATCH 1/4] coda: Remove unnecessary OOM messages

On 01/02/12 09:42, Joe Perches wrote:
> Per call site OOM messages are unnecessary.
> k.alloc and v.alloc failures use dump_stack().
>
> Signed-off-by: Joe Perches <joe <at> perches.com>
> ---
>  fs/coda/coda_linux.h |   13 ++++++-------
>  1 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/fs/coda/coda_linux.h b/fs/coda/coda_linux.h
> index cc0ea9f..7b2c3a1 100644
> --- a/fs/coda/coda_linux.h
> +++ b/fs/coda/coda_linux.h
>  <at>  <at>  -57,13 +57,12  <at>  <at>  unsigned short coda_flags_to_cflags(unsigned short);
>  void coda_sysctl_init(void);
>  void coda_sysctl_clean(void);
>  
> -#define CODA_ALLOC(ptr, cast, size) do { \
> -    if (size < PAGE_SIZE) \
> -        ptr = kzalloc((unsigned long) size, GFP_KERNEL); \
> -    else \
> -        ptr = (cast)vzalloc((unsigned long) size); \
> -    if (!ptr) \
> -        printk("kernel malloc returns 0 at %s:%d\n", __FILE__, __LINE__); \
> +#define CODA_ALLOC(ptr, cast, size)			\
> +do {							\
> +	if (size < PAGE_SIZE)				\
> +		ptr = kzalloc(size, GFP_KERNEL);	\
> +	else						\
> +		ptr = vzalloc(size);			\
(Continue reading)

Permalink | Reply | 5 comments |
headers
Grant Likely | 1 Feb 2012 01:07
Picon

Re: [PATCH v3 2/2] gpio: pl061: enable interrupts with DT style binding

On Tue, Jan 31, 2012 at 08:44:19AM -0600, Rob Herring wrote:
> On 01/31/2012 08:36 AM, Shawn Guo wrote:
> > On Mon, Jan 30, 2012 at 11:31:39AM -0600, Rob Herring wrote:
> > ...
> >> -static void __init pl061_init_gc(struct pl061_gpio *chip, int irq_base)
> >> +static void __init pl061_init_gc(struct pl061_gpio *chip,
> >> +				 struct device_node *node, int irq_base)
> >>  {
> >>  	struct irq_chip_type *ct;
> >>  
> >>  <at>  <at>  -212,15 +212,17  <at>  <at>  static void __init pl061_init_gc(struct pl061_gpio *chip, int irq_base)
> >>  	ct->chip.irq_set_wake = irq_gc_set_wake;
> >>  	ct->regs.mask = GPIOIE;
> >>  
> >> -	irq_setup_generic_chip(chip->irq_gc, IRQ_MSK(PL061_GPIO_NR),
> >> -			       IRQ_GC_INIT_NESTED_LOCK, IRQ_NOREQUEST, 0);
> >> +	irq_setup_generic_chip_domain(chip->irq_gc, node,
> >> +				      IRQ_MSK(PL061_GPIO_NR),
> >> +				      IRQ_GC_INIT_NESTED_LOCK,
> >> +				      IRQ_NOREQUEST, 0);
> >>  }
> > 
> > The function irq_setup_generic_chip_domain() is wrapped by
> > #ifdef CONFIG_IRQ_DOMAIN in patch #1.  Is it true that pl061 driver
> > will never work with !IRQ_DOMAIN case?
> 
> You're right unless Grant thinks IRQ_DOMAIN should always be enabled for
> ARM? Otherwise, I'll add something like this for !IRQ_DOMAIN:

I think always having IRQ_DOMAIN on are is where we want to get to; or at least
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Likely | 1 Feb 2012 01:07
Picon

Re: [PATCH v3 00/25] irq_domain generalization and refinement

On Mon, Jan 30, 2012 at 08:53:44PM -0800, Olof Johansson wrote:
> On Fri, Jan 27, 2012 at 02:35:54PM -0700, Grant Likely wrote:
> > Hey everyone,
> > 
> > This patch series is ready for much wider consumption now.  I'd like
> > to get it into linux-next ASAP because there will be ARM board support
> > depending on it.  I'll wait a few days before I ask Stephen to pull
> > this in.
> > 
> > Stephen/Milton/Ben, any testing you can help with here would be
> > appreciated since you've got access to a wider variety of Power
> > machines than I do.
> 
> This series has been:
> 
> Tested-by: Olof Johansson <olof <at> lixom.net>
> 
> On powerpc/pasemi (it's the only one I still have easy access to).

Excellent, thanks Olof!

g.
Permalink | Reply | 0 comments |
headers
Grant Likely | 1 Feb 2012 01:08
Picon

Re: [PATCH v3 14/25] irq_domain: Remove irq_domain_add_simple()

On Tue, Jan 31, 2012 at 09:58:22PM +0800, Shawn Guo wrote:
> On Tue, Jan 31, 2012 at 07:15:26AM -0600, Rob Herring wrote:
> ...
> > >> --- a/arch/arm/mach-mx5/imx51-dt.c
> > >> +++ b/arch/arm/mach-mx5/imx51-dt.c
> > >>  <at>  <at>  -47,7 +47,7  <at>  <at>  static const struct of_dev_auxdata imx51_auxdata_lookup[] __initconst = {
> > >>  static int __init imx51_tzic_add_irq_domain(struct device_node *np,
> > >>  				struct device_node *interrupt_parent)
> > >>  {
> > >> -	irq_domain_add_simple(np, 0);
> > >> +	irq_domain_add_legacy(np, 32, 0, 0, &irq_domain_simple_ops, NULL);
> > >>  	return 0;
> > >>  }
> > >>  
> > >>  <at>  <at>  -57,7 +57,7  <at>  <at>  static int __init imx51_gpio_add_irq_domain(struct device_node *np,
> > >>  	static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS;
> > >>  
> > >>  	gpio_irq_base -= 32;
> > >> -	irq_domain_add_simple(np, gpio_irq_base);
> > >> +	irq_domain_add_legacy(np, 32, gpio_irq_base, 0, &irq_domain_simple_ops, NULL);
> > > 
> > > The tzic on imx5 gets 128 irq lines rather than 32 here.  The current
> > > code will make any hwirq that is > 32 hit the WARN_ON below in
> > > irq_domain_legacy_revmap().
> > 
> > But this is the gpio controller code? Really this should be 4 domains,
> > but this temp fix is probably fine until you use my generic irq chip
> > support.
> > 
> Sorry.  The comment was put at the wrong place.  It should be against
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 1 Feb 2012 01:09
Picon
Picon

Re: [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback

On Mon, 30 Jan 2012, Vinod Koul wrote:

> On Thu, 2012-01-26 at 16:22 -0500, Alexandre Bounine wrote:
> > As we agreed during our discussion about adding DMA Engine support for RapidIO
> > subsystem, RapidIO and similar clients may benefit from adding an extra context
> > parameter to device_prep_slave_sg() callback.
> > See https://lkml.org/lkml/2011/10/24/275 for more details.
> > 
> > Adding the context parameter will allow to pass client/target specific
> > information associated with an individual data transfer request.
> > 
> > In the case of RapidIO support this additional information consists of target
> > destination ID and its buffer address (which is not mapped into the local CPU
> > memory space). Because a single RapidIO-capable DMA channel may queue data
> > transfer requests to different target devices, the per-request configuration
> > is required.
> > 
> > The proposed change eliminates need for new subsystem-specific API.
> > Existing DMA_SLAVE clients will ignore the new parameter.
> > 
> > This RFC only demonstrates the API change and does not include corresponding
> > changes to existing DMA_SLAVE clients. Complete set of patches will be provided
> > after (if) this API change is accepted.
> This looks good to me. But was thinking if we need to add this new
> parameter for other slave calls (circular, interleaved, memcpy...)

Yes, we (shdma.c) also need to pass additional slave configuration 
information to the dmaengine driver and I also was thinking about 
extending the existing API, but my ideas were going more in the direction 
of adding a parameter to __dma_request_channel() along the lines of
(Continue reading)

Permalink | Reply | 6 comments |
headers
David Miller | 1 Feb 2012 01:08
Favicon

Re: [patch v7, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP

From: Štefan Gula <steweg <at> ynet.sk>
Date: Wed, 1 Feb 2012 00:32:04 +0100

> About the new API. Openvswitch is using it's own GRE code, with it's
> own API. So if the finally NVGRE or VXLAN will be added to
> openvswitch,it doesn't breaks anything to leave also my API as is.

You don't understand.

If your code is superfluous in the end, we shouldn't add it in
the first place.

But if I do relent and let your code in now, we have to live
with it, and it's associated maintainence costs, FOREVER.

That's why I'm forcing this to be implemented properly from the start,
so we don't end up with two pieces of code that provide essentially
the same functionality.
Permalink | Reply | 6 comments |
headers
Venkatesh Pallipadi | 1 Feb 2012 01:17
Picon
Favicon

[PATCH] Avoid mask based num_possible_cpus and num_online_cpus -v5

Kernel's notion of possible cpus (from include/linux/cpumask.h)
 *     cpu_possible_mask- has bit 'cpu' set iff cpu is populatable

 *  The cpu_possible_mask is fixed at boot time, as the set of CPU id's
 *  that it is possible might ever be plugged in at anytime during the
 *  life of that system boot.

 #define num_possible_cpus()     cpumask_weight(cpu_possible_mask)

and on x86 cpumask_weight() calls hweight64 and hweight64 (on older kernels
and systems with !X86_FEATURE_POPCNT) or a popcnt based alternative.

i.e, We needlessly go through this mask based calculation everytime
num_possible_cpus() is called.

The problem is there with cpu_online_mask() as well, which is fixed value at
boot time in !CONFIG_HOTPLUG_CPU case and should not change that often even
in HOTPLUG case.

Though most of the callers of these two routines are init time (with few
exceptions of runtime calls), it is cleaner to use variables
and not go through this repeated mask based calculation.

Signed-off-by: Venkatesh Pallipadi <venki <at> google.com>
Acked-by: Srivatsa S. Bhat <srivatsa.bhat <at> linux.vnet.ibm.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>
---
 include/linux/cpumask.h |    9 +++++++--
 kernel/cpu.c            |   13 +++++++++++++
 2 files changed, 20 insertions(+), 2 deletions(-)
(Continue reading)

Permalink | Reply | 24 comments |
headers
Joe Perches | 1 Feb 2012 01:21

Re: [PATCH 1/4] coda: Remove unnecessary OOM messages

> Since CODA_ALLOC no longer uses __FILE__ and __LINE__ and doesn't use
> the cast argument any more, it can be replaced with a static inline
> function. Something like this (untested, applies on top of your patch):

Hi Ryan.

I didn't want to be quite so invasive
but this looks like a nice cleanup to me.

Maybe because alloc/free functions are
used relatively infrequently, maybe it'd
be better to not declare the functions
inline but add them to coda_linux.c

> +static inline void *coda_alloc(size_t size)
> +{
> +	if (size < PAGE_SIZE)
> +		return kzalloc(size, GFP_KERNEL);
> +	return vzalloc(size);
> +}
[]
> +static inline void coda_free(const void *ptr, size_t size)
> +{
> +	if (size < PAGE_SIZE)
> +		kfree(ptr);
> +	else
> +		vfree(ptr);
> +}
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ryan Mallon | 1 Feb 2012 01:23
Picon

Re: [PATCH 1/4] coda: Remove unnecessary OOM messages

On 01/02/12 11:21, Joe Perches wrote:

>> Since CODA_ALLOC no longer uses __FILE__ and __LINE__ and doesn't use
>> the cast argument any more, it can be replaced with a static inline
>> function. Something like this (untested, applies on top of your patch):
> 
> Hi Ryan.
> 
> I didn't want to be quite so invasive
> but this looks like a nice cleanup to me.

Yeah, it needed to be done as a separate patch. Just a good time to do
it now that it no longer needs to be a macro.

> Maybe because alloc/free functions are
> used relatively infrequently, maybe it'd
> be better to not declare the functions
> inline but add them to coda_linux.c

Sure, either approach is fine. Do you want to add the patch to your series?

~Ryan

> 
>> +static inline void *coda_alloc(size_t size)
>> +{
>> +	if (size < PAGE_SIZE)
>> +		return kzalloc(size, GFP_KERNEL);
>> +	return vzalloc(size);
>> +}
(Continue reading)

Permalink | Reply | 3 comments |

Gmane