Re: Delivery Status Notification (Failure)

2018-05-21 Thread Pintu Kumar
Dear Lucas,

Can you give me some pointers on how to set affinity for entire GPIO Bank.
Currently I am exploring drivers/gpio/gpio-mxc.c to find out how the
GPIO banks are set up.

I also found that affinity can be set using: desc->irq_data.affinity,
may be by using cpumask_copy(...).
But still I am not familiar with this.

So, I need your help.


Thank You!

Regards,
Pintu



On Thu, May 17, 2018 at 6:58 PM, Pintu Kumar  wrote:
> On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar  wrote:
>>
>> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
>> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> >> Hi,
>> >>
>> >> Is there any work around possible to set IRQ affinity for some GPIO
>> >> interrupt ?
>> >> How to avoid CPU0 to receive the current GPIO interrupt ?
>> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> >> that GPIO interrupt can be served by another CPU ?
>> >>
>> >> Need your inputs to decide whether it is still possible to set
>> >> affinity for GPIO interrupt, or its impossible ?
>> >
>> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
>> > line per GPIO bank, so it is not possible to change affinity of a
>> > single GPIO interrupt to another CPU.
>>
>> OK. Thanks for your confirmation.
>>
>> > Best we could do is change the
>> > affinity of the whole bank,
>>
>
> Hi,
>
> I found that the driver is responsible for setting GPIO bank in i.MX7:
> https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c
>
> However I still dont know how to set the cpumask for one of the GPIO Bank.
>
> From this link, it seems it is possible to set affinity for a GPIO IRQ.
> https://community.nxp.com/thread/303144
>
> But when I try it form my GPIO138 (GPIO5_IO10) it did not help.
>
> So, as you said, I wanted to change affinity for the whole GPIO bank and try 
> it.
> Please give me some pointers.
>
> Thanks
>
>
>> OK. How can we do this on the fly from my driver code.
>> If you have any reference please let me know.
>> This is required only for experimental purpose to prove the point to be mgmt.
>> My idea is, from the driver, change the affinity of the whole bank.
>> So, the GPIO interrupt can be delivered on to this specific CPU bank.
>> Once I am done, I will revert back to the old bank.
>> Please give me some hint on how to do this from my kernel module
>>
>>
>> > but given the limited usefulness of
>> > something like that, nobody bothered to implement such a thing.
>> >
>> > Regards,
>> > Lucas
>> >
>> >>
>> >>
>> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
>> >> wrote:
>> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach > >> > e> wrote:
>> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> >> > > ARM Linux:
>> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> >> > > > > Hi,
>> >> > > > >
>> >> > > > > I need one help.
>> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >> > > > >
>> >> > > > > Let's say I am interested in GPIO number: 21
>> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> >> > > > > so I
>> >> > > > > tried the below steps:
>> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> >> > > > > root@10:~# cat /proc/interrupts | grep 21
>> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> >> > > > > in
>> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> >> > > > > 3
>> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> >> > > > > -bash: echo: write error: Input/output error
>> >> > > > >
>> >> > > > > But I get input/output error.
>> >> > > > > When I debug further, found that irq_can_set_affinity is
>> >> > > > > returning 0:
>> >> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> >> > > > > [0.00] write_irq_affinity: FAIL
>> >> > > > >
>> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
>> >> > > > > 2 (from 3).
>> >> > > > > This change is working, but the smp_affinity setting for the
>> >> > > > > new IRQ
>> >> > > > > is not working.
>> >> > > > >
>> >> > > > > When I try to set smp_affinity for mmc0, then it works.
>> >> > > > > # cat /proc/interrupts | grep mmc
>> >> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
>> >> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
>> >> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
>> >> > > > >
>> >> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> >> > > > > root@10:~#
>> >> > > > >
>> >> > > > >
>> >> > > > > So, I wanted to know what are the conditions for which
>> >> > > 

Re: Delivery Status Notification (Failure)

2018-05-21 Thread Pintu Kumar
Dear Lucas,

Can you give me some pointers on how to set affinity for entire GPIO Bank.
Currently I am exploring drivers/gpio/gpio-mxc.c to find out how the
GPIO banks are set up.

I also found that affinity can be set using: desc->irq_data.affinity,
may be by using cpumask_copy(...).
But still I am not familiar with this.

So, I need your help.


Thank You!

Regards,
Pintu



On Thu, May 17, 2018 at 6:58 PM, Pintu Kumar  wrote:
> On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar  wrote:
>>
>> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
>> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> >> Hi,
>> >>
>> >> Is there any work around possible to set IRQ affinity for some GPIO
>> >> interrupt ?
>> >> How to avoid CPU0 to receive the current GPIO interrupt ?
>> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> >> that GPIO interrupt can be served by another CPU ?
>> >>
>> >> Need your inputs to decide whether it is still possible to set
>> >> affinity for GPIO interrupt, or its impossible ?
>> >
>> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
>> > line per GPIO bank, so it is not possible to change affinity of a
>> > single GPIO interrupt to another CPU.
>>
>> OK. Thanks for your confirmation.
>>
>> > Best we could do is change the
>> > affinity of the whole bank,
>>
>
> Hi,
>
> I found that the driver is responsible for setting GPIO bank in i.MX7:
> https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c
>
> However I still dont know how to set the cpumask for one of the GPIO Bank.
>
> From this link, it seems it is possible to set affinity for a GPIO IRQ.
> https://community.nxp.com/thread/303144
>
> But when I try it form my GPIO138 (GPIO5_IO10) it did not help.
>
> So, as you said, I wanted to change affinity for the whole GPIO bank and try 
> it.
> Please give me some pointers.
>
> Thanks
>
>
>> OK. How can we do this on the fly from my driver code.
>> If you have any reference please let me know.
>> This is required only for experimental purpose to prove the point to be mgmt.
>> My idea is, from the driver, change the affinity of the whole bank.
>> So, the GPIO interrupt can be delivered on to this specific CPU bank.
>> Once I am done, I will revert back to the old bank.
>> Please give me some hint on how to do this from my kernel module
>>
>>
>> > but given the limited usefulness of
>> > something like that, nobody bothered to implement such a thing.
>> >
>> > Regards,
>> > Lucas
>> >
>> >>
>> >>
>> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
>> >> wrote:
>> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach > >> > e> wrote:
>> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> >> > > ARM Linux:
>> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> >> > > > > Hi,
>> >> > > > >
>> >> > > > > I need one help.
>> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >> > > > >
>> >> > > > > Let's say I am interested in GPIO number: 21
>> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> >> > > > > so I
>> >> > > > > tried the below steps:
>> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> >> > > > > root@10:~# cat /proc/interrupts | grep 21
>> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> >> > > > > in
>> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> >> > > > > 3
>> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> >> > > > > -bash: echo: write error: Input/output error
>> >> > > > >
>> >> > > > > But I get input/output error.
>> >> > > > > When I debug further, found that irq_can_set_affinity is
>> >> > > > > returning 0:
>> >> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> >> > > > > [0.00] write_irq_affinity: FAIL
>> >> > > > >
>> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
>> >> > > > > 2 (from 3).
>> >> > > > > This change is working, but the smp_affinity setting for the
>> >> > > > > new IRQ
>> >> > > > > is not working.
>> >> > > > >
>> >> > > > > When I try to set smp_affinity for mmc0, then it works.
>> >> > > > > # cat /proc/interrupts | grep mmc
>> >> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
>> >> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
>> >> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
>> >> > > > >
>> >> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> >> > > > > root@10:~#
>> >> > > > >
>> >> > > > >
>> >> > > > > So, I wanted to know what are the conditions for which
>> >> > > > > setting
>> >> > > > > smp_affinity for an IRQ will work ?
>> >> > > > >
>> >> > > > > Is there any way by 

Re: Delivery Status Notification (Failure)

2018-05-17 Thread Pintu Kumar
On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar  wrote:
>
> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> >> Hi,
> >>
> >> Is there any work around possible to set IRQ affinity for some GPIO
> >> interrupt ?
> >> How to avoid CPU0 to receive the current GPIO interrupt ?
> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> >> that GPIO interrupt can be served by another CPU ?
> >>
> >> Need your inputs to decide whether it is still possible to set
> >> affinity for GPIO interrupt, or its impossible ?
> >
> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> > line per GPIO bank, so it is not possible to change affinity of a
> > single GPIO interrupt to another CPU.
>
> OK. Thanks for your confirmation.
>
> > Best we could do is change the
> > affinity of the whole bank,
>

Hi,

I found that the driver is responsible for setting GPIO bank in i.MX7:
https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c

However I still dont know how to set the cpumask for one of the GPIO Bank.

>From this link, it seems it is possible to set affinity for a GPIO IRQ.
https://community.nxp.com/thread/303144

But when I try it form my GPIO138 (GPIO5_IO10) it did not help.

So, as you said, I wanted to change affinity for the whole GPIO bank and try it.
Please give me some pointers.

Thanks


> OK. How can we do this on the fly from my driver code.
> If you have any reference please let me know.
> This is required only for experimental purpose to prove the point to be mgmt.
> My idea is, from the driver, change the affinity of the whole bank.
> So, the GPIO interrupt can be delivered on to this specific CPU bank.
> Once I am done, I will revert back to the old bank.
> Please give me some hint on how to do this from my kernel module
>
>
> > but given the limited usefulness of
> > something like that, nobody bothered to implement such a thing.
> >
> > Regards,
> > Lucas
> >
> >>
> >>
> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
> >> wrote:
> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  >> > e> wrote:
> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> >> > > ARM Linux:
> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > I need one help.
> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> >> > > > >
> >> > > > > Let's say I am interested in GPIO number: 21
> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> >> > > > > so I
> >> > > > > tried the below steps:
> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> >> > > > > root@10:~# cat /proc/interrupts | grep 21
> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
> >> > > > > in
> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
> >> > > > > 3
> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> >> > > > > -bash: echo: write error: Input/output error
> >> > > > >
> >> > > > > But I get input/output error.
> >> > > > > When I debug further, found that irq_can_set_affinity is
> >> > > > > returning 0:
> >> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> >> > > > > [0.00] write_irq_affinity: FAIL
> >> > > > >
> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> >> > > > > 2 (from 3).
> >> > > > > This change is working, but the smp_affinity setting for the
> >> > > > > new IRQ
> >> > > > > is not working.
> >> > > > >
> >> > > > > When I try to set smp_affinity for mmc0, then it works.
> >> > > > > # cat /proc/interrupts | grep mmc
> >> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
> >> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
> >> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
> >> > > > >
> >> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
> >> > > > > root@10:~#
> >> > > > >
> >> > > > >
> >> > > > > So, I wanted to know what are the conditions for which
> >> > > > > setting
> >> > > > > smp_affinity for an IRQ will work ?
> >> > > > >
> >> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> >> > > > > IRQ ?
> >> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> >> > > >
> >> > > > IRQ affinity is only supported where interrupts are _directly_
> >> > > > wired to
> >> > > > the GIC.  It's the GIC which does the interrupt steering to the
> >> > > > CPU
> >> > > > cores.
> >> > > >
> >> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> >> > > > have no
> >> > > > ability to be 

Re: Delivery Status Notification (Failure)

2018-05-17 Thread Pintu Kumar
On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar  wrote:
>
> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> >> Hi,
> >>
> >> Is there any work around possible to set IRQ affinity for some GPIO
> >> interrupt ?
> >> How to avoid CPU0 to receive the current GPIO interrupt ?
> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> >> that GPIO interrupt can be served by another CPU ?
> >>
> >> Need your inputs to decide whether it is still possible to set
> >> affinity for GPIO interrupt, or its impossible ?
> >
> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> > line per GPIO bank, so it is not possible to change affinity of a
> > single GPIO interrupt to another CPU.
>
> OK. Thanks for your confirmation.
>
> > Best we could do is change the
> > affinity of the whole bank,
>

Hi,

I found that the driver is responsible for setting GPIO bank in i.MX7:
https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c

However I still dont know how to set the cpumask for one of the GPIO Bank.

>From this link, it seems it is possible to set affinity for a GPIO IRQ.
https://community.nxp.com/thread/303144

But when I try it form my GPIO138 (GPIO5_IO10) it did not help.

So, as you said, I wanted to change affinity for the whole GPIO bank and try it.
Please give me some pointers.

Thanks


> OK. How can we do this on the fly from my driver code.
> If you have any reference please let me know.
> This is required only for experimental purpose to prove the point to be mgmt.
> My idea is, from the driver, change the affinity of the whole bank.
> So, the GPIO interrupt can be delivered on to this specific CPU bank.
> Once I am done, I will revert back to the old bank.
> Please give me some hint on how to do this from my kernel module
>
>
> > but given the limited usefulness of
> > something like that, nobody bothered to implement such a thing.
> >
> > Regards,
> > Lucas
> >
> >>
> >>
> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
> >> wrote:
> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  >> > e> wrote:
> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> >> > > ARM Linux:
> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > I need one help.
> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> >> > > > >
> >> > > > > Let's say I am interested in GPIO number: 21
> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> >> > > > > so I
> >> > > > > tried the below steps:
> >> > > > > root@10:~# echo 21 > /sys/class/gpio/export
> >> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> >> > > > > root@10:~# cat /proc/interrupts | grep 21
> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> >> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
> >> > > > > in
> >> > > > > root@10:~# cat /proc/irq/47/smp_affinity
> >> > > > > 3
> >> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> >> > > > > -bash: echo: write error: Input/output error
> >> > > > >
> >> > > > > But I get input/output error.
> >> > > > > When I debug further, found that irq_can_set_affinity is
> >> > > > > returning 0:
> >> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> >> > > > > [0.00] write_irq_affinity: FAIL
> >> > > > >
> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> >> > > > > 2 (from 3).
> >> > > > > This change is working, but the smp_affinity setting for the
> >> > > > > new IRQ
> >> > > > > is not working.
> >> > > > >
> >> > > > > When I try to set smp_affinity for mmc0, then it works.
> >> > > > > # cat /proc/interrupts | grep mmc
> >> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
> >> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
> >> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
> >> > > > >
> >> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
> >> > > > > root@10:~#
> >> > > > >
> >> > > > >
> >> > > > > So, I wanted to know what are the conditions for which
> >> > > > > setting
> >> > > > > smp_affinity for an IRQ will work ?
> >> > > > >
> >> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> >> > > > > IRQ ?
> >> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> >> > > >
> >> > > > IRQ affinity is only supported where interrupts are _directly_
> >> > > > wired to
> >> > > > the GIC.  It's the GIC which does the interrupt steering to the
> >> > > > CPU
> >> > > > cores.
> >> > > >
> >> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> >> > > > have no
> >> > > > ability to be directed independently to other CPUs - the only
> >> > > > possible
> >> > > > way to 

Re: Delivery Status Notification (Failure)

2018-05-14 Thread Pintu Kumar
On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
> Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> Hi,
>>
>> Is there any work around possible to set IRQ affinity for some GPIO
>> interrupt ?
>> How to avoid CPU0 to receive the current GPIO interrupt ?
>> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> that GPIO interrupt can be served by another CPU ?
>>
>> Need your inputs to decide whether it is still possible to set
>> affinity for GPIO interrupt, or its impossible ?
>
> This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> line per GPIO bank, so it is not possible to change affinity of a
> single GPIO interrupt to another CPU.

OK. Thanks for your confirmation.

> Best we could do is change the
> affinity of the whole bank,

OK. How can we do this on the fly from my driver code.
If you have any reference please let me know.
This is required only for experimental purpose to prove the point to be mgmt.
My idea is, from the driver, change the affinity of the whole bank.
So, the GPIO interrupt can be delivered on to this specific CPU bank.
Once I am done, I will revert back to the old bank.
Please give me some hint on how to do this from my kernel module


> but given the limited usefulness of
> something like that, nobody bothered to implement such a thing.
>
> Regards,
> Lucas
>
>>
>>
>> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
>> wrote:
>> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach > > e> wrote:
>> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> > > ARM Linux:
>> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I need one help.
>> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> > > > >
>> > > > > Let's say I am interested in GPIO number: 21
>> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> > > > > so I
>> > > > > tried the below steps:
>> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > > > > root@10:~# cat /proc/interrupts | grep 21
>> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > > > > in
>> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> > > > > 3
>> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > > > > -bash: echo: write error: Input/output error
>> > > > >
>> > > > > But I get input/output error.
>> > > > > When I debug further, found that irq_can_set_affinity is
>> > > > > returning 0:
>> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > > > > [0.00] write_irq_affinity: FAIL
>> > > > >
>> > > > > I also tried first setting /proc/irq/default_smp_affinity to
>> > > > > 2 (from 3).
>> > > > > This change is working, but the smp_affinity setting for the
>> > > > > new IRQ
>> > > > > is not working.
>> > > > >
>> > > > > When I try to set smp_affinity for mmc0, then it works.
>> > > > > # cat /proc/interrupts | grep mmc
>> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
>> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
>> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
>> > > > >
>> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > > > > root@10:~#
>> > > > >
>> > > > >
>> > > > > So, I wanted to know what are the conditions for which
>> > > > > setting
>> > > > > smp_affinity for an IRQ will work ?
>> > > > >
>> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
>> > > > > IRQ ?
>> > > > > Whether, irq_set_affinity_hint() will work in this case ?
>> > > >
>> > > > IRQ affinity is only supported where interrupts are _directly_
>> > > > wired to
>> > > > the GIC.  It's the GIC which does the interrupt steering to the
>> > > > CPU
>> > > > cores.
>> > > >
>> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
>> > > > have no
>> > > > ability to be directed independently to other CPUs - the only
>> > > > possible
>> > > > way to change the mapping is to move _all_ interrupts on that
>> > > > controller,
>> > > > and any downstream chained interrupts at GIC level.
>> > > >
>> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
>> > > > is no way
>> > > > for the interrupt controller itself to change the affinity of
>> > > > the input
>> > > > interrupt.
>> > >
>> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
>> > > mapping
>> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
>> > > thus be
>> > > handled by forwarding the request to the GIC by
>> > > irq_chip_set_affinity_parent().
>> > >
>> > > As this is handled correctly in the upstream kernel since the
>> > > first
>> > > commit 

Re: Delivery Status Notification (Failure)

2018-05-14 Thread Pintu Kumar
On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
> Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> Hi,
>>
>> Is there any work around possible to set IRQ affinity for some GPIO
>> interrupt ?
>> How to avoid CPU0 to receive the current GPIO interrupt ?
>> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> that GPIO interrupt can be served by another CPU ?
>>
>> Need your inputs to decide whether it is still possible to set
>> affinity for GPIO interrupt, or its impossible ?
>
> This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> line per GPIO bank, so it is not possible to change affinity of a
> single GPIO interrupt to another CPU.

OK. Thanks for your confirmation.

> Best we could do is change the
> affinity of the whole bank,

OK. How can we do this on the fly from my driver code.
If you have any reference please let me know.
This is required only for experimental purpose to prove the point to be mgmt.
My idea is, from the driver, change the affinity of the whole bank.
So, the GPIO interrupt can be delivered on to this specific CPU bank.
Once I am done, I will revert back to the old bank.
Please give me some hint on how to do this from my kernel module


> but given the limited usefulness of
> something like that, nobody bothered to implement such a thing.
>
> Regards,
> Lucas
>
>>
>>
>> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
>> wrote:
>> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach > > e> wrote:
>> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> > > ARM Linux:
>> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I need one help.
>> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> > > > >
>> > > > > Let's say I am interested in GPIO number: 21
>> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> > > > > so I
>> > > > > tried the below steps:
>> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > > > > root@10:~# cat /proc/interrupts | grep 21
>> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > > > > in
>> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> > > > > 3
>> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > > > > -bash: echo: write error: Input/output error
>> > > > >
>> > > > > But I get input/output error.
>> > > > > When I debug further, found that irq_can_set_affinity is
>> > > > > returning 0:
>> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > > > > [0.00] write_irq_affinity: FAIL
>> > > > >
>> > > > > I also tried first setting /proc/irq/default_smp_affinity to
>> > > > > 2 (from 3).
>> > > > > This change is working, but the smp_affinity setting for the
>> > > > > new IRQ
>> > > > > is not working.
>> > > > >
>> > > > > When I try to set smp_affinity for mmc0, then it works.
>> > > > > # cat /proc/interrupts | grep mmc
>> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
>> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
>> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
>> > > > >
>> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > > > > root@10:~#
>> > > > >
>> > > > >
>> > > > > So, I wanted to know what are the conditions for which
>> > > > > setting
>> > > > > smp_affinity for an IRQ will work ?
>> > > > >
>> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
>> > > > > IRQ ?
>> > > > > Whether, irq_set_affinity_hint() will work in this case ?
>> > > >
>> > > > IRQ affinity is only supported where interrupts are _directly_
>> > > > wired to
>> > > > the GIC.  It's the GIC which does the interrupt steering to the
>> > > > CPU
>> > > > cores.
>> > > >
>> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
>> > > > have no
>> > > > ability to be directed independently to other CPUs - the only
>> > > > possible
>> > > > way to change the mapping is to move _all_ interrupts on that
>> > > > controller,
>> > > > and any downstream chained interrupts at GIC level.
>> > > >
>> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
>> > > > is no way
>> > > > for the interrupt controller itself to change the affinity of
>> > > > the input
>> > > > interrupt.
>> > >
>> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
>> > > mapping
>> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
>> > > thus be
>> > > handled by forwarding the request to the GIC by
>> > > irq_chip_set_affinity_parent().
>> > >
>> > > As this is handled correctly in the upstream kernel since the
>> > > first
>> > > commit introducing support for the GPCv2, it seems the issue is
>> > > only
>> > > 

Re: Delivery Status Notification (Failure)

2018-05-14 Thread Lucas Stach
Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> Hi,
> 
> Is there any work around possible to set IRQ affinity for some GPIO
> interrupt ?
> How to avoid CPU0 to receive the current GPIO interrupt ?
> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> that GPIO interrupt can be served by another CPU ?
> 
> Need your inputs to decide whether it is still possible to set
> affinity for GPIO interrupt, or its impossible ?

This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
line per GPIO bank, so it is not possible to change affinity of a
single GPIO interrupt to another CPU. Best we could do is change the
affinity of the whole bank, but given the limited usefulness of
something like that, nobody bothered to implement such a thing.

Regards,
Lucas

> 
> 
> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
> wrote:
> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  > e> wrote:
> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> > > ARM Linux:
> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> > > > > Hi,
> > > > > 
> > > > > I need one help.
> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> > > > > 
> > > > > Let's say I am interested in GPIO number: 21
> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> > > > > so I
> > > > > tried the below steps:
> > > > > root@10:~# echo 21 > /sys/class/gpio/export
> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > > > > root@10:~# cat /proc/interrupts | grep 21
> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
> > > > > in
> > > > > root@10:~# cat /proc/irq/47/smp_affinity
> > > > > 3
> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> > > > > -bash: echo: write error: Input/output error
> > > > > 
> > > > > But I get input/output error.
> > > > > When I debug further, found that irq_can_set_affinity is
> > > > > returning 0:
> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> > > > > [0.00] write_irq_affinity: FAIL
> > > > > 
> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> > > > > 2 (from 3).
> > > > > This change is working, but the smp_affinity setting for the
> > > > > new IRQ
> > > > > is not working.
> > > > > 
> > > > > When I try to set smp_affinity for mmc0, then it works.
> > > > > # cat /proc/interrupts | grep mmc
> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
> > > > > 
> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
> > > > > root@10:~#
> > > > > 
> > > > > 
> > > > > So, I wanted to know what are the conditions for which
> > > > > setting
> > > > > smp_affinity for an IRQ will work ?
> > > > > 
> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> > > > > IRQ ?
> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> > > > 
> > > > IRQ affinity is only supported where interrupts are _directly_
> > > > wired to
> > > > the GIC.  It's the GIC which does the interrupt steering to the
> > > > CPU
> > > > cores.
> > > > 
> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> > > > have no
> > > > ability to be directed independently to other CPUs - the only
> > > > possible
> > > > way to change the mapping is to move _all_ interrupts on that
> > > > controller,
> > > > and any downstream chained interrupts at GIC level.
> > > > 
> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
> > > > is no way
> > > > for the interrupt controller itself to change the affinity of
> > > > the input
> > > > interrupt.
> > > 
> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
> > > mapping
> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
> > > thus be
> > > handled by forwarding the request to the GIC by
> > > irq_chip_set_affinity_parent().
> > > 
> > > As this is handled correctly in the upstream kernel since the
> > > first
> > > commit introducing support for the GPCv2, it seems the issue is
> > > only
> > > present in some downstream kernel.
> > > 
> > 
> > OK. Thanks so much for your reply.
> > 
> > I saw some of the drivers using irq_set_affinity_hint() to force
> > the
> > IRQ affinity to a particular CPU.
> > This is the sample:
> > {
> > cpumask_clear(mask);
> > cpumask_set_cpu(cpu, mask);
> > irq_set_affinity_hint(irq, mask);
> > }
> > 
> > Whether this logic will work for a particular GPIO pin ?
> > 
> > 
> > > Regards,
> > > Lucas


Re: Delivery Status Notification (Failure)

2018-05-14 Thread Lucas Stach
Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> Hi,
> 
> Is there any work around possible to set IRQ affinity for some GPIO
> interrupt ?
> How to avoid CPU0 to receive the current GPIO interrupt ?
> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> that GPIO interrupt can be served by another CPU ?
> 
> Need your inputs to decide whether it is still possible to set
> affinity for GPIO interrupt, or its impossible ?

This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
line per GPIO bank, so it is not possible to change affinity of a
single GPIO interrupt to another CPU. Best we could do is change the
affinity of the whole bank, but given the limited usefulness of
something like that, nobody bothered to implement such a thing.

Regards,
Lucas

> 
> 
> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
> wrote:
> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  > e> wrote:
> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> > > ARM Linux:
> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> > > > > Hi,
> > > > > 
> > > > > I need one help.
> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> > > > > 
> > > > > Let's say I am interested in GPIO number: 21
> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> > > > > so I
> > > > > tried the below steps:
> > > > > root@10:~# echo 21 > /sys/class/gpio/export
> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > > > > root@10:~# cat /proc/interrupts | grep 21
> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
> > > > > in
> > > > > root@10:~# cat /proc/irq/47/smp_affinity
> > > > > 3
> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> > > > > -bash: echo: write error: Input/output error
> > > > > 
> > > > > But I get input/output error.
> > > > > When I debug further, found that irq_can_set_affinity is
> > > > > returning 0:
> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> > > > > [0.00] write_irq_affinity: FAIL
> > > > > 
> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> > > > > 2 (from 3).
> > > > > This change is working, but the smp_affinity setting for the
> > > > > new IRQ
> > > > > is not working.
> > > > > 
> > > > > When I try to set smp_affinity for mmc0, then it works.
> > > > > # cat /proc/interrupts | grep mmc
> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
> > > > > 
> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
> > > > > root@10:~#
> > > > > 
> > > > > 
> > > > > So, I wanted to know what are the conditions for which
> > > > > setting
> > > > > smp_affinity for an IRQ will work ?
> > > > > 
> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> > > > > IRQ ?
> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> > > > 
> > > > IRQ affinity is only supported where interrupts are _directly_
> > > > wired to
> > > > the GIC.  It's the GIC which does the interrupt steering to the
> > > > CPU
> > > > cores.
> > > > 
> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> > > > have no
> > > > ability to be directed independently to other CPUs - the only
> > > > possible
> > > > way to change the mapping is to move _all_ interrupts on that
> > > > controller,
> > > > and any downstream chained interrupts at GIC level.
> > > > 
> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
> > > > is no way
> > > > for the interrupt controller itself to change the affinity of
> > > > the input
> > > > interrupt.
> > > 
> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
> > > mapping
> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
> > > thus be
> > > handled by forwarding the request to the GIC by
> > > irq_chip_set_affinity_parent().
> > > 
> > > As this is handled correctly in the upstream kernel since the
> > > first
> > > commit introducing support for the GPCv2, it seems the issue is
> > > only
> > > present in some downstream kernel.
> > > 
> > 
> > OK. Thanks so much for your reply.
> > 
> > I saw some of the drivers using irq_set_affinity_hint() to force
> > the
> > IRQ affinity to a particular CPU.
> > This is the sample:
> > {
> > cpumask_clear(mask);
> > cpumask_set_cpu(cpu, mask);
> > irq_set_affinity_hint(irq, mask);
> > }
> > 
> > Whether this logic will work for a particular GPIO pin ?
> > 
> > 
> > > Regards,
> > > Lucas


Re: Delivery Status Notification (Failure)

2018-05-14 Thread Pintu Kumar
Hi,

Is there any work around possible to set IRQ affinity for some GPIO interrupt ?
How to avoid CPU0 to receive the current GPIO interrupt ?
How do we assign GPIO interrupts to any CPU other than CPU0 ?
Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
that GPIO interrupt can be served by another CPU ?

Need your inputs to decide whether it is still possible to set
affinity for GPIO interrupt, or its impossible ?


Thanks,
Pintu



On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar  wrote:
> On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  wrote:
>> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I need one help.
>>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>>> >
>>> > Let's say I am interested in GPIO number: 21
>>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>>> > tried the below steps:
>>> > root@10:~# echo 21 > /sys/class/gpio/export
>>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>>> > root@10:~# cat /proc/interrupts | grep 21
>>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>>> > in
>>> > root@10:~# cat /proc/irq/47/smp_affinity
>>> > 3
>>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>>> > -bash: echo: write error: Input/output error
>>> >
>>> > But I get input/output error.
>>> > When I debug further, found that irq_can_set_affinity is returning 0:
>>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>>> > [0.00] write_irq_affinity: FAIL
>>> >
>>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>>> > This change is working, but the smp_affinity setting for the new IRQ
>>> > is not working.
>>> >
>>> > When I try to set smp_affinity for mmc0, then it works.
>>> > # cat /proc/interrupts | grep mmc
>>> > 295: 55  0 GPCV2  22 Edge  mmc0
>>> > 296:  0  0 GPCV2  23 Edge  mmc1
>>> > 297: 52  0 GPCV2  24 Edge  mmc2
>>> >
>>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>>> > root@10:~#
>>> >
>>> >
>>> > So, I wanted to know what are the conditions for which setting
>>> > smp_affinity for an IRQ will work ?
>>> >
>>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>>> > Whether, irq_set_affinity_hint() will work in this case ?
>>>
>>> IRQ affinity is only supported where interrupts are _directly_ wired to
>>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>>> cores.
>>>
>>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>>> ability to be directed independently to other CPUs - the only possible
>>> way to change the mapping is to move _all_ interrupts on that controller,
>>> and any downstream chained interrupts at GIC level.
>>>
>>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>>> for the interrupt controller itself to change the affinity of the input
>>> interrupt.
>>
>> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
>> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
>> handled by forwarding the request to the GIC by
>> irq_chip_set_affinity_parent().
>>
>> As this is handled correctly in the upstream kernel since the first
>> commit introducing support for the GPCv2, it seems the issue is only
>> present in some downstream kernel.
>>
>
> OK. Thanks so much for your reply.
>
> I saw some of the drivers using irq_set_affinity_hint() to force the
> IRQ affinity to a particular CPU.
> This is the sample:
> {
> cpumask_clear(mask);
> cpumask_set_cpu(cpu, mask);
> irq_set_affinity_hint(irq, mask);
> }
>
> Whether this logic will work for a particular GPIO pin ?
>
>
>> Regards,
>> Lucas


Re: Delivery Status Notification (Failure)

2018-05-14 Thread Pintu Kumar
Hi,

Is there any work around possible to set IRQ affinity for some GPIO interrupt ?
How to avoid CPU0 to receive the current GPIO interrupt ?
How do we assign GPIO interrupts to any CPU other than CPU0 ?
Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
that GPIO interrupt can be served by another CPU ?

Need your inputs to decide whether it is still possible to set
affinity for GPIO interrupt, or its impossible ?


Thanks,
Pintu



On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar  wrote:
> On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  wrote:
>> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I need one help.
>>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>>> >
>>> > Let's say I am interested in GPIO number: 21
>>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>>> > tried the below steps:
>>> > root@10:~# echo 21 > /sys/class/gpio/export
>>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>>> > root@10:~# cat /proc/interrupts | grep 21
>>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>>> > in
>>> > root@10:~# cat /proc/irq/47/smp_affinity
>>> > 3
>>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>>> > -bash: echo: write error: Input/output error
>>> >
>>> > But I get input/output error.
>>> > When I debug further, found that irq_can_set_affinity is returning 0:
>>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>>> > [0.00] write_irq_affinity: FAIL
>>> >
>>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>>> > This change is working, but the smp_affinity setting for the new IRQ
>>> > is not working.
>>> >
>>> > When I try to set smp_affinity for mmc0, then it works.
>>> > # cat /proc/interrupts | grep mmc
>>> > 295: 55  0 GPCV2  22 Edge  mmc0
>>> > 296:  0  0 GPCV2  23 Edge  mmc1
>>> > 297: 52  0 GPCV2  24 Edge  mmc2
>>> >
>>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>>> > root@10:~#
>>> >
>>> >
>>> > So, I wanted to know what are the conditions for which setting
>>> > smp_affinity for an IRQ will work ?
>>> >
>>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>>> > Whether, irq_set_affinity_hint() will work in this case ?
>>>
>>> IRQ affinity is only supported where interrupts are _directly_ wired to
>>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>>> cores.
>>>
>>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>>> ability to be directed independently to other CPUs - the only possible
>>> way to change the mapping is to move _all_ interrupts on that controller,
>>> and any downstream chained interrupts at GIC level.
>>>
>>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>>> for the interrupt controller itself to change the affinity of the input
>>> interrupt.
>>
>> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
>> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
>> handled by forwarding the request to the GIC by
>> irq_chip_set_affinity_parent().
>>
>> As this is handled correctly in the upstream kernel since the first
>> commit introducing support for the GPCv2, it seems the issue is only
>> present in some downstream kernel.
>>
>
> OK. Thanks so much for your reply.
>
> I saw some of the drivers using irq_set_affinity_hint() to force the
> IRQ affinity to a particular CPU.
> This is the sample:
> {
> cpumask_clear(mask);
> cpumask_set_cpu(cpu, mask);
> irq_set_affinity_hint(irq, mask);
> }
>
> Whether this logic will work for a particular GPIO pin ?
>
>
>> Regards,
>> Lucas


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Pintu Kumar
On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  wrote:
> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > Hi,
>> >
>> > I need one help.
>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >
>> > Let's say I am interested in GPIO number: 21
>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>> > tried the below steps:
>> > root@10:~# echo 21 > /sys/class/gpio/export
>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > root@10:~# cat /proc/interrupts | grep 21
>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > in
>> > root@10:~# cat /proc/irq/47/smp_affinity
>> > 3
>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > -bash: echo: write error: Input/output error
>> >
>> > But I get input/output error.
>> > When I debug further, found that irq_can_set_affinity is returning 0:
>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > [0.00] write_irq_affinity: FAIL
>> >
>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>> > This change is working, but the smp_affinity setting for the new IRQ
>> > is not working.
>> >
>> > When I try to set smp_affinity for mmc0, then it works.
>> > # cat /proc/interrupts | grep mmc
>> > 295: 55  0 GPCV2  22 Edge  mmc0
>> > 296:  0  0 GPCV2  23 Edge  mmc1
>> > 297: 52  0 GPCV2  24 Edge  mmc2
>> >
>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > root@10:~#
>> >
>> >
>> > So, I wanted to know what are the conditions for which setting
>> > smp_affinity for an IRQ will work ?
>> >
>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>> > Whether, irq_set_affinity_hint() will work in this case ?
>>
>> IRQ affinity is only supported where interrupts are _directly_ wired to
>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>> cores.
>>
>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>> ability to be directed independently to other CPUs - the only possible
>> way to change the mapping is to move _all_ interrupts on that controller,
>> and any downstream chained interrupts at GIC level.
>>
>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>> for the interrupt controller itself to change the affinity of the input
>> interrupt.
>
> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
> handled by forwarding the request to the GIC by
> irq_chip_set_affinity_parent().
>
> As this is handled correctly in the upstream kernel since the first
> commit introducing support for the GPCv2, it seems the issue is only
> present in some downstream kernel.
>

OK. Thanks so much for your reply.

I saw some of the drivers using irq_set_affinity_hint() to force the
IRQ affinity to a particular CPU.
This is the sample:
{
cpumask_clear(mask);
cpumask_set_cpu(cpu, mask);
irq_set_affinity_hint(irq, mask);
}

Whether this logic will work for a particular GPIO pin ?


> Regards,
> Lucas


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Pintu Kumar
On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  wrote:
> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > Hi,
>> >
>> > I need one help.
>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>> >
>> > Let's say I am interested in GPIO number: 21
>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>> > tried the below steps:
>> > root@10:~# echo 21 > /sys/class/gpio/export
>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > root@10:~# cat /proc/interrupts | grep 21
>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > in
>> > root@10:~# cat /proc/irq/47/smp_affinity
>> > 3
>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > -bash: echo: write error: Input/output error
>> >
>> > But I get input/output error.
>> > When I debug further, found that irq_can_set_affinity is returning 0:
>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > [0.00] write_irq_affinity: FAIL
>> >
>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>> > This change is working, but the smp_affinity setting for the new IRQ
>> > is not working.
>> >
>> > When I try to set smp_affinity for mmc0, then it works.
>> > # cat /proc/interrupts | grep mmc
>> > 295: 55  0 GPCV2  22 Edge  mmc0
>> > 296:  0  0 GPCV2  23 Edge  mmc1
>> > 297: 52  0 GPCV2  24 Edge  mmc2
>> >
>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > root@10:~#
>> >
>> >
>> > So, I wanted to know what are the conditions for which setting
>> > smp_affinity for an IRQ will work ?
>> >
>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>> > Whether, irq_set_affinity_hint() will work in this case ?
>>
>> IRQ affinity is only supported where interrupts are _directly_ wired to
>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>> cores.
>>
>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>> ability to be directed independently to other CPUs - the only possible
>> way to change the mapping is to move _all_ interrupts on that controller,
>> and any downstream chained interrupts at GIC level.
>>
>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>> for the interrupt controller itself to change the affinity of the input
>> interrupt.
>
> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
> handled by forwarding the request to the GIC by
> irq_chip_set_affinity_parent().
>
> As this is handled correctly in the upstream kernel since the first
> commit introducing support for the GPCv2, it seems the issue is only
> present in some downstream kernel.
>

OK. Thanks so much for your reply.

I saw some of the drivers using irq_set_affinity_hint() to force the
IRQ affinity to a particular CPU.
This is the sample:
{
cpumask_clear(mask);
cpumask_set_cpu(cpu, mask);
irq_set_affinity_hint(irq, mask);
}

Whether this logic will work for a particular GPIO pin ?


> Regards,
> Lucas


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Lucas Stach
Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> > Hi,
> > 
> > I need one help.
> > I am using i.MX7 Sabre board with kernel version 4.1.15
> > 
> > Let's say I am interested in GPIO number: 21
> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
> > tried the below steps:
> > root@10:~# echo 21 > /sys/class/gpio/export
> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > root@10:~# cat /proc/interrupts | grep 21
> >   47: 0 0 gpio-mxc 21 Edge gpiolib
> > root@10:~# cat /sys/class/gpio/gpio21/direction
> > in
> > root@10:~# cat /proc/irq/47/smp_affinity
> > 3
> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> > -bash: echo: write error: Input/output error
> > 
> > But I get input/output error.
> > When I debug further, found that irq_can_set_affinity is returning 0:
> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> > [0.00] write_irq_affinity: FAIL
> > 
> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
> > This change is working, but the smp_affinity setting for the new IRQ
> > is not working.
> > 
> > When I try to set smp_affinity for mmc0, then it works.
> > # cat /proc/interrupts | grep mmc
> > 295: 55  0 GPCV2  22 Edge  mmc0
> > 296:  0  0 GPCV2  23 Edge  mmc1
> > 297: 52  0 GPCV2  24 Edge  mmc2
> > 
> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
> > root@10:~#
> > 
> > 
> > So, I wanted to know what are the conditions for which setting
> > smp_affinity for an IRQ will work ?
> > 
> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
> > Whether, irq_set_affinity_hint() will work in this case ?
> 
> IRQ affinity is only supported where interrupts are _directly_ wired to
> the GIC.  It's the GIC which does the interrupt steering to the CPU
> cores.
> 
> Interrupts on downstream interrupt controllers (such as GPCV2) have no
> ability to be directed independently to other CPUs - the only possible
> way to change the mapping is to move _all_ interrupts on that controller,
> and any downstream chained interrupts at GIC level.
> 
> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
> for the interrupt controller itself to change the affinity of the input
> interrupt.

The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
handled by forwarding the request to the GIC by
irq_chip_set_affinity_parent().

As this is handled correctly in the upstream kernel since the first
commit introducing support for the GPCv2, it seems the issue is only
present in some downstream kernel.

Regards,
Lucas


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Lucas Stach
Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> > Hi,
> > 
> > I need one help.
> > I am using i.MX7 Sabre board with kernel version 4.1.15
> > 
> > Let's say I am interested in GPIO number: 21
> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
> > tried the below steps:
> > root@10:~# echo 21 > /sys/class/gpio/export
> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > root@10:~# cat /proc/interrupts | grep 21
> >   47: 0 0 gpio-mxc 21 Edge gpiolib
> > root@10:~# cat /sys/class/gpio/gpio21/direction
> > in
> > root@10:~# cat /proc/irq/47/smp_affinity
> > 3
> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> > -bash: echo: write error: Input/output error
> > 
> > But I get input/output error.
> > When I debug further, found that irq_can_set_affinity is returning 0:
> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> > [0.00] write_irq_affinity: FAIL
> > 
> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
> > This change is working, but the smp_affinity setting for the new IRQ
> > is not working.
> > 
> > When I try to set smp_affinity for mmc0, then it works.
> > # cat /proc/interrupts | grep mmc
> > 295: 55  0 GPCV2  22 Edge  mmc0
> > 296:  0  0 GPCV2  23 Edge  mmc1
> > 297: 52  0 GPCV2  24 Edge  mmc2
> > 
> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
> > root@10:~#
> > 
> > 
> > So, I wanted to know what are the conditions for which setting
> > smp_affinity for an IRQ will work ?
> > 
> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
> > Whether, irq_set_affinity_hint() will work in this case ?
> 
> IRQ affinity is only supported where interrupts are _directly_ wired to
> the GIC.  It's the GIC which does the interrupt steering to the CPU
> cores.
> 
> Interrupts on downstream interrupt controllers (such as GPCV2) have no
> ability to be directed independently to other CPUs - the only possible
> way to change the mapping is to move _all_ interrupts on that controller,
> and any downstream chained interrupts at GIC level.
> 
> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
> for the interrupt controller itself to change the affinity of the input
> interrupt.

The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
handled by forwarding the request to the GIC by
irq_chip_set_affinity_parent().

As this is handled correctly in the upstream kernel since the first
commit introducing support for the GPCv2, it seems the issue is only
present in some downstream kernel.

Regards,
Lucas


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Russell King - ARM Linux
On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> Hi,
> 
> I need one help.
> I am using i.MX7 Sabre board with kernel version 4.1.15
> 
> Let's say I am interested in GPIO number: 21
> I wanted to set CPU affinity for particular GPIO->IRQ number, so I
> tried the below steps:
> root@10:~# echo 21 > /sys/class/gpio/export
> root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> root@10:~# cat /proc/interrupts | grep 21
>   47: 0 0 gpio-mxc 21 Edge gpiolib
> root@10:~# cat /sys/class/gpio/gpio21/direction
> in
> root@10:~# cat /proc/irq/47/smp_affinity
> 3
> root@10:~# echo 2 > /proc/irq/47/smp_affinity
> -bash: echo: write error: Input/output error
> 
> But I get input/output error.
> When I debug further, found that irq_can_set_affinity is returning 0:
> [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> [0.00] write_irq_affinity: FAIL
> 
> I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
> This change is working, but the smp_affinity setting for the new IRQ
> is not working.
> 
> When I try to set smp_affinity for mmc0, then it works.
> # cat /proc/interrupts | grep mmc
> 295: 55  0 GPCV2  22 Edge  mmc0
> 296:  0  0 GPCV2  23 Edge  mmc1
> 297: 52  0 GPCV2  24 Edge  mmc2
> 
> root@10:~# echo 2 > /proc/irq/295/smp_affinity
> root@10:~#
> 
> 
> So, I wanted to know what are the conditions for which setting
> smp_affinity for an IRQ will work ?
> 
> Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
> Whether, irq_set_affinity_hint() will work in this case ?

IRQ affinity is only supported where interrupts are _directly_ wired to
the GIC.  It's the GIC which does the interrupt steering to the CPU
cores.

Interrupts on downstream interrupt controllers (such as GPCV2) have no
ability to be directed independently to other CPUs - the only possible
way to change the mapping is to move _all_ interrupts on that controller,
and any downstream chained interrupts at GIC level.

Hence why Interrupt 295 has no irq_set_affinity function: there is no way
for the interrupt controller itself to change the affinity of the input
interrupt.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Russell King - ARM Linux
On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> Hi,
> 
> I need one help.
> I am using i.MX7 Sabre board with kernel version 4.1.15
> 
> Let's say I am interested in GPIO number: 21
> I wanted to set CPU affinity for particular GPIO->IRQ number, so I
> tried the below steps:
> root@10:~# echo 21 > /sys/class/gpio/export
> root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> root@10:~# cat /proc/interrupts | grep 21
>   47: 0 0 gpio-mxc 21 Edge gpiolib
> root@10:~# cat /sys/class/gpio/gpio21/direction
> in
> root@10:~# cat /proc/irq/47/smp_affinity
> 3
> root@10:~# echo 2 > /proc/irq/47/smp_affinity
> -bash: echo: write error: Input/output error
> 
> But I get input/output error.
> When I debug further, found that irq_can_set_affinity is returning 0:
> [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> [0.00] write_irq_affinity: FAIL
> 
> I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
> This change is working, but the smp_affinity setting for the new IRQ
> is not working.
> 
> When I try to set smp_affinity for mmc0, then it works.
> # cat /proc/interrupts | grep mmc
> 295: 55  0 GPCV2  22 Edge  mmc0
> 296:  0  0 GPCV2  23 Edge  mmc1
> 297: 52  0 GPCV2  24 Edge  mmc2
> 
> root@10:~# echo 2 > /proc/irq/295/smp_affinity
> root@10:~#
> 
> 
> So, I wanted to know what are the conditions for which setting
> smp_affinity for an IRQ will work ?
> 
> Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
> Whether, irq_set_affinity_hint() will work in this case ?

IRQ affinity is only supported where interrupts are _directly_ wired to
the GIC.  It's the GIC which does the interrupt steering to the CPU
cores.

Interrupts on downstream interrupt controllers (such as GPCV2) have no
ability to be directed independently to other CPUs - the only possible
way to change the mapping is to move _all_ interrupts on that controller,
and any downstream chained interrupts at GIC level.

Hence why Interrupt 295 has no irq_set_affinity function: there is no way
for the interrupt controller itself to change the affinity of the input
interrupt.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Pintu Kumar
Hi,

I need one help.
I am using i.MX7 Sabre board with kernel version 4.1.15

Let's say I am interested in GPIO number: 21
I wanted to set CPU affinity for particular GPIO->IRQ number, so I
tried the below steps:
root@10:~# echo 21 > /sys/class/gpio/export
root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
root@10:~# cat /proc/interrupts | grep 21
  47: 0 0 gpio-mxc 21 Edge gpiolib
root@10:~# cat /sys/class/gpio/gpio21/direction
in
root@10:~# cat /proc/irq/47/smp_affinity
3
root@10:~# echo 2 > /proc/irq/47/smp_affinity
-bash: echo: write error: Input/output error

But I get input/output error.
When I debug further, found that irq_can_set_affinity is returning 0:
[0.00] genirq: irq_can_set_affinity (0): balance: 1,
irq_data.chip: a81b7e48, irq_set_affinity:   (null)
[0.00] write_irq_affinity: FAIL

I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
This change is working, but the smp_affinity setting for the new IRQ
is not working.

When I try to set smp_affinity for mmc0, then it works.
# cat /proc/interrupts | grep mmc
295: 55  0 GPCV2  22 Edge  mmc0
296:  0  0 GPCV2  23 Edge  mmc1
297: 52  0 GPCV2  24 Edge  mmc2

root@10:~# echo 2 > /proc/irq/295/smp_affinity
root@10:~#


So, I wanted to know what are the conditions for which setting
smp_affinity for an IRQ will work ?

Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
Whether, irq_set_affinity_hint() will work in this case ?


Thanks,
Pintu


Re: Delivery Status Notification (Failure)

2018-05-11 Thread Pintu Kumar
Hi,

I need one help.
I am using i.MX7 Sabre board with kernel version 4.1.15

Let's say I am interested in GPIO number: 21
I wanted to set CPU affinity for particular GPIO->IRQ number, so I
tried the below steps:
root@10:~# echo 21 > /sys/class/gpio/export
root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
root@10:~# cat /proc/interrupts | grep 21
  47: 0 0 gpio-mxc 21 Edge gpiolib
root@10:~# cat /sys/class/gpio/gpio21/direction
in
root@10:~# cat /proc/irq/47/smp_affinity
3
root@10:~# echo 2 > /proc/irq/47/smp_affinity
-bash: echo: write error: Input/output error

But I get input/output error.
When I debug further, found that irq_can_set_affinity is returning 0:
[0.00] genirq: irq_can_set_affinity (0): balance: 1,
irq_data.chip: a81b7e48, irq_set_affinity:   (null)
[0.00] write_irq_affinity: FAIL

I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
This change is working, but the smp_affinity setting for the new IRQ
is not working.

When I try to set smp_affinity for mmc0, then it works.
# cat /proc/interrupts | grep mmc
295: 55  0 GPCV2  22 Edge  mmc0
296:  0  0 GPCV2  23 Edge  mmc1
297: 52  0 GPCV2  24 Edge  mmc2

root@10:~# echo 2 > /proc/irq/295/smp_affinity
root@10:~#


So, I wanted to know what are the conditions for which setting
smp_affinity for an IRQ will work ?

Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
Whether, irq_set_affinity_hint() will work in this case ?


Thanks,
Pintu


Delivery Status Notification (Failure)

2018-04-06 Thread Admins
Please notice that the mail sent by you to dd...@safe-mail.net
has been rejected.
Reason: The mailbox of dd...@safe-mail.net is full.

The message was received by the safe-mail.net secure mailing system.
The safe-mail.net system enables people to exchange confidential
information in a highly SECURE and RELIABLE environment.
To see more go to web site http://www.Safe-mail.net and follow the prompts.

(C) Safe-mail Ltd. 1998-2018
safe-mail.net


Delivery Status Notification (Failure)

2018-04-06 Thread Admins
Please notice that the mail sent by you to dd...@safe-mail.net
has been rejected.
Reason: The mailbox of dd...@safe-mail.net is full.

The message was received by the safe-mail.net secure mailing system.
The safe-mail.net system enables people to exchange confidential
information in a highly SECURE and RELIABLE environment.
To see more go to web site http://www.Safe-mail.net and follow the prompts.

(C) Safe-mail Ltd. 1998-2018
safe-mail.net


Fwd: Delivery Status Notification (Failure)

2016-09-28 Thread gengdongjiu
Hi,
  In the kernel 4.1, I am confused for the
runnable_avg_sum/avg_period/running_avg_sum,
for example below code.
Does the task runnable_avg_sum includes running_avg_sum? Does avg_period
includes the task runnable_avg_sum and the task sleep time? thank you.

static inline void __update_task_entity_contrib(struct sched_entity *se)
{
u32 contrib;

/* avoid overflowing a 32-bit type w/ SCHED_LOAD_SCALE */
contrib = se->avg.runnable_avg_sum * scale_load_down(se->load.
weight);
contrib /= (se->avg.avg_period + 1);
se->avg.load_avg_contrib = scale_load(contrib);
}


static inline void __update_task_entity_utilization(struct sched_entity *se)
{
u32 contrib;

/* avoid overflowing a 32-bit type w/ SCHED_LOAD_SCALE */
contrib = se->avg.running_avg_sum * scale_load_down(SCHED_LOAD_
SCALE);
contrib /= (se->avg.avg_period + 1);
se->avg.utilization_avg_contrib = scale_load(contrib);
}


Fwd: Delivery Status Notification (Failure)

2016-09-28 Thread gengdongjiu
Hi,
  In the kernel 4.1, I am confused for the
runnable_avg_sum/avg_period/running_avg_sum,
for example below code.
Does the task runnable_avg_sum includes running_avg_sum? Does avg_period
includes the task runnable_avg_sum and the task sleep time? thank you.

static inline void __update_task_entity_contrib(struct sched_entity *se)
{
u32 contrib;

/* avoid overflowing a 32-bit type w/ SCHED_LOAD_SCALE */
contrib = se->avg.runnable_avg_sum * scale_load_down(se->load.
weight);
contrib /= (se->avg.avg_period + 1);
se->avg.load_avg_contrib = scale_load(contrib);
}


static inline void __update_task_entity_utilization(struct sched_entity *se)
{
u32 contrib;

/* avoid overflowing a 32-bit type w/ SCHED_LOAD_SCALE */
contrib = se->avg.running_avg_sum * scale_load_down(SCHED_LOAD_
SCALE);
contrib /= (se->avg.avg_period + 1);
se->avg.utilization_avg_contrib = scale_load(contrib);
}


Re: Delivery Status Notification (Failure)

2014-03-06 Thread Alan Stern
On Thu, 6 Mar 2014, Jagdish Gedia wrote:

> Hi Alan,
> 
> Thanks for you informative reply.
> I will try your suggestion. yes, i will not get more than one wakeup per 
> second.
> 
> I have tried below things.
> My usb device is using the cdc-acm.c driver.
> 
> inside cdc-acm.c file,
> 
> static struct usb_device *usb_device;
> 
> static int acm_probe(, )
> {
> usb_device = interface_to_usbdev(intf);
> ..
> }
> 
> inside interrupt handler
> 
> static irqhandle_t int_handler(..., ..)
> {
>usb_lock_device(usb_device);
>usb_remote_wakeup(usb_device);
>usb_unlock_device(usb_device);
>return IRQ_HANDLED;
> }
> 
> but these things are not working. kernel is crashing when interrupt occurs.

Because you didn't do what I said: Call pm_request_resume.  Not 
usb_remote_wakeup.

> I have some other doubt also.
> 
> 1. If usb is runtime suspended and if global suspend happens , do i
> need to do anything special to wakeup the usb device?

No.

> 2. How can i address particularly my usb device. right now, i am using
> usb_device = interface_to_usbdev(intf) to get pointer to my usb device
> inside probe function,

That's a perfectly good way to do it.  Lots of other drivers do the 
same thing.

>  but probe function is getting called for every
> interface of the device. Is there any other way through which i can
> get the pointer to my usb device like i can traverse all the available
> usb device and on basis of vendor and product id i can address my usb
> device or by any other way?

You can't get the device pointer unless you have something to start 
from.  For example, if you already have an interface pointer then you 
can use interface_to_usbdev.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Delivery Status Notification (Failure)

2014-03-06 Thread Alan Stern
On Thu, 6 Mar 2014, Jagdish Gedia wrote:

 Hi Alan,
 
 Thanks for you informative reply.
 I will try your suggestion. yes, i will not get more than one wakeup per 
 second.
 
 I have tried below things.
 My usb device is using the cdc-acm.c driver.
 
 inside cdc-acm.c file,
 
 static struct usb_device *usb_device;
 
 static int acm_probe(, )
 {
 usb_device = interface_to_usbdev(intf);
 ..
 }
 
 inside interrupt handler
 
 static irqhandle_t int_handler(..., ..)
 {
usb_lock_device(usb_device);
usb_remote_wakeup(usb_device);
usb_unlock_device(usb_device);
return IRQ_HANDLED;
 }
 
 but these things are not working. kernel is crashing when interrupt occurs.

Because you didn't do what I said: Call pm_request_resume.  Not 
usb_remote_wakeup.

 I have some other doubt also.
 
 1. If usb is runtime suspended and if global suspend happens , do i
 need to do anything special to wakeup the usb device?

No.

 2. How can i address particularly my usb device. right now, i am using
 usb_device = interface_to_usbdev(intf) to get pointer to my usb device
 inside probe function,

That's a perfectly good way to do it.  Lots of other drivers do the 
same thing.

  but probe function is getting called for every
 interface of the device. Is there any other way through which i can
 get the pointer to my usb device like i can traverse all the available
 usb device and on basis of vendor and product id i can address my usb
 device or by any other way?

You can't get the device pointer unless you have something to start 
from.  For example, if you already have an interface pointer then you 
can use interface_to_usbdev.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Delivery Status Notification (Failure)

2014-03-05 Thread Jagdish Gedia
Hi Alan,

Thanks for you informative reply.
I will try your suggestion. yes, i will not get more than one wakeup per second.

I have tried below things.
My usb device is using the cdc-acm.c driver.

inside cdc-acm.c file,

static struct usb_device *usb_device;

static int acm_probe(, )
{
usb_device = interface_to_usbdev(intf);
..
}

inside interrupt handler

static irqhandle_t int_handler(..., ..)
{
   usb_lock_device(usb_device);
   usb_remote_wakeup(usb_device);
   usb_unlock_device(usb_device);
   return IRQ_HANDLED;
}

but these things are not working. kernel is crashing when interrupt occurs.

I have some other doubt also.

1. If usb is runtime suspended and if global suspend happens , do i
need to do anything special to wakeup the usb device?

2. How can i address particularly my usb device. right now, i am using
usb_device = interface_to_usbdev(intf) to get pointer to my usb device
inside probe function, but probe function is getting called for every
interface of the device. Is there any other way through which i can
get the pointer to my usb device like i can traverse all the available
usb device and on basis of vendor and product id i can address my usb
device or by any other way?


thanks,
jagdish gediya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Delivery Status Notification (Failure)

2014-03-05 Thread Jagdish Gedia
Hi Alan,

Thanks for you informative reply.
I will try your suggestion. yes, i will not get more than one wakeup per second.

I have tried below things.
My usb device is using the cdc-acm.c driver.

inside cdc-acm.c file,

static struct usb_device *usb_device;

static int acm_probe(, )
{
usb_device = interface_to_usbdev(intf);
..
}

inside interrupt handler

static irqhandle_t int_handler(..., ..)
{
   usb_lock_device(usb_device);
   usb_remote_wakeup(usb_device);
   usb_unlock_device(usb_device);
   return IRQ_HANDLED;
}

but these things are not working. kernel is crashing when interrupt occurs.

I have some other doubt also.

1. If usb is runtime suspended and if global suspend happens , do i
need to do anything special to wakeup the usb device?

2. How can i address particularly my usb device. right now, i am using
usb_device = interface_to_usbdev(intf) to get pointer to my usb device
inside probe function, but probe function is getting called for every
interface of the device. Is there any other way through which i can
get the pointer to my usb device like i can traverse all the available
usb device and on basis of vendor and product id i can address my usb
device or by any other way?


thanks,
jagdish gediya
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Fw: Delivery Status Notification (Failure)

2001-06-13 Thread William Scott Lockwood III

Gee Andre, I guess people who use hotmail don't have an opinion you'd care
to read?
- Original Message -
From: +ADw-postmaster+AEA-mail.hotmail.com+AD4-
To: +ADw-thatlinuxguy+AEA-hotmail.com+AD4-
Sent: Wednesday, June 13, 2001 8:12 PM
Subject: Delivery Status Notification (Failure)


+AD4- This is an automatically generated Delivery Status Notification.
+AD4-
+AD4- Delivery to the following recipients failed.
+AD4-
+AD4-andre+AEA-linux-ide.org
+AD4-
+AD4-
+AD4-
+AD4-

 ATT00063.dat


Dear Mr. Lyons,
  I think it's very exciting to see someone from promise talking to the
community.  I think the most important thing to remember is that even if the
company does not release source, people will reverse engineer the cards
anyway - possibly not giving the best support to the hardware that could be
given with GPL'd source.  How does that make the product look?  If I can buy
a controller that is very well documented (like my Adaptec 2940) and will
serve my needs, and has source, I (personally) will pick that card over a
closed source product where I cannot update the binary only driver provided
by the manufacturer.  While I recognize that sometimes it's hard to get
"suits" to understand this, I encourage you to try.  :-)
  Along these lines, I'm wondering what your interest, and Promise's policy
is about Interviews?  I'm curious to get your companies views on Linux, and
also yours - I run a small (VERY loose, VERY non-serious) website called
http://www.geekizoid.com/ and while we mostly cover troll related net humor,
we also are trying to branch out and do more serious stuff.  The Interview
(if you would agree to it) would be "Slashdot style" - we'd let the
readership know you were willing to answer questions, and we'd then forward
them to you - you would then answer the ones you wanted, and those answers,
verbatim with no editing, would appear with the questions as asked.

William Scott Lockwood III
Geekizoid Webmaster

- Original Message -
From: "Craig Lyons" <[EMAIL PROTECTED]>
To: "'Andre Hedrick'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 6:52 PM
Subject: RE: Eye2Eye a hope for Promise to Join Linux


> Hi,
>
> Andre and I did indeed have a nice conversation on the phone. Thank you
> again for taking the time to talk with me and offering your assistance. As
I
> stated on the phone, we are making a large commitment of resources to
> supporting Linux by releasing drivers and utilities for our products,
> including the FastTrak. I know we have plans to release source for our
Ultra
> and SuperTrak series cards, but at this point I'm not sure that the way we
> are going to be supporting FastTrak is what you would like to see. As I
> said, while I cannot guarantee anything that I don't have the authority to
> deliver, I will pass on your requests. I will try to be an advocate for
> Promise in the Linux community, and an advocate for the Linux community to
> Promise. If the company has concerns, I will let you know what they are,
and
> then maybe you can tell us if we are off-base with those concerns or not.
>
> I would invite anybody to contact me if you have any suggestions, any
> requests, whatever. As I told Andre, I won't promise something I can't
> personally deliver, but I will do whatever I can to help out. I'm also
> trying to get a technical point of contact so that you don't have to deal
> with a marketing weenie who doesn't understand half of what you're saying
> ;).
>
> Regards,
>
> Craig
>
>
> -Original Message-
> From: Andre Hedrick [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 13, 2001 2:43 PM
> To: Craig Lyons
> Cc: [EMAIL PROTECTED]
> Subject: Eye2Eye a hope for Promise to Join Linux
>
>
>
> Greetings Craig,
>
> I would like to publicly thank you for coming to the table of GNU/GPL with
> an open perspective.  After 90 minutes on the phone, of which 45 minutes
> were me pointing out issues promblems and complaints w/ 20 minutes on ways
> to work on solutions in the near and distant future and the listening to
> your concerns and questions between my moments of interruption.
>
> The next conversion will not have the burst-in moments because it will be
> in person or my cell battery will be fully charged.
>
> Since you have stated "I will not make promise, I can not keep" this is a
> good thing and it will go a fair way to clean up messes from the past on
> both sides.
>
> I look forward to Promise working with Linux in meaningful and productive
> ways.
>
> Please reply and correct anything that is mistated by me or verify the
> correctness.  This will show an action of good-faith before all those
> watching here.
>
> Respectfully,
>
> Andre Hedrick
> Linux ATA Development
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>





Fw: Delivery Status Notification (Failure)

2001-06-13 Thread William Scott Lockwood III

Gee Andre, I guess people who use hotmail don't have an opinion you'd care
to read?
- Original Message -
From: +ADw-postmaster+AEA-mail.hotmail.com+AD4-
To: +ADw-thatlinuxguy+AEA-hotmail.com+AD4-
Sent: Wednesday, June 13, 2001 8:12 PM
Subject: Delivery Status Notification (Failure)


+AD4- This is an automatically generated Delivery Status Notification.
+AD4-
+AD4- Delivery to the following recipients failed.
+AD4-
+AD4-andre+AEA-linux-ide.org
+AD4-
+AD4-
+AD4-
+AD4-

 ATT00063.dat


Dear Mr. Lyons,
  I think it's very exciting to see someone from promise talking to the
community.  I think the most important thing to remember is that even if the
company does not release source, people will reverse engineer the cards
anyway - possibly not giving the best support to the hardware that could be
given with GPL'd source.  How does that make the product look?  If I can buy
a controller that is very well documented (like my Adaptec 2940) and will
serve my needs, and has source, I (personally) will pick that card over a
closed source product where I cannot update the binary only driver provided
by the manufacturer.  While I recognize that sometimes it's hard to get
suits to understand this, I encourage you to try.  :-)
  Along these lines, I'm wondering what your interest, and Promise's policy
is about Interviews?  I'm curious to get your companies views on Linux, and
also yours - I run a small (VERY loose, VERY non-serious) website called
http://www.geekizoid.com/ and while we mostly cover troll related net humor,
we also are trying to branch out and do more serious stuff.  The Interview
(if you would agree to it) would be Slashdot style - we'd let the
readership know you were willing to answer questions, and we'd then forward
them to you - you would then answer the ones you wanted, and those answers,
verbatim with no editing, would appear with the questions as asked.

William Scott Lockwood III
Geekizoid Webmaster

- Original Message -
From: Craig Lyons [EMAIL PROTECTED]
To: 'Andre Hedrick' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, June 13, 2001 6:52 PM
Subject: RE: Eye2Eye a hope for Promise to Join Linux


 Hi,

 Andre and I did indeed have a nice conversation on the phone. Thank you
 again for taking the time to talk with me and offering your assistance. As
I
 stated on the phone, we are making a large commitment of resources to
 supporting Linux by releasing drivers and utilities for our products,
 including the FastTrak. I know we have plans to release source for our
Ultra
 and SuperTrak series cards, but at this point I'm not sure that the way we
 are going to be supporting FastTrak is what you would like to see. As I
 said, while I cannot guarantee anything that I don't have the authority to
 deliver, I will pass on your requests. I will try to be an advocate for
 Promise in the Linux community, and an advocate for the Linux community to
 Promise. If the company has concerns, I will let you know what they are,
and
 then maybe you can tell us if we are off-base with those concerns or not.

 I would invite anybody to contact me if you have any suggestions, any
 requests, whatever. As I told Andre, I won't promise something I can't
 personally deliver, but I will do whatever I can to help out. I'm also
 trying to get a technical point of contact so that you don't have to deal
 with a marketing weenie who doesn't understand half of what you're saying
 ;).

 Regards,

 Craig


 -Original Message-
 From: Andre Hedrick [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, June 13, 2001 2:43 PM
 To: Craig Lyons
 Cc: [EMAIL PROTECTED]
 Subject: Eye2Eye a hope for Promise to Join Linux



 Greetings Craig,

 I would like to publicly thank you for coming to the table of GNU/GPL with
 an open perspective.  After 90 minutes on the phone, of which 45 minutes
 were me pointing out issues promblems and complaints w/ 20 minutes on ways
 to work on solutions in the near and distant future and the listening to
 your concerns and questions between my moments of interruption.

 The next conversion will not have the burst-in moments because it will be
 in person or my cell battery will be fully charged.

 Since you have stated I will not make promise, I can not keep this is a
 good thing and it will go a fair way to clean up messes from the past on
 both sides.

 I look forward to Promise working with Linux in meaningful and productive
 ways.

 Please reply and correct anything that is mistated by me or verify the
 correctness.  This will show an action of good-faith before all those
 watching here.

 Respectfully,

 Andre Hedrick
 Linux ATA Development

 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/