Fwd: Kernelnewbies Digest, Vol 52, Issue 41

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




---------- Forwarded message ----------
From: <kernelnewbies-request@xxxxxxxxxxxxxxxxx>
Date: Mon, Mar 23, 2015 at 9:30 PM
Subject: Kernelnewbies Digest, Vol 52, Issue 41
To: kernelnewbies@xxxxxxxxxxxxxxxxx


Send Kernelnewbies mailing list submissions to
        kernelnewbies@xxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxx

You can reach the person managing the list at
        kernelnewbies-owner@xxxxxxxxxxxxxxxxx

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@xxxxxx)


----------------------------------------------------------------------

Message: 1
Date: Mon, 23 Mar 2015 14:46:51 +0200
From: Daniel Baluta <daniel.baluta@xxxxxxxxx>
Subject: Re: Delaying an interrupt handler
To: Milton Krutt <milton@xxxxxxxxx>
Cc: Kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
        <CAEnQRZDQrnNjxKtDSqmmA+QFHYJbXoWWE=cHEPVE7LOLHA31Uw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt <milton@xxxxxxxxx> 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@xxxxxxxxx>
Subject: Re: Sysfs requirement for running generic_buffer.c
        application - IIO       sensors
To: "s.rawat" <imsaurabhrawat@xxxxxxxxx>
Cc: "linux-iio@xxxxxxxxxxxxxxx" <linux-iio@xxxxxxxxxxxxxxx>,
        kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
        <CAEnQRZDmYTzZPyMiO=0SMo=d1k3s_Dj-T7u7Jw696dz1c5uRJA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 23, 2015 at 7:27 AM, s.rawat <imsaurabhrawat@xxxxxxxxx> 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@xxxxxxxxx>
Subject: Re: Delaying an interrupt handler
To: kernelnewbies@xxxxxxxxxxxxxxxxx
Message-ID: <20150323134622.GA4933@debian>
Content-Type: text/plain; charset=us-ascii

> On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt <milton@xxxxxxxxx> 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@xxxxxxxxx>
Subject: Re: Get Back Into Kernel Work
To: kernelnewbies@xxxxxxxxxxxxxxxxx
Message-ID: <loom.20150323T144133-770@xxxxxxxxxxxxxx>
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@xxxxxxxxx>
Subject: Re: Sysfs requirement for running generic_buffer.c
        application - IIO       sensors
To: Daniel Baluta <daniel.baluta@xxxxxxxxx>
Cc: "linux-iio@xxxxxxxxxxxxxxx" <linux-iio@xxxxxxxxxxxxxxx>,
        kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
        <CALwa49t7WB_KhE5o7d=B3vJXwd+=ctwU0_Rv6j93uHK5665F0A@xxxxxxxxxxxxxx>
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@xxxxxxxxx>
wrote:

> On Mon, Mar 23, 2015 at 7:27 AM, s.rawat <imsaurabhrawat@xxxxxxxxx> 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@xxxxxxxxx>
Subject: Re: Get Back Into Kernel Work
To: el_es <el.es.cr@xxxxxxxxx>,kernelnewbies@xxxxxxxxxxxxxxxxx
Message-ID: <083A04E5-C995-425F-A4F8-ED164A87827A@xxxxxxxxx>
Content-Type: text/plain; charset=UTF-8



On March 23, 2015 9:51:30 AM EDT, el_es <el.es.cr@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
>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@xxxxxx
Subject: Re: Writing driver for a net device which does not support
        interrupt
To: Freeman Zhang <freeman.zhang1992@xxxxxxxxx>
Cc: Kernel Newbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID: <53058.1427125905@xxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


End of Kernelnewbies Digest, Vol 52, Issue 41
*********************************************

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux