Delivery Status Notification (Failure)

Delivery Status Notification (Failure)

[Nick Krause]

Does anybody have some work in the scheduler subsystem I can work on
 that is a good top dipping for a kernel newbie.
Regards Nick

Delivery Status Notification (Failure)

[Valdis.Kletnieks at vt.edu]

On Wed, 06 Aug 2014 15:07:21 -0400, Nick Krause said:
> Does anybody have some work in the scheduler subsystem I can work on
>  that is a good top dipping for a kernel newbie.

There is zero code in the scheduler that somebody of your demonstrated
competence will be able to successfully modify.

For that matter, there is zero code in most of the rest of the kernel
that you're in any position to patch.

Do yourself and the world a favor - make a resolution to *NOT* attempt
a patch of anything in the calendar year 2014, and spend the time learning.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140806/03929bbf/attachment.bin 

Delivery Status Notification (Failure)

[priyaranjan]

>On Thu, Aug 7, 2014 at 12:59 AM, <Valdis.Kletnieks@vt.edu> wrote:

> >On Wed, 06 Aug 2014 15:07:21 -0400, Nick Krause said:
> >> Does anybody have some work in the scheduler subsystem I can work on
> >>  that is a good top dipping for a kernel newbie.
>
>
I think you should start with learning the schedular and it code....may be
you can find something...



> >There is zero code in the scheduler that somebody of your demonstrated
> >competence will be able to successfully modify.
>
> >For that matter, there is zero code in most of the rest of the kernel
> >that you're in any position to patch.
>

One shouldn't judge a book by its cover....This is a newbie list, If  all
people here are already competent enough to post high-end patches(though
patching a kernel might not be a very huge thing in this world, given that
there are more complex things in this world) ..then there would be not need
of a newbie list.


>
> >Do yourself and the world a favor - make a resolution to *NOT* attempt
> >a patch of anything in the calendar year 2014, and spend the time
> learning.
>
>


Its always a good idea to keep learning and keep others motivated to
learn... :)


> ______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140807/32a1babd/attachment.html 

Delivery Status Notification (Failure)

[Pramod Gurav]

On Thu, Aug 7, 2014 at 12:15 PM, priyaranjan <priyaranjan45678@gmail.com> wrote:
>
>
>
>>On Thu, Aug 7, 2014 at 12:59 AM, <Valdis.Kletnieks@vt.edu> wrote:
>>
>> >On Wed, 06 Aug 2014 15:07:21 -0400, Nick Krause said:
>> >> Does anybody have some work in the scheduler subsystem I can work on
>> >>  that is a good top dipping for a kernel newbie.
>>
>
> I think you should start with learning the schedular and it code....may be
> you can find something...
>
>
>>
>> >There is zero code in the scheduler that somebody of your demonstrated
>> >competence will be able to successfully modify.
>>
>> >For that matter, there is zero code in most of the rest of the kernel
>> >that you're in any position to patch.
>
>
> One shouldn't judge a book by its cover....This is a newbie list, If  all
> people here are already competent enough to post high-end patches(though
> patching a kernel might not be a very huge thing in this world, given that
> there are more complex things in this world) ..then there would be not need
> of a newbie list.
>
Priyaranjan,

With that analogy, Nick's book is a big hit in lkml! :) Nobody wants
to read it! lol
Nick, No offence meant!
>>
>>
>> >Do yourself and the world a favor - make a resolution to *NOT* attempt
>> >a patch of anything in the calendar year 2014, and spend the time
>> > learning.
>>
>>
>
>
> Its always a good idea to keep learning and keep others motivated to
> learn... :)
>
>>
>> ______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Thanks and Regards
Pramod

Delivery Status Notification (Failure)

[Nick Krause]

On Thu, Aug 7, 2014 at 8:29 AM, Pramod Gurav <pramod.gurav.etc@gmail.com> wrote:
> On Thu, Aug 7, 2014 at 12:15 PM, priyaranjan <priyaranjan45678@gmail.com> wrote:
>>
>>
>>
>>>On Thu, Aug 7, 2014 at 12:59 AM, <Valdis.Kletnieks@vt.edu> wrote:
>>>
>>> >On Wed, 06 Aug 2014 15:07:21 -0400, Nick Krause said:
>>> >> Does anybody have some work in the scheduler subsystem I can work on
>>> >>  that is a good top dipping for a kernel newbie.
>>>
>>
>> I think you should start with learning the schedular and it code....may be
>> you can find something...
>>
>>
>>>
>>> >There is zero code in the scheduler that somebody of your demonstrated
>>> >competence will be able to successfully modify.
>>>
>>> >For that matter, there is zero code in most of the rest of the kernel
>>> >that you're in any position to patch.
>>
>>
>> One shouldn't judge a book by its cover....This is a newbie list, If  all
>> people here are already competent enough to post high-end patches(though
>> patching a kernel might not be a very huge thing in this world, given that
>> there are more complex things in this world) ..then there would be not need
>> of a newbie list.
>>
> Priyaranjan,
>
> With that analogy, Nick's book is a big hit in lkml! :) Nobody wants
> to read it! lol
> Nick, No offence meant!
>>>
>>>
>>> >Do yourself and the world a favor - make a resolution to *NOT* attempt
>>> >a patch of anything in the calendar year 2014, and spend the time
>>> > learning.
>>>
>>>
>>
>>
>> Its always a good idea to keep learning and keep others motivated to
>> learn... :)
>>
>>>
>>> ______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
>
> --
> Thanks and Regards
> Pramod
No I don't take any offense, I am very rusty with kernel code haven't
touched it in like 2 years.
If you want to me to learn through just answer my questions and I will learn.
Regards Nick

Delivery Status Notification (Failure)

[Valdis.Kletnieks at vt.edu]

On Thu, 07 Aug 2014 13:14:42 -0400, Nick Krause said:

> No I don't take any offense, I am very rusty with kernel code haven't
> touched it in like 2 years.

Excuse me if I'm dubious. Yesterday you said:

On Wed, 06 Aug 2014 18:11:30 -0400, Nick Krause said:
> I am new to kernel programming and have a lot  questions about this
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140807/40308ef5/attachment.bin 

Delivery Status Notification (Failure)

[Nick Krause]

On Thu, Aug 7, 2014 at 4:11 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 07 Aug 2014 13:14:42 -0400, Nick Krause said:
>
>> No I don't take any offense, I am very rusty with kernel code haven't
>> touched it in like 2 years.
>
> Excuse me if I'm dubious. Yesterday you said:
>
> On Wed, 06 Aug 2014 18:11:30 -0400, Nick Krause said:
>> I am new to kernel programming and have a lot  questions about this
What I meant to state was I never tried to do it more then on my own and
didn't do much mostly tracing and reading code.
Nick

Sysfs requirement for running generic_buffer.c application - IIO sensors

[s.rawat]

I have two system having different kernel version and drivers(IIO) on which
i can run the generic_buffer.c application .On one system it works fine but
on the other it does not give the input reports data.

I have checked that the system on which it is working has the following
sysfs under /sys/bus/iio/devices/iio:deviceX (where X is 1,2,3...)

buffer
dev
in_accel_hysteresis
in_accel_offset
in_accel_sampling_frequency
in_accel_scale
*in_accel_x_raw*

*in_accel_y_raw*
*in_accel_z_raw*
name
power
scan_elements
subsystem
trigger
uevent

This is for accelerometer similiarly for magnetometer
(in_magn_x_raw,_y_raw,z_raw etc) and for Gyrometer (
in_anglvel_x_raw,in_anglvel_y_raw,in_anglvel_z_raw )



and the one on which it is not working has the below sysfs under
/sys/bus/iio/devices/iio:deviceX (where X is 1,2,3...) :

buffer
dev
in_accel_hysteresis
in_accel_offset
in_accel_sampling_frequency
in_accel_scale
name
power
scan_elements
subsystem
trigger
uevent



Is the missing _x_raw,_y_raw and _z_raw component main reason for not
working of the app,.Where I can enable them in the driver?



Thanks and Rgds,
Saurabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150323/d3d8beb2/attachment.html 

Delivery Status Notification (Failure)

[s.rawat]

More over  I also found that :
scan_elements/in_*_x_en has value = -1 instead of 0 or 1 .Could this be the
cause for this?
Thanks and Rgds,
Saurabh

On Mon, Mar 23, 2015 at 10:58 AM, Mail Delivery Subsystem <
mailer-daemon@googlemail.com> wrote:

> Delivery to the following recipient failed permanently:
>
>      linux-iio at vger.kernel.org
>
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the server
> for the recipient domain vger.kernel.org by vger.kernel.org.
> [209.132.180.67].
>
> The error that the other server returned was:
> 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart,
> therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN is accepted.!
> BF:<H 0.340883>; S1752369AbbCWF2O
>
>
> ----- Original message -----
>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=gmail.com; s=20120113;
>         h=mime-version:from:date:message-id:subject:to:content-type;
>         bh=W+21xGol3QXRz/AvvkDAa++sfkPFzpaeG7bCHFWwCK4=;
>
> b=W24U0Vx1L94eBofJD/jfz8XA3wklJQcDDewTbOXPXQBBOJBuZQv4Q2SQ2FCVzBtcx0
>
>  bbyECGWi5OwG3CZkW/bk7Z8lHbhbkiwNAzVZk9k3/RTxPWjIQT9kxVesJckBy6dq9lr2
>
>  C/if1bV0EYyKYAuB1QPp+k+srcrfRrfawkz87nGEFu147Ocnn/ilMcBVuQLegjVZRC0Y
>
>  4AVXRtzIurvk7zOekGldYbgHGiRy+iHitSwXAtbN6pTc1bpG1dniN29ErGIq6dBcqBNI
>
>  A4RDC+9A85CEezW1rTdSz4BYvFOE5UhfeDwGfy4nRKwdw38MhBiyDmDTLb5x1KqNrK/x
>          0H7w==
> X-Received: by 10.55.22.213 with SMTP id
> 82mr135607224qkw.103.1427088493423;
>  Sun, 22 Mar 2015 22:28:13 -0700 (PDT)
> MIME-Version: 1.0
> Received: by 10.140.157.148 with HTTP; Sun, 22 Mar 2015 22:27:52 -0700
> (PDT)
> From: "s.rawat" <imsaurabhrawat@gmail.com>
> Date: Mon, 23 Mar 2015 10:57:52 +0530
> Message-ID: <CALwa49u4s7qqBUbV8FUU=
> 3dFJczEkzQwXZAEhakxGY1Xay-8iA at mail.gmail.com>
> Subject: Sysfs requirement for running generic_buffer.c application - IIO
> sensors
> To: kernelnewbies <kernelnewbies@kernelnewbies.org>,
>         "linux-iio at vger.kernel.org" <linux-iio@vger.kernel.org>
> Content-Type: multipart/alternative; boundary=001a114904d6b6b16e0511edee04
>
> I have two system having different kernel version and drivers(IIO) on which
> i can run the generic_buffer.c application .On one system it works fine but
> on the other it does not give the input reports data.
>
> I have checked that the system on which it is working has the following
> sysfs under /sys/bus/iio/devices/iio:deviceX (where X is 1,2,3...)
>
> buffer
> dev
> in_accel_hysteresis
> in_accel_offset
> in_accel_sampling_frequency
> in_accel_scale
> *in_accel_x_raw*
>
> *in_accel_y_raw*
> *in_accel_z_raw*
> name
> power
> scan_elements
> subsystem
> trigger
> uevent
>
> This is for accelerometer similiarly for magnetometer
> (in_magn_x_raw,_y_raw,z_raw etc) and for Gyrometer (
> in_anglvel_x_raw,in_anglvel_y_raw,in_anglvel_z_raw )
>
>
>
> and the one on which it is not working has the below sysfs under
> /sys/bus/iio/devices/iio:deviceX (where X is 1,2,3...) :
>
> buffer
> dev
> in_accel_hysteresis
> in_accel_offset
> in_accel_sampling_frequency
> in_accel_scale
> name
> power
> scan_elements
> subsystem
> trigger
> uevent
>
>
>
> Is the missing _x_raw,_y_raw and _z_raw component main reason for not
> working of the app,.Where I can enable them in the driver?
>
>
>
> Thanks and Rgds,
> Saurabh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150323/bc7a4a4c/attachment.html 

Not able to set smp_affinity for an IRQ on i.MX7

[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 at 10:~# echo 21 > /sys/class/gpio/export
root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
root at 10:~# cat /proc/interrupts | grep 21
  47: 0 0 gpio-mxc 21 Edge gpiolib
root at 10:~# cat /sys/class/gpio/gpio21/direction
in
root at 10:~# cat /proc/irq/47/smp_affinity
3
root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1, irq_data.chip:
a81b7e48, irq_set_affinity:   (null)
[    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
root at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180511/a55f3961/attachment.html>

Delivery Status Notification (Failure)

[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 at 10:~# echo 21 > /sys/class/gpio/export
root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
root at 10:~# cat /proc/interrupts | grep 21
  47: 0 0 gpio-mxc 21 Edge gpiolib
root at 10:~# cat /sys/class/gpio/gpio21/direction
in
root at 10:~# cat /proc/irq/47/smp_affinity
3
root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
irq_data.chip: a81b7e48, irq_set_affinity:   (null)
[    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
root at 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)

[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 at 10:~# echo 21 > /sys/class/gpio/export
> > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > root at 10:~# cat /proc/interrupts | grep 21
> >   47: 0 0 gpio-mxc 21 Edge gpiolib
> > root at 10:~# cat /sys/class/gpio/gpio21/direction
> > in
> > root at 10:~# cat /proc/irq/47/smp_affinity
> > 3
> > root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> > [    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
> > root at 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

Delivery Status Notification (Failure)

[Pintu Kumar]

On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.de> 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 at 10:~# echo 21 > /sys/class/gpio/export
>> > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > root at 10:~# cat /proc/interrupts | grep 21
>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > root at 10:~# cat /sys/class/gpio/gpio21/direction
>> > in
>> > root at 10:~# cat /proc/irq/47/smp_affinity
>> > 3
>> > root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > [    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
>> > root at 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

Delivery Status Notification (Failure)

[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 <pintu.ping@gmail.com> wrote:
> On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.de> 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 at 10:~# echo 21 > /sys/class/gpio/export
>>> > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>>> > root at 10:~# cat /proc/interrupts | grep 21
>>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>>> > root at 10:~# cat /sys/class/gpio/gpio21/direction
>>> > in
>>> > root at 10:~# cat /proc/irq/47/smp_affinity
>>> > 3
>>> > root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
>>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>>> > [    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
>>> > root at 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

Delivery Status Notification (Failure)

[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 <pintu.ping@gmail.com>
> wrote:
> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
> > 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 at 10:~# echo 21 > /sys/class/gpio/export
> > > > > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > > > > root at 10:~# cat /proc/interrupts | grep 21
> > > > > ? 47: 0 0 gpio-mxc 21 Edge gpiolib
> > > > > root at 10:~# cat /sys/class/gpio/gpio21/direction
> > > > > in
> > > > > root at 10:~# cat /proc/irq/47/smp_affinity
> > > > > 3
> > > > > root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
> > > > > irq_data.chip: a81b7e48, irq_set_affinity:???(null)
> > > > > [????0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
> > > > > root at 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

Delivery Status Notification (Failure)

[Pintu Kumar]

On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.stach@pengutronix.de> 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 <pintu.ping@gmail.com>
>> wrote:
>> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
>> > 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 at 10:~# echo 21 > /sys/class/gpio/export
>> > > > > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > > > > root at 10:~# cat /proc/interrupts | grep 21
>> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > > > > root at 10:~# cat /sys/class/gpio/gpio21/direction
>> > > > > in
>> > > > > root at 10:~# cat /proc/irq/47/smp_affinity
>> > > > > 3
>> > > > > root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
>> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > > > > [    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
>> > > > > root at 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

Delivery Status Notification (Failure)

[Pintu Kumar]

On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>
> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.stach@pengutronix.de> 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 <pintu.ping@gmail.com>
> >> wrote:
> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
> >> > 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 at 10:~# echo 21 > /sys/class/gpio/export
> >> > > > > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> >> > > > > root at 10:~# cat /proc/interrupts | grep 21
> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> >> > > > > root at 10:~# cat /sys/class/gpio/gpio21/direction
> >> > > > > in
> >> > > > > root at 10:~# cat /proc/irq/47/smp_affinity
> >> > > > > 3
> >> > > > > root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> >> > > > > [    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
> >> > > > > root at 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

Delivery Status Notification (Failure)

[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 <pintu.ping@gmail.com> wrote:
> On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>>
>> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.stach@pengutronix.de> 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 <pintu.ping@gmail.com>
>> >> wrote:
>> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
>> >> > 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 at 10:~# echo 21 > /sys/class/gpio/export
>> >> > > > > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> >> > > > > root at 10:~# cat /proc/interrupts | grep 21
>> >> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> >> > > > > root at 10:~# cat /sys/class/gpio/gpio21/direction
>> >> > > > > in
>> >> > > > > root at 10:~# cat /proc/irq/47/smp_affinity
>> >> > > > > 3
>> >> > > > > root at 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.000000] genirq: irq_can_set_affinity (0): balance: 1,
>> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> >> > > > > [    0.000000] 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 at 10:~# echo 2 > /proc/irq/295/smp_affinity
>> >> > > > > root at 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