April 2015 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Re: Question about shared interrupts in devicetree
by Stefan Wahren April 9, 2015

April 9, 2015

Hi Geert, Am 08.04.2015 um 21:20 schrieb Geert Uytterhoeven: > On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren(a)i2se.com> wrote: >> [...] >> >> thanks for the good explanation. After looking into the reference manual [1] of >> the i.MX28 i still can't decide if the subsystem generate the interrupts as a >> whole or >> as a logical group. I only found this para in chapter 11.11: >> >> The VDDA_BO_IRQ, VDDD_BO_IRQ, VDDIO_BO_IRQ, and BATT_BO_IRQ each >> have their own interrupt line back to the interrupt collector. >> However, the remaining five interrupts—VDD5V_GT_VDDIO_IRQ, DC_OK_IRQ, >> VBUSVALID_IRQ, LINREG_OK_IRQ and PSWITCH_IRQ—all share a single >> interrupt line. In this case, software must read the interrupt status >> bits to discover which event caused the interrupt. >> >> In my case DC_OK_IRQ and PSWITCH_IRQ are relevant. >> >> Maybe someone else has a idea? > Perhaps you can implement an interrupt-controller to handle the multiplexing > of the 5 remaining interrupts? Could you please explain the benefit / reason of this approach? > > Can they be disabled/enabled individually? Yes. What are the consequences? Thanks Stefan > >> Thanks Stefan >> >> [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf >> >> Document Number: MCIMX28RM >> Rev 2, 08/2013 >> >> > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds

2 1

Re: Spoon feeding
by Nicholas Krause April 9, 2015

April 9, 2015

On April 8, 2015 11:18:13 PM EDT, Chinmay V S <cvs268(a)gmail.com> wrote: >Spoon-feeding = Actually explaining to you now what "spoon-feeding" >means. > I know what it means however whenever I ask a question, I always get the response do more research. I am wondering if this is due to a lack of effort on my part or a misunderstanding that I am putting in time but my questions are too open ended. Ni5 >On Thu, Apr 9, 2015 at 8:45 AM, Nicholas Krause <xerofoify(a)gmail.com> >wrote: > >> Greetings All, >> After thinking for a few days I have come to the conclusion that the >> communities definition of spoon feeding and my are different. If >someone >> would like to give me the community definition so there is no more >> misunderstandings and time wasting that would be great. >> Nick >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies(a)kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

2 1

pci devices
by A B April 9, 2015

April 9, 2015

Hi, One of my pci device is not showing up in /proc/pci/bus/devices. I'm using 2.6.36 kernel. which part of code i can look to troubleshoot, i'm looking at drivers/pci/probe.c. Any pointers / tips will be helpful

2 1

Re: Question about shared interrupts in devicetree
by Stefan Wahren April 8, 2015

April 8, 2015

Hi Mark, [add some possible interested developer in CC] > Mark Rutland <mark.rutland(a)arm.com> hat am 7. April 2015 um 13:29 geschrieben: > > > On Sat, Apr 04, 2015 at 10:40:13PM +0100, Stefan Wahren wrote: > > Hi, > > Hi, > > > i'm currently working on drivers (regulator and power switch) for a power > > subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts for > > the > > power subsystem which share the same interrupt line. This interrupt line is > > needed by both drivers (regulator and power switch). > > > > Now the question what is the right way (tm) to specify the interrupt in the > > devicetree and fetch the irq number during driver probe? > > If the interrupts are generated by the subsystem as a whole, then A > would be more correct. If you can read some shared register to determine > the particular sub-block which generated the interrupt, A would > certainly be the right way of describing the HW. > > If the subsystem is just a logical grouping, and the two units generate > separate interrupts which simply get muxed together (with nothing > special done at the subsystem level), then B would seem more correct, as > the two units are effectively independent. > > It really depends on way the HW is organised, and how the HW _could_ be > organised if reused, so this is a grey area generally. > > It looks like it would be possible to support both styles if we need to > (by checking the node first, then its parent), if we go for one option > and later discover we need the other. thanks for the good explanation. After looking into the reference manual [1] of the i.MX28 i still can't decide if the subsystem generate the interrupts as a whole or as a logical group. I only found this para in chapter 11.11: The VDDA_BO_IRQ, VDDD_BO_IRQ, VDDIO_BO_IRQ, and BATT_BO_IRQ each have their own interrupt line back to the interrupt collector. However, the remaining five interrupts—VDD5V_GT_VDDIO_IRQ, DC_OK_IRQ, VBUSVALID_IRQ, LINREG_OK_IRQ and PSWITCH_IRQ—all share a single interrupt line. In this case, software must read the interrupt status bits to discover which event caused the interrupt. In my case DC_OK_IRQ and PSWITCH_IRQ are relevant. Maybe someone else has a idea? Thanks Stefan [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf Document Number: MCIMX28RM Rev 2, 08/2013 > > Thanks, > Mark. > > > > > Option A (define interrupt in parent node): > > > > power: power@80044000 { > > compatible = "fsl,imx28-power", "syscon"; > > reg = <0x80044000 0x2000>; > > interrupts = <6>; > > > > reg_vddd: regulator@1 { > > compatible = "fsl,imx28-vddd"; > > }; > > > > pswitch: pswitch@5 { > > compatible = "fsl,mxs-pswitch"; > > linux,code = <116>; > > }; > > } > > > > int irq = irq_of_parse_and_map(parent, 0); > > > > Option B (define interrupt for each child node): > > > > power: power@80044000 { > > compatible = "fsl,imx28-power", "syscon"; > > reg = <0x80044000 0x2000>; > > > > reg_vddd: regulator@1 { > > compatible = "fsl,imx28-vddd"; > > interrupts = <6>; > > }; > > > > pswitch: pswitch@5 { > > compatible = "fsl,mxs-pswitch"; > > linux,code = <116>; > > interrupts = <6>; > > }; > > } > > > > int irq = platform_get_irq(pdev, 0); > > > > Best regards > > Stefan > > -- > > To unsubscribe from this list: send the line "unsubscribe devicetree" in > > the body of a message to majordomo(a)vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > >

2 1

[milton@krutt.org: Re: Delaying an interrupt handler]
by Milton Krutt April 8, 2015

April 8, 2015

----- Forwarded message from Milton Krutt <milton(a)krutt.org> ----- Date: Tue, 7 Apr 2015 18:46:46 +0200 From: Milton Krutt <milton(a)krutt.org> To: Malte Vesper <malte.vesper(a)postgrad.manchester.ac.uk> Subject: Re: Delaying an interrupt handler Not that late! I take your advice, and I inform all the folks who suggested me to jump on a new kernel that now I am on a 3.19! So their hints are still welcome. Bye > Despite beeing fairly late, take a look at threaded interrupt > handlers, they might help you. You will handle the interrupt fast > but you can delay doing the actual work. In the threaded part of the > interrupt handler you can sleep and thus use semaphores. > > hope it is still useful ----- End forwarded message -----

1 0

Out of openat flag space
by David Legault April 8, 2015

April 8, 2015

Hello, Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there is no space left to add more flags since the flags variable is a 32 bit int. How does one resolve this issue and extend this? A new syscall with a 64bit wide flags support? http://www.spinics.net/lists/fstests/msg01064.html Thanks David

5 9

cross-compiling kernel using a 32-bit toolchain on a 64-bit machine
by Mandeep Sandhu April 7, 2015

April 7, 2015

Hi All, I'm having trouble compiling my kernel using a 32-bit toolchain (for ARM) on a 64-bit host (Ubuntu 14.10). The kernel version is 3.14.17. I understand that 32-bit binaries require "ia32-libs" (or equivalent) for compiling on 64-bit hosts. I installed the required packages (lib32z1 lib32ncurses5 lib32bz2-1.0 for Ubuntu 14.10), but still keep getting errors: $ make CROSS_COMPILE=arm-none-linux-gnueabi- all Makefile:616: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler make: arm-none-linux-gnueabi-gcc: Command not found CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CC kernel/bounds.s /bin/sh: 1: arm-none-linux-gnueabi-gcc: not found make[1]: *** [kernel/bounds.s] Error 127 make: *** [prepare0] Error 2 I've ensured that the PATH to the toolchain binaries is correct. If I try to export CROSS_COMPILE to my environment, then too I get an error (although it's for a different reason): $ make all Makefile:616: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CC kernel/bounds.s gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’ gcc: note: valid arguments to ‘-mabi=’ are: ms sysv gcc: error: unrecognized command line option ‘-mlittle-endian’ gcc: error: unrecognized command line option ‘-mapcs’ gcc: error: unrecognized command line option ‘-mno-sched-prolog’ gcc: error: unrecognized command line option ‘-mno-thumb-interwork’ gcc: error: unrecognized command line option ‘-mfpu=vfp’ make[1]: *** [kernel/bounds.s] Error 1 make: *** [prepare0] Error 2 It looks like make is starting a new shell which does not have either PATH (1st case) or CROSS_COMPILE (2nd case) set. Any hints on how to get make to use the toolchain? Thanks, -mandeep

4 6

VFS/driver core overhead
by nick April 7, 2015

April 7, 2015

Greetings All, After reading through the code for the usb and vfs core infrastructure, I was wondering if after reading it if I am correct in my notion of there being very little overhead or none at all int these areas of the kernel. This is due to be noticing most drivers and file systems wrap around the core/vfs and therefore the overhead is very little and no need to worry about it like the overhead of the kernel's process structures based off task_struct .Honestly, I could benchmark this area of the kernel but it's hard to remove the file system/drivers interfering with my benchmarks due to me not knowing of any one way to do that. If someone either points me to a benchmark for me to test this or answers it that would be very helpful. Thanks, Nick

2 1

Learning things
by Joris Bolsens April 7, 2015

April 7, 2015

Hey list, I'm working on trying to teach myself C and was wondering if you had any kernel specific recommendations. I started the eudyptula challenge but so far it seems to be mostly learning the standards and whatnot. Are there any kernel/C books or online tutorials you guys think would help?

8 10

scull_init_module() in scull driver
by Rock Lee April 7, 2015

April 7, 2015

Hi, guys: I am reading function scull_init_module() in scull driver.I found that scull_init_module() doesn't check scull_setup_cdev()'s return value.If there will be a probem when scull_setup_cdev() failed, and then, others call scull_cleanup_module()? for (i = 0; i < scull_nr_devs; i++) { scull_devices[i].quantum = scull_quantum; scull_devices[i].qset = scull_qset; init_MUTEX(&scull_devices[i].sem); scull_setup_cdev(&scull_devices[i], i); } Best Regard ---- Rock Lee

1 0