Hi all, I want to contribute to camera dri*vers in linux kernel*.Please guide me the procedure of doing that.
Regards, Mayank On Tue, Feb 7, 2012 at 10:30 PM, <[email protected]>wrote: > Send Kernelnewbies mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Kernelnewbies digest..." > > > Today's Topics: > > 1. Re: "Trying to free already-free IRQ 9", but it wasn't freed > by me (mayur nande) > 2. Re: request_firmware question (Greg KH) > 3. Re: fork() and exec() (Bernd Petrovitsch) > 4. Re: make config errors while building kernel on Fedora 16 > (Kartik Singhal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 7 Feb 2012 20:33:31 +0530 > From: mayur nande <[email protected]> > Subject: Re: "Trying to free already-free IRQ 9", but it wasn't freed > by me > To: "nils.stec" <[email protected]> > Cc: kernelnewbies <[email protected]> > Message-ID: > <ca+fm3xy2qalrjbtyjxw0ykn-q-y99wi8xuyywtkezydtbyt...@mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nils, > > >>void cleanup_module(void) { > >> ... > >> free_irq(ADC_IRQ, NULL); /* remove interrupt handler */ > >> ... > >> return; > >>} > > You should not pass NULL here. It should be the unique cookie that you > passed in request_irq (adc_irq_handler in your case) since you have used > IRQF_SHARED which means you want to share your interrupt line. Also check > whether you really want to share your interrupt line and also if you want > to use "(void *)(adc_irq_handler)" as the unique identification. > > HTH! > > Regards > Mayur > > On Tue, Feb 7, 2012 at 7:45 PM, nils.stec <[email protected]> > wrote: > > > Hi, > > > > atm I'm writing a kernel module for an embedded ARM device. > > This module uses IRQ9. > > > > If i remove the module, the kernel tells me that: > > > > ------------[ cut here ]------------ > > WARNING: at kernel/irq/manage.c:858 __free_irq+0x84/0x154() > > Trying to free already-free IRQ 9 > > Modules linked in: adc_demo_irq(P-) g_ether pegasus mii > > [<c0028794>] (unwind_backtrace+0x0/0xd0) from [<c003b504>] > > (warn_slowpath_common+0x48/0x60) > > [<c003b504>] (warn_slowpath_common+0x48/0x60) from [<c003b554>] > > (warn_slowpath_fmt+0x24/0x30) > > [<c003b554>] (warn_slowpath_fmt+0x24/0x30) from [<c005fa00>] > > (__free_irq+0x84/0x154) > > [<c005fa00>] (__free_irq+0x84/0x154) from [<c005fb0c>] > > (free_irq+0x3c/0x5c) > > [<c005fb0c>] (free_irq+0x3c/0x5c) from [<bf01e18c>] > > (cleanup_module+0x4c/0x60 [adc_demo_irq]) > > [<bf01e18c>] (cleanup_module+0x4c/0x60 [adc_demo_irq]) from [<c005b898>] > > (sys_delete_module+0x1c4/0x238) > > [<c005b898>] (sys_delete_module+0x1c4/0x238) from [<c0022dc0>] > > (ret_fast_syscall+0x0/0x28) > > ---[ end trace 60d7a16d878ac0b3 ]--- > > adc testing module removed > > ------------[ cut here ]------------ > > > > The message "adc testing module removed" comes from my module > **after**free_irq() via printk, so the module exit routine works till the > end. > > > > This is my code (only the IRQ related part): > > > > irqreturn_t adc_irq_handler(int irq, void *dev_id) { > > > > ... do someting ... > > > > return IRQ_HANDLED; > > } > > > > int init_module(void) { > > int32_t retval; > > ... > > retval = request_irq(ADC_IRQ, adc_irq_handler, IRQF_SHARED, "lpc313x > > adc irq", (void *)(adc_irq_handler)); > > ... > > return retval; > > } > > > > void cleanup_module(void) { > > ... > > free_irq(ADC_IRQ, NULL); /* remove interrupt handler */ > > ... > > return; > > } > > > > > > I hope anyone of you can help me with that problem. If you need more > > information, i'll send it > > > > Greetings, > > Nils > > > > _______________________________________________ > > Kernelnewbies mailing list > > [email protected] > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120207/79cf9412/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Tue, 7 Feb 2012 07:07:50 -0800 > From: Greg KH <[email protected]> > Subject: Re: request_firmware question > To: anish kumar <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Tue, Feb 07, 2012 at 12:51:42AM -0800, anish kumar wrote: > > Hi, > > > > Now I have switched to using request_firmware api > > and after using firmware, memory is being released. > > Does it save kernel memory compare to case when > > I am having a having a local static firmware buffer(very big) > > from which I used to get the firmware and write it > > to the chip? > > > > As I know request_firmware api has several advantages > > but what I want to know is the advantages related > > to kernel memory footprint. > > Yes it is, as well as using the "proper" api for firmware loading, which > means it fits into the rest of the kernel correctly. > > Also, no new drivers will be accepted that have static firmware blobs. > > greg k-h > > > > ------------------------------ > > Message: 3 > Date: Tue, 07 Feb 2012 16:40:13 +0100 > From: Bernd Petrovitsch <[email protected]> > Subject: Re: fork() and exec() > To: Vijay Chauhan <[email protected]> > Cc: [email protected] > Message-ID: <1328629213.25984.123.camel@thorin> > Content-Type: text/plain; charset="UTF-8" > > On Die, 2012-02-07 at 00:38 +0530, Vijay Chauhan wrote: > > Hi List, > > > > I am learning Linux and trying to understand exec and fork function. > > execl says that it overlays the running address space. What does it mean? > > > > I created the following program and used top command with > > intentionally wrong arguments: > > > > #include<stdio.h> > > #include<unistd.h> > > #include<sys/types.h> > > #include<stdlib.h> > > > > int main(){ > > int a = -1; > > if(fork()==0){ > > printf("Inside child\n"); > > printf("child pid=%d, parentid=%d\n", getpid(), getppid()); > > execl("/usr/bin/top", "/usr/bin/top", ">/dev/null" > ,(char*)0 ); > > You get here only if the execl() as such fails. > > > scanf("inside child provide a %d", &a); > > You should check the return value here if you actually got a matching > parameter. > scanf() is actually a function to be avoided. > > > printf("Inside child a=%d\n", a); > > exit(1); > > } else { > > printf("Inside parent, going to wait\n"); > > printf("my pid=%d, parentid=%d\n", getpid(), getppid()); > > scanf("input parent %d\n", &a); > > You should check the return value here if you actually got a matching > parameter. > scanf() is actually a function to be avoided. > > > wait(NULL); > > You should check the return value here to know why "wait()" returns. > > > printf("Wait over\n"); > > printf("Inside parent a=%d\n", a); > > } > > return 0; > > } > > Bernd > -- > Bernd Petrovitsch Email : [email protected] > LUGA : http://www.luga.at > > > > > ------------------------------ > > Message: 4 > Date: Tue, 7 Feb 2012 22:10:46 +0530 > From: Kartik Singhal <[email protected]> > Subject: Re: make config errors while building kernel on Fedora 16 > To: Mulyadi Santosa <[email protected]> > Cc: [email protected] > Message-ID: > <caay3td5ujymtqm5mzkbhug5bfmx0q5cobd5cowtdntdvrto...@mail.gmail.com > > > Content-Type: text/plain; charset="utf-8" > > On Mon, Feb 6, 2012 at 1:05 PM, Mulyadi Santosa > <[email protected]>wrote: > > > have you check their checksums? > > > Is there a way to verify the checksums for git clones as in my case? > > -- > Kartik > http://k4rtik.wordpress.com/ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120207/3ff99cbf/attachment-0001.html > > ------------------------------ > > _______________________________________________ > Kernelnewbies mailing list > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > End of Kernelnewbies Digest, Vol 15, Issue 12 > ********************************************* >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
