Re: SOC: Zedboard: Driver question
is this Finally Working or you are facing some issues ? Regards Sanjeev Sharma On Fri, Jun 13, 2014 at 6:43 PM, Josh Cartwright jo...@eso.teric.us wrote: On Thu, Jun 12, 2014 at 04:39:25PM +0300, amit mehta wrote: We are working on a school project in which we are trying to develop a audio mixer on Zedboard (Development board from Digilent). We have developed the IP and have integrated it with the overall hardware using Programmable logic. This board has ARM core. We have a Digilent pre-configured Linux source which we cross-compiled for ARM board, device tree blob and bootloader for Zync(BOOT.BIN). The system boots fine with Linux, but now to expose the recently added hardware implementation of audio mixer, we are trying to develop the driver using the platform driver API. Currently, In our reconfigurable hardware, we have 2 channels and a mixer and we want to access those individually as some file nodes under /proc FS. The sample code is shown below: [..] It wasn't clear what your problem was, or if you were just asking for advice, but I will add one comment that will hopefully save you some debugging time: #include linux/kernel.h #include linux/module.h #include asm/uaccess.h /*Needed for copy_from_user */ #include asm/io.h /*Needed for IO Read/Write Functions */ #include linux/proc_fs.h/*Needed for Proc File System Functions */ #include linux/seq_file.h /*Needed for Sequence File Operations */ #include linux/platform_device.h/*Needed for Platform Driver Functions */ /* Define Driver Name */ #define DRIVER_NAME myiir unsigned long *base_addr; /* Vitual Base Address */ struct resource *res; /* Device Resource Structure */ unsigned long remap_size; /* Device Memory Size */ The way this driver is written, you will actually be probed three times, once per node in the device tree. The drivers' use of global state here is going to bite you. [..] static int __devinit myiir_probe(struct platform_device *pdev) { struct proc_dir_entry *myiir_proc_entry[3]; int ret = 0; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(pdev-dev, No memory resource\n); return -ENODEV; } remap_size = res-end - res-start + 1; if (!request_mem_region(res-start, remap_size, pdev-name)) { dev_err(pdev-dev, Cannot request IO\n); return -ENXIO; } base_addr = ioremap(res-start, remap_size); if (base_addr == NULL) { dev_err(pdev-dev, Couldn't ioremap memory at 0x%08lx\n, (unsigned long)res-start); ret = -ENOMEM; goto err_release_region; } [..] static const struct of_device_id myiir_of_match[] __devinitconst = { {.compatible = dglnt,myiir-audio-ch0}, {.compatible = dglnt,myiir-audio-ch1}, {.compatible = dglnt,myiir-audio-mix0}, {}, }; Are these really separate IP blocks entirely, or just multiple instances of the same IP block (perhaps with different parameters used during synthesis)? If the latter, then they should really share a compatible string that reflects the name/version of the IP block; handling which block is which channel should be done at a higher level. Good luck, Josh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: SOC: Zedboard: Driver question
On Thu, Jun 12, 2014 at 04:39:25PM +0300, amit mehta wrote: We are working on a school project in which we are trying to develop a audio mixer on Zedboard (Development board from Digilent). We have developed the IP and have integrated it with the overall hardware using Programmable logic. This board has ARM core. We have a Digilent pre-configured Linux source which we cross-compiled for ARM board, device tree blob and bootloader for Zync(BOOT.BIN). The system boots fine with Linux, but now to expose the recently added hardware implementation of audio mixer, we are trying to develop the driver using the platform driver API. Currently, In our reconfigurable hardware, we have 2 channels and a mixer and we want to access those individually as some file nodes under /proc FS. The sample code is shown below: [..] It wasn't clear what your problem was, or if you were just asking for advice, but I will add one comment that will hopefully save you some debugging time: #include linux/kernel.h #include linux/module.h #include asm/uaccess.h /*Needed for copy_from_user */ #include asm/io.h /*Needed for IO Read/Write Functions */ #include linux/proc_fs.h/*Needed for Proc File System Functions */ #include linux/seq_file.h /*Needed for Sequence File Operations */ #include linux/platform_device.h/*Needed for Platform Driver Functions */ /* Define Driver Name */ #define DRIVER_NAME myiir unsigned long *base_addr; /* Vitual Base Address */ struct resource *res; /* Device Resource Structure */ unsigned long remap_size; /* Device Memory Size */ The way this driver is written, you will actually be probed three times, once per node in the device tree. The drivers' use of global state here is going to bite you. [..] static int __devinit myiir_probe(struct platform_device *pdev) { struct proc_dir_entry *myiir_proc_entry[3]; int ret = 0; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(pdev-dev, No memory resource\n); return -ENODEV; } remap_size = res-end - res-start + 1; if (!request_mem_region(res-start, remap_size, pdev-name)) { dev_err(pdev-dev, Cannot request IO\n); return -ENXIO; } base_addr = ioremap(res-start, remap_size); if (base_addr == NULL) { dev_err(pdev-dev, Couldn't ioremap memory at 0x%08lx\n, (unsigned long)res-start); ret = -ENOMEM; goto err_release_region; } [..] static const struct of_device_id myiir_of_match[] __devinitconst = { {.compatible = dglnt,myiir-audio-ch0}, {.compatible = dglnt,myiir-audio-ch1}, {.compatible = dglnt,myiir-audio-mix0}, {}, }; Are these really separate IP blocks entirely, or just multiple instances of the same IP block (perhaps with different parameters used during synthesis)? If the latter, then they should really share a compatible string that reflects the name/version of the IP block; handling which block is which channel should be done at a higher level. Good luck, Josh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
SOC: Zedboard: Driver question
We are working on a school project in which we are trying to develop a audio mixer on Zedboard (Development board from Digilent). We have developed the IP and have integrated it with the overall hardware using Programmable logic. This board has ARM core. We have a Digilent pre-configured Linux source which we cross-compiled for ARM board, device tree blob and bootloader for Zync(BOOT.BIN). The system boots fine with Linux, but now to expose the recently added hardware implementation of audio mixer, we are trying to develop the driver using the platform driver API. Currently, In our reconfigurable hardware, we have 2 channels and a mixer and we want to access those individually as some file nodes under /proc FS. The sample code is shown below: snip from myiir.c /* device match table to match with device node in device tree * These are the list of devices that we want to expose as platform device */ static const struct of_device_id myiir_of_match[] __devinitconst = { {.compatible = dglnt,myiir-audio-ch0}, {.compatible = dglnt,myiir-audio-ch1}, {.compatible = dglnt,myiir-audio-mix0}, {}, }; MODULE_DEVICE_TABLE(of, myiir_of_match); /* platform driver structure for myiir driver */ static struct platform_driver myiir_driver = { .driver = { .name = DRIVER_NAME, .owner = THIS_MODULE, .of_match_table = myiir_of_match}, .probe = myiir_probe, .remove = __devexit_p(myiir_remove), .shutdown = __devexit_p(myiir_shutdown) }; /* Register myiir platform driver */ module_platform_driver(myiir_driver); myiir.c Now, inside the probe routine (myiir_probe), can we create proc entries by calling create_proc for each of these nodes and setting the appropriate read and write methods(file_operations) ? snip from the myiir_probe struct proc_dir_entry *myiir_proc_entry[3]; myiir_proc_entry[0] = proc_create(myiir-audio-ch0, 0, NULL, proc_myiir_ch0_operations); myiir_proc_entry[1] = proc_create(myiir-audio-ch1, 0, NULL, proc_myiir_ch1_operations); myiir_proc_entry[2] = proc_create(myiir-audio-mix0, 0, NULL, proc_myiir_mix0_operations); snip from the myiir_probe While browsing the Internet, we found some sample driver code, which we are also using as a template. I've attached the driver that is based on the same template. snip from device tree file myiir-aud-ch0 { compatible = dglnt,myiir-audio-ch0; reg = 0x7420 0x1; }; myiir-aud-ch1 { compatible = dglnt,myiir-audio-ch1; reg = 0x7422 0x1; }; myiir-aud-mix0 { compatible = dglnt,myiir-audio-mix0; reg = 0x6860 0x1; }; snip from device tree file The driver is far from complete, but as of now the compilation woks fine. snip user@fpga4v:~/tutorial/IIRdriver$ make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi- make -C ../linux-digilent-3.6-digilent-13.01/ M=/home/user/tutorial/IIRdriver modules make[1]: Entering directory `/home/user/tutorial/linux-digilent-3.6-digilent-13.01' CC [M] /home/user/tutorial/IIRdriver/myiir.o Building modules, stage 2. MODPOST 1 modules CC /home/user/tutorial/IIRdriver/myiir.mod.o LD [M] /home/user/tutorial/IIRdriver/myiir.ko make[1]: Leaving directory `/home/user/tutorial/linux-digilent-3.6-digilent-13.01' snip Thanks, Kumar #include linux/kernel.h #include linux/module.h #include asm/uaccess.h /*Needed for copy_from_user */ #include asm/io.h /*Needed for IO Read/Write Functions */ #include linux/proc_fs.h /*Needed for Proc File System Functions */ #include linux/seq_file.h /*Needed for Sequence File Operations */ #include linux/platform_device.h /*Needed for Platform Driver Functions */ /* Define Driver Name */ #define DRIVER_NAME myiir unsigned long *base_addr; /* Vitual Base Address */ struct resource *res; /* Device Resource Structure */ unsigned long remap_size; /* Device Memory Size */ /* Write operation for /proc/myiir * --- * When user cat a string to /proc/myiir file, the string will be stored in * const char __user *buf. This function will copy the string from user * space into kernel space, and change it to an unsigned long value. * It will then write the value to the register of myiir controller, * and turn on the corresponding LEDs eventually. */ static ssize_t proc_myiir_write(struct file *file, const char __user * buf, size_t count, loff_t * ppos) { char myiir_phrase[16]; u32 myiir_value; if (count 11) { if (copy_from_user(myiir_phrase, buf, count)) return -EFAULT; myiir_phrase[count] = '\0'; } myiir_value = simple_strtoul(myiir_phrase, NULL, 0); wmb(); iowrite32(myiir_value, base_addr); return count; } /* Callback function when opening file /proc/myiir * -- * Read the register value of myiir controller,
Re: SOC: Zedboard: Driver question
On Thu, Jun 12, 2014 at 7:09 PM, amit mehta gmate.a...@gmail.com wrote: We are working on a school project in which we are trying to develop a audio mixer on Zedboard (Development board from Digilent). We have developed the IP and have integrated it with the overall hardware using Programmable logic. This board has ARM core. We have a Digilent pre-configured Linux source which we cross-compiled for ARM board, device tree blob and bootloader for Zync(BOOT.BIN). The system boots fine with Linux, but now to expose the recently added hardware implementation of audio mixer, we are trying to develop the driver using the platform driver API. Currently, In our reconfigurable hardware, we have 2 channels and a mixer and we want to access those individually as some file nodes under /proc FS. The sample code is shown below: snip from myiir.c /* device match table to match with device node in device tree * These are the list of devices that we want to expose as platform device */ static const struct of_device_id myiir_of_match[] __devinitconst = { {.compatible = dglnt,myiir-audio-ch0}, {.compatible = dglnt,myiir-audio-ch1}, {.compatible = dglnt,myiir-audio-mix0}, {}, }; MODULE_DEVICE_TABLE(of, myiir_of_match); /* platform driver structure for myiir driver */ static struct platform_driver myiir_driver = { .driver = { .name = DRIVER_NAME, .owner = THIS_MODULE, .of_match_table = myiir_of_match}, .probe = myiir_probe, .remove = __devexit_p(myiir_remove), .shutdown = __devexit_p(myiir_shutdown) }; /* Register myiir platform driver */ module_platform_driver(myiir_driver); myiir.c Now, inside the probe routine (myiir_probe), can we create proc entries by calling create_proc for each of these nodes and setting the appropriate read and write methods(file_operations) ? Yes, I feel this is fine, the proc entries to be created in probe, Initialize all data structures as required in probe. snip from the myiir_probe struct proc_dir_entry *myiir_proc_entry[3]; myiir_proc_entry[0] = proc_create(myiir-audio-ch0, 0, NULL, proc_myiir_ch0_operations); myiir_proc_entry[1] = proc_create(myiir-audio-ch1, 0, NULL, proc_myiir_ch1_operations); myiir_proc_entry[2] = proc_create(myiir-audio-mix0, 0, NULL, proc_myiir_mix0_operations); snip from the myiir_probe While browsing the Internet, we found some sample driver code, which we are also using as a template. I've attached the driver that is based on the same template. snip from device tree file myiir-aud-ch0 { compatible = dglnt,myiir-audio-ch0; reg = 0x7420 0x1; }; myiir-aud-ch1 { compatible = dglnt,myiir-audio-ch1; reg = 0x7422 0x1; }; myiir-aud-mix0 { compatible = dglnt,myiir-audio-mix0; reg = 0x6860 0x1; }; snip from device tree file The driver is far from complete, but as of now the compilation woks fine. snip user@fpga4v:~/tutorial/IIRdriver$ make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi- make -C ../linux-digilent-3.6-digilent-13.01/ M=/home/user/tutorial/IIRdriver modules make[1]: Entering directory `/home/user/tutorial/linux-digilent-3.6-digilent-13.01' CC [M] /home/user/tutorial/IIRdriver/myiir.o Building modules, stage 2. MODPOST 1 modules CC /home/user/tutorial/IIRdriver/myiir.mod.o LD [M] /home/user/tutorial/IIRdriver/myiir.ko make[1]: Leaving directory `/home/user/tutorial/linux-digilent-3.6-digilent-13.01' snip Overall this looks to be a good attempt .Kumar :) Thanks, Kumar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: SOC: Zedboard: Driver question
On Thu, Jun 12, 2014 at 8:13 PM, amit mehta gmate.a...@gmail.com wrote: On Thu, Jun 12, 2014 at 4:52 PM, priyaranjan priyaranjan45...@gmail.com wrote: On Thu, Jun 12, 2014 at 7:09 PM, amit mehta gmate.a...@gmail.com wrote: We are working on a school project in which we are trying to develop a audio mixer on Zedboard (Development board from Digilent). We have developed the IP and have integrated it with the overall hardware using Programmable logic. This board has ARM core. We have a Digilent pre-configured Linux source which we cross-compiled for ARM board, device tree blob and bootloader for Zync(BOOT.BIN). The system boots fine with Linux, but now to expose the recently added hardware implementation of audio mixer, we are trying to develop the driver using the platform driver API. Currently, In our reconfigurable hardware, we have 2 channels and a mixer and we want to access those individually as some file nodes under /proc FS. The sample code is shown below: snip from myiir.c /* device match table to match with device node in device tree * These are the list of devices that we want to expose as platform device */ static const struct of_device_id myiir_of_match[] __devinitconst = { {.compatible = dglnt,myiir-audio-ch0}, {.compatible = dglnt,myiir-audio-ch1}, {.compatible = dglnt,myiir-audio-mix0}, {}, }; MODULE_DEVICE_TABLE(of, myiir_of_match); /* platform driver structure for myiir driver */ static struct platform_driver myiir_driver = { .driver = { .name = DRIVER_NAME, .owner = THIS_MODULE, .of_match_table = myiir_of_match}, .probe = myiir_probe, .remove = __devexit_p(myiir_remove), .shutdown = __devexit_p(myiir_shutdown) }; /* Register myiir platform driver */ module_platform_driver(myiir_driver); myiir.c Now, inside the probe routine (myiir_probe), can we create proc entries by calling create_proc for each of these nodes and setting the appropriate read and write methods(file_operations) ? Yes, I feel this is fine, the proc entries to be created in probe, Initialize all data structures as required in probe. Thank you for this confirmation. I've one more query regarding the IO addresses. The CAD tool from Xilinx shows the base addresses of our custom IP, which we have put into the device tree blob(also shown in the attached screeshot) and in our driver, we are requesting the memory region and after calling the ioremap, we access those IO addresses, but is there are need to write the register addresses in the device tree file in a particular order(asceding/descending) ? I am not sure about ascending or descending order but yes, the register addresses should be in the device tree. You can check more examples on the same and follow. snip from device tree file myiir-aud-ch0 { compatible = dglnt,myiir-audio-ch0; reg = 0x7420 0x1; }; myiir-aud-ch1 { compatible = dglnt,myiir-audio-ch1; reg = 0x7422 0x1; }; myiir-aud-mix0 { compatible = dglnt,myiir-audio-mix0; reg = 0x6860 0x1; }; snip from device tree file The sequence of operation in probe routine is: platform_get_resource(pdev, IORESOURCE_MEM, 0); remap_size = res-end - res-start + 1; request_mem_region(res-start, remap_size, pdev-name); base_addr = ioremap(res-start, remap_size); Thanks, Kumar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies