All of lore.kernel.org
 help / color / mirror / Atom feed
* SOC: Zedboard: Driver question
@ 2014-06-12 13:39 amit mehta
  2014-06-12 13:52 ` priyaranjan
  2014-06-13 13:13 ` Josh Cartwright
  0 siblings, 2 replies; 6+ messages in thread
From: amit mehta @ 2014-06-12 13:39 UTC (permalink / raw)
  To: kernelnewbies

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 = <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 driver is far from complete, but as of now the compilation woks fine.
<snip>
user at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: myiir.c
Type: text/x-csrc
Size: 6753 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140612/03e15d80/attachment.bin 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* SOC: Zedboard: Driver question
  2014-06-12 13:39 SOC: Zedboard: Driver question amit mehta
@ 2014-06-12 13:52 ` priyaranjan
  2014-06-12 14:43   ` amit mehta
  2014-06-13 13:13 ` Josh Cartwright
  1 sibling, 1 reply; 6+ messages in thread
From: priyaranjan @ 2014-06-12 13:52 UTC (permalink / raw)
  To: kernelnewbies

On Thu, Jun 12, 2014 at 7:09 PM, amit mehta <gmate.amit@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 = <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 driver is far from complete, but as of now the compilation woks fine.
> <snip>
> user at 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 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/20140612/841ba8d1/attachment-0001.html 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* SOC: Zedboard: Driver question
  2014-06-12 13:52 ` priyaranjan
@ 2014-06-12 14:43   ` amit mehta
  2014-06-12 16:10     ` priyaranjan
  0 siblings, 1 reply; 6+ messages in thread
From: amit mehta @ 2014-06-12 14:43 UTC (permalink / raw)
  To: kernelnewbies

On Thu, Jun 12, 2014 at 4:52 PM, priyaranjan <priyaranjan45678@gmail.com> wrote:
>
>
>
> On Thu, Jun 12, 2014 at 7:09 PM, amit mehta <gmate.amit@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) ?
<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 --------------
A non-text attachment was scrubbed...
Name: IIR_ISE.png
Type: image/png
Size: 88897 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140612/fcc8474c/attachment-0001.png 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* SOC: Zedboard: Driver question
  2014-06-12 14:43   ` amit mehta
@ 2014-06-12 16:10     ` priyaranjan
  0 siblings, 0 replies; 6+ messages in thread
From: priyaranjan @ 2014-06-12 16:10 UTC (permalink / raw)
  To: kernelnewbies

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

> On Thu, Jun 12, 2014 at 4:52 PM, priyaranjan <priyaranjan45678@gmail.com>
> wrote:
> >
> >
> >
> > On Thu, Jun 12, 2014 at 7:09 PM, amit mehta <gmate.amit@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 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* SOC: Zedboard: Driver question
  2014-06-12 13:39 SOC: Zedboard: Driver question amit mehta
  2014-06-12 13:52 ` priyaranjan
@ 2014-06-13 13:13 ` Josh Cartwright
  2014-06-18  6:01   ` sanjeev sharma
  1 sibling, 1 reply; 6+ messages in thread
From: Josh Cartwright @ 2014-06-13 13:13 UTC (permalink / raw)
  To: kernelnewbies

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* SOC: Zedboard: Driver question
  2014-06-13 13:13 ` Josh Cartwright
@ 2014-06-18  6:01   ` sanjeev sharma
  0 siblings, 0 replies; 6+ messages in thread
From: sanjeev sharma @ 2014-06-18  6:01 UTC (permalink / raw)
  To: kernelnewbies

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@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 

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-06-18  6:01 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-12 13:39 SOC: Zedboard: Driver question amit mehta
2014-06-12 13:52 ` priyaranjan
2014-06-12 14:43   ` amit mehta
2014-06-12 16:10     ` priyaranjan
2014-06-13 13:13 ` Josh Cartwright
2014-06-18  6:01   ` sanjeev sharma

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.