SOC: Zedboard: Driver question

[joshc@eso.teric.us (Josh Cartwright)]

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