SOC: Zedboard: Driver question

sanjeev sharma sanjeevsharmaengg at gmail.com
Wed Jun 18 02:01:43 EDT 2014


is this Finally Working or you are facing some issues ?

Regards
Sanjeev Sharma


On Fri, Jun 13, 2014 at 6:43 PM, Josh Cartwright <joshc at 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140618/4eeb0d88/attachment.html 


More information about the Kernelnewbies mailing list