Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1633398 > unrolled thread

Re: powerpc/8xx: Adding support of IRQ in MPC8xx GPIO

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: powerpc/8xx: Adding support of IRQ in MPC8xx GPIO Scott Wood <oss@buserror.net> - 2017-04-30 08:50 +0200
    Re: powerpc/8xx: Adding support of IRQ in MPC8xx GPIO christophe leroy <christophe.leroy@c-s.fr> - 2017-05-01 09:50 +0200
      Re: powerpc/8xx: Adding support of IRQ in MPC8xx GPIO Scott Wood <oss@buserror.net> - 2017-05-01 20:20 +0200

#1633398 — Re: powerpc/8xx: Adding support of IRQ in MPC8xx GPIO

On Thu, Mar 09, 2017 at 10:42:04AM +0100, Christophe Leroy wrote:
> This patch allows the use of IRQ to notify the change of GPIO status
> on MPC8xx CPM IO ports. This then allows to associate IRQs to GPIOs
> in the Device Tree.
> 
> Ex:
> 	CPM1_PIO_C: gpio-controller@960 {
> 		#gpio-cells = <2>;
> 		compatible = "fsl,cpm1-pario-bank-c";
> 		reg = <0x960 0x10>;
> 		interrupts = <1 2 6 9 10 11 14 15 23 24 26 31>;
> 		interrupts-mask = <0x0fff>;
> 		interrupt-parent = <&CPM_PIC>;
> 		gpio-controller;
> 	};
> 
> The property 'interrupts-mask' defines which of the 16 GPIOs have
> the associated interrupts defined in the 'interrupts' property.

Binding?  Should also be named something like "fsl,cpm1-gpio-irq-mask",

>  static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
>  {
>  	struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> @@ -618,6 +633,7 @@ int cpm1_gpiochip_add16(struct device_node *np)
>  	struct cpm1_gpio16_chip *cpm1_gc;
>  	struct of_mm_gpio_chip *mm_gc;
>  	struct gpio_chip *gc;
> +	u16 mask;
>  
>  	cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
>  	if (!cpm1_gc)

> @@ -625,6 +641,14 @@ int cpm1_gpiochip_add16(struct device_node *np)
>  
>  	spin_lock_init(&cpm1_gc->lock);
>  
> +	if (!of_property_read_u16(np, "interrupts-mask", &mask)) {
> +		int i, j;
> +
> +		for (i = 0, j = 0; i < 16; i++)
> +			if (mask & (1 << (15 - i)))
> +				cpm1_gc->irq[i] = irq_of_parse_and_map(np, j++);
> +	}

Do we really need to use MSB-first bit numbering here?

-Scott

[toc] | [next] | [standalone]

#1633569

Le 30/04/2017 à 08:48, Scott Wood a écrit :
> On Thu, Mar 09, 2017 at 10:42:04AM +0100, Christophe Leroy wrote:
>> This patch allows the use of IRQ to notify the change of GPIO status
>> on MPC8xx CPM IO ports. This then allows to associate IRQs to GPIOs
>> in the Device Tree.
>>
>> Ex:
>> 	CPM1_PIO_C: gpio-controller@960 {
>> 		#gpio-cells = <2>;
>> 		compatible = "fsl,cpm1-pario-bank-c";
>> 		reg = <0x960 0x10>;
>> 		interrupts = <1 2 6 9 10 11 14 15 23 24 26 31>;
>> 		interrupts-mask = <0x0fff>;
>> 		interrupt-parent = <&CPM_PIC>;
>> 		gpio-controller;
>> 	};
>>
>> The property 'interrupts-mask' defines which of the 16 GPIOs have
>> the associated interrupts defined in the 'interrupts' property.
>
> Binding?  Should also be named something like "fsl,cpm1-gpio-irq-mask",

Ok, done in v2

>
>>  static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
>>  {
>>  	struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
>> @@ -618,6 +633,7 @@ int cpm1_gpiochip_add16(struct device_node *np)
>>  	struct cpm1_gpio16_chip *cpm1_gc;
>>  	struct of_mm_gpio_chip *mm_gc;
>>  	struct gpio_chip *gc;
>> +	u16 mask;
>>
>>  	cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
>>  	if (!cpm1_gc)
>
>> @@ -625,6 +641,14 @@ int cpm1_gpiochip_add16(struct device_node *np)
>>
>>  	spin_lock_init(&cpm1_gc->lock);
>>
>> +	if (!of_property_read_u16(np, "interrupts-mask", &mask)) {
>> +		int i, j;
>> +
>> +		for (i = 0, j = 0; i < 16; i++)
>> +			if (mask & (1 << (15 - i)))
>> +				cpm1_gc->irq[i] = irq_of_parse_and_map(np, j++);
>> +	}
>
> Do we really need to use MSB-first bit numbering here?

Well, I think it is better to keep the GPIOs in the same order as in the 
CPM1 registers, like everywhere else in that driver, isn't it ?

The registers have GPIO 0 in the MSB and GPIO15 in the LSB.

Christophe

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

[toc] | [prev] | [next] | [standalone]

#1633782

On Mon, 2017-05-01 at 09:46 +0200, christophe leroy wrote:
> 
> Le 30/04/2017 à 08:48, Scott Wood a écrit :
> > On Thu, Mar 09, 2017 at 10:42:04AM +0100, Christophe Leroy wrote:
> > > 
> > > @@ -625,6 +641,14 @@ int cpm1_gpiochip_add16(struct device_node *np)
> > > 
> > >  	spin_lock_init(&cpm1_gc->lock);
> > > 
> > > +	if (!of_property_read_u16(np, "interrupts-mask", &mask)) {
> > > +		int i, j;
> > > +
> > > +		for (i = 0, j = 0; i < 16; i++)
> > > +			if (mask & (1 << (15 - i)))
> > > +				cpm1_gc->irq[i] =
> > > irq_of_parse_and_map(np, j++);
> > > +	}
> > 
> > Do we really need to use MSB-first bit numbering here?
> 
> Well, I think it is better to keep the GPIOs in the same order as in the 
> CPM1 registers, like everywhere else in that driver, isn't it ?
> 
> The registers have GPIO 0 in the MSB and GPIO15 in the LSB.

OK, if there's a specific register this is reflecting that's reasonable.

-Scott

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web