SOC: Zedboard: Driver question

[priyaranjan]

On Thu, Jun 12, 2014 at 8:13 PM, amit mehta <gmate.amit at gmail.com> wrote:

> On Thu, Jun 12, 2014 at 4:52 PM, priyaranjan <priyaranjan45678 at gmail.com>
> wrote:
> >
> >
> >
> > On Thu, Jun 12, 2014 at 7:09 PM, amit mehta <gmate.amit at 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 = <0x74200000 0x10000>;
>                 };
>                 myiir-aud-ch1 {
>                         compatible = "dglnt,myiir-audio-ch1";
>                         reg = <0x74220000 0x10000>;
>                 };
>                 myiir-aud-mix0 {
>                         compatible = "dglnt,myiir-audio-mix0";
>                         reg = <0x68600000 0x10000>;
>                 };
> <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140612/adadfbf4/attachment.html