* Fwd: Kernelnewbies Digest, Vol 52, Issue 41
[not found] <mailman.1.1427126403.3844.kernelnewbies@kernelnewbies.org>
@ 2015-03-24 8:23 ` Vishwas Srivastava
2015-03-24 8:43 ` Kernel Apprentice
0 siblings, 1 reply; 2+ messages in thread
From: Vishwas Srivastava @ 2015-03-24 8:23 UTC (permalink / raw)
To: kernelnewbies
---------- Forwarded message ----------
From: <kernelnewbies-request@kernelnewbies.org>
Date: Mon, Mar 23, 2015 at 9:30 PM
Subject: Kernelnewbies Digest, Vol 52, Issue 41
To: kernelnewbies at kernelnewbies.org
Send Kernelnewbies mailing list submissions to
kernelnewbies at kernelnewbies.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
or, via email, send a message with subject or body 'help' to
kernelnewbies-request at kernelnewbies.org
You can reach the person managing the list at
kernelnewbies-owner at kernelnewbies.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Kernelnewbies digest..."
Today's Topics:
1. Re: Delaying an interrupt handler (Daniel Baluta)
2. Re: Sysfs requirement for running generic_buffer.c
application - IIO sensors (Daniel Baluta)
3. Re: Delaying an interrupt handler (Milton Krutt)
4. Re: Get Back Into Kernel Work (el_es)
5. Re: Sysfs requirement for running generic_buffer.c
application - IIO sensors (s.rawat)
6. Re: Get Back Into Kernel Work (Nicholas Krause)
7. Re: Writing driver for a net device which does not support
interrupt (Valdis.Kletnieks at vt.edu)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Mar 2015 14:46:51 +0200
From: Daniel Baluta <daniel.baluta@gmail.com>
Subject: Re: Delaying an interrupt handler
To: Milton Krutt <milton@krutt.org>
Cc: Kernelnewbies <kernelnewbies@kernelnewbies.org>
Message-ID:
<CAEnQRZDQrnNjxKtDSqmmA+QFHYJbXoWWE=cHEPVE7LOLHA31Uw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt <milton@krutt.org> wrote:
> Hi.
> It is known that no semaphore synchronization should be
> used inside an interrupt handler.
>
> Anyway, I am looking at a freeBSD device driver (written by
> a profesionist) and there are semaphores inside an interrupt
> handler's subroutine.
>
> Since I should port to linux that driver, I ask you how can I
> reach such synchronization under linux; I tried to use semaphores
> inside my handler but I got complains, and I don't want to break
> the law, so no semaphores for me.
Perhaps spinlocks could be the solution :).
2.6.10 please no - :), Linux kernel is now at 4.0.
Daniel.
Hi Daniel,
Its us legitimate to use semaphore inside the interrupt
handler but the only thing what should not be done is to _acquire_ it from
within. Releasing is perfectly all right.
By the way what is done within the interrupt handler in the code written by
professional? release ?? acquire??
Vishwas
------------------------------
Message: 2
Date: Mon, 23 Mar 2015 15:40:39 +0200
From: Daniel Baluta <daniel.baluta@gmail.com>
Subject: Re: Sysfs requirement for running generic_buffer.c
application - IIO sensors
To: "s.rawat" <imsaurabhrawat@gmail.com>
Cc: "linux-iio at vger.kernel.org" <linux-iio@vger.kernel.org>,
kernelnewbies <kernelnewbies@kernelnewbies.org>
Message-ID:
<CAEnQRZDmYTzZPyMiO=0SMo=d1k3s_Dj-T7u7Jw696dz1c5uRJA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Mar 23, 2015 at 7:27 AM, s.rawat <imsaurabhrawat@gmail.com> wrote:
> 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.
What kernel versions are you using? Why are you using different drivers? :D
thanks,
Daniel.
------------------------------
Message: 3
Date: Mon, 23 Mar 2015 06:46:23 -0700
From: Milton Krutt <milton@krutt.org>
Subject: Re: Delaying an interrupt handler
To: kernelnewbies at kernelnewbies.org
Message-ID: <20150323134622.GA4933@debian>
Content-Type: text/plain; charset=us-ascii
> On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt <milton@krutt.org> wrote:
> > Hi.
> > It is known that no semaphore synchronization should be
> > used inside an interrupt handler.
> >
> > Anyway, I am looking at a freeBSD device driver (written by
> > a profesionist) and there are semaphores inside an interrupt
> > handler's subroutine.
> >
> > Since I should port to linux that driver, I ask you how can I
> > reach such synchronization under linux; I tried to use semaphores
> > inside my handler but I got complains, and I don't want to break
> > the law, so no semaphores for me.
>
> Perhaps spinlocks could be the solution :).
>
> 2.6.10 please no - :), Linux kernel is now at 4.0.
>
> Daniel.
Yes and no. The routine the int. handler's delay depends on has to
make some non atomic work. So if I lock a spinlock and then I do some
"lengthy" (i.e. non atomic) job, then I get a warning message like
"spinlock held while being preempted" (or similar). In symbols, you suggest
something like
process P{
spin_lock(lock);
non_atomic_function();
spin_unlock(lock);
}
int. handler {
spin_lock(lock);
do_things(); /* preferably atomically */
spin_unlock(lock);
}
My first attempt is still to avoid both semaphores and the above remedy,
in order to delay the int. handler up to a desired point.
Thanks!
------------------------------
Message: 4
Date: Mon, 23 Mar 2015 13:51:30 +0000 (UTC)
From: el_es <el.es.cr@gmail.com>
Subject: Re: Get Back Into Kernel Work
To: kernelnewbies at kernelnewbies.org
Message-ID: <loom.20150323T144133-770@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
Nicholas Krause <xerofoify <at> gmail.com> writes:
>
> I have listened to peoples feedback. Am I still missing something
> as I now do
> 1. Build test all patches
> 2. Reading the code properly
> 3.Testing my patches
> 4.Listening to feedback
> Nick
>
[trim]
Insert this:
X. Do My Own Research First, THEN ask questions
preferably at X = 0, 2, 4, 6, 8 of the above list.
Read a few netiquette/'how to write questions smart' manuals
to learn how to let people /know/ you did your research.
If your school work gets in the way though,
it probably means it's much more important and you
should not miss it.
Cheers,
CHSMBIDWT/MSPANC.
el es
------------------------------
Message: 5
Date: Mon, 23 Mar 2015 20:22:30 +0530
From: "s.rawat" <imsaurabhrawat@gmail.com>
Subject: Re: Sysfs requirement for running generic_buffer.c
application - IIO sensors
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: "linux-iio at vger.kernel.org" <linux-iio@vger.kernel.org>,
kernelnewbies <kernelnewbies@kernelnewbies.org>
Message-ID:
<CALwa49t7WB_KhE5o7d=B3vJXwd+=ctwU0_Rv6j93uHK5665F0A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
kernel version is 3.10.20 ,
drivers are hid-sensor-* driver. (hid-accel-3d,hid-gyro-3d,etc.) for
different sensors.I have two different devices having two different
kernels,Just wanted to know the difference technically why one is not
working.
On Mon, Mar 23, 2015 at 7:10 PM, Daniel Baluta <daniel.baluta@gmail.com>
wrote:
> On Mon, Mar 23, 2015 at 7:27 AM, s.rawat <imsaurabhrawat@gmail.com> wrote:
> > 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.
>
> What kernel versions are you using? Why are you using different drivers?
:D
>
> thanks,
> Daniel.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150323/13fdc553/attachment-0001.html
------------------------------
Message: 6
Date: Mon, 23 Mar 2015 11:04:57 -0400
From: Nicholas Krause <xerofoify@gmail.com>
Subject: Re: Get Back Into Kernel Work
To: el_es <el.es.cr@gmail.com>,kernelnewbies at kernelnewbies.org
Message-ID: <083A04E5-C995-425F-A4F8-ED164A87827A@gmail.com>
Content-Type: text/plain; charset=UTF-8
On March 23, 2015 9:51:30 AM EDT, el_es <el.es.cr@gmail.com> wrote:
>Nicholas Krause <xerofoify <at> gmail.com> writes:
>
>>
>> I have listened to peoples feedback. Am I still missing something
>> as I now do
>> 1. Build test all patches
>> 2. Reading the code properly
>> 3.Testing my patches
>> 4.Listening to feedback
>> Nick
>>
>[trim]
>
>Insert this:
>
>X. Do My Own Research First, THEN ask questions
>
>preferably at X = 0, 2, 4, 6, 8 of the above list.
>
>Read a few netiquette/'how to write questions smart' manuals
>to learn how to let people /know/ you did your research.
>
>If your school work gets in the way though,
>it probably means it's much more important and you
>should not miss it.
>
>Cheers,
>
>CHSMBIDWT/MSPANC.
>
>el es
>
>
That makes sense and I am doing my own research now. Furthermore I am
able to handle my school work in top of kernel programming.
Nick
>_______________________________________________
>Kernelnewbies mailing list
>Kernelnewbies at kernelnewbies.org
>http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------------------------------
Message: 7
Date: Mon, 23 Mar 2015 11:51:45 -0400
From: Valdis.Kletnieks@vt.edu
Subject: Re: Writing driver for a net device which does not support
interrupt
To: Freeman Zhang <freeman.zhang1992@gmail.com>
Cc: Kernel Newbies <kernelnewbies@kernelnewbies.org>
Message-ID: <53058.1427125905@turing-police.cc.vt.edu>
Content-Type: text/plain; charset="us-ascii"
On Mon, 23 Mar 2015 18:51:51 +0800, Freeman Zhang said:
> I'm writing a net device driver for my final project in college. But the
> half-finished device doesn't support interrupt yet(those hardware guys...)
>
> So I'm wondering if there is some way to poll the device for its status
> and events.
As a realistic datapoint - if it still doesn't support interrupts, the
*rest*
of it is probably still so buggy that trying to write a driver isn't worth
the effort.
It's doable if you are working with a group of talented and experienced
engineers - but if the hardware is also being done as a final project,
you're in for naught but misery.
You *could* do something like this:
while (waiting) {
status = read_status_bits(your_device);
if (status & DATA_AVAIL_MASK) break;
msleep(100);
}
But having seen enough student hardware design projects in my life, I
estimate
that if it still can't signal interrupts, the status bits probably aren't
valid
either. (Think about it - a bog-simple implementation of interrupts would be
to just feed a transition-high on the appropriate status bit to the
interrupt
pin, and use a read from the chip to clear the pin).
Good luck - I suspect you're going to need it....
-------------- 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/20150323/d9f1295d/attachment-0001.bin
------------------------------
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
End of Kernelnewbies Digest, Vol 52, Issue 41
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150324/9711f615/attachment-0001.html
^ permalink raw reply [flat|nested] 2+ messages in thread