Re: Need some guidance on i2c-ocores driver
mfd_add_devices() is called, it uses dev-resource as the base. So the
BAR will
be the parent. Check the code in mfd-core.c, mfd_add_device(),
if ((cell-resources[r].flags IORESOURCE_MEM) mem_base) {
res[r].parent = mem_base;
res[r].start = mem_base-start + cell-resources[r].start;
res[r].end = mem_base-start + cell-resources[r].end;
}
So the MFD resource is within its parent. When later the device driver
request a
region, will it get conflict with the parent?
I doubt you'll want to map the same memory area in both the parent and
the child device drivers. Only map the registers you plan to use in
the driver you plan to use them. If you need multiple devices to
access the same registers then you need to create an API, complete
with locking, in the MFD parent device.
Thanks for pointing out. I thought at first the conflict was due to my
pci_ioremap_bar(). I went ahead to remove the mapping but still not working.
Your email inspired me to take a deeper look at my code and I found my error.
I
have called pci_request_regions() which reserves all BARs. I think that's my
root cause. Thanks for helping me.
You are welcome.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need some guidance on i2c-ocores driver
On 04/19/2015 11:42 PM, Lee Jones wrote:
On Fri, 17 Apr 2015, York Sun wrote:
Resend to LKML
Lee,
This question is actually more about MFD. Can you point me to the possible
causes for my failure below?
It's hard to tell exactly without code, but it looks like you're
trying to allocate overlapping memory regions. Double check all of
your addresses. For DT you need to take a look at your 'reg'
properties, for traditional platform data it's best to grep for
IORESOURCE_MEM.
Lee,
It _is_ overlapping. How could it not be? The resource for the I2C is mapped to
BAR2. So the resource is overlapping with BAR2. It is alway the case, isn't it?
What I don't understand is how MFD works with the resources if it is guaranteed
overlapping. Did I get something wrong?
Look at the reference code I took, drivers/mfd/timberdale.c, when
mfd_add_devices() is called, it uses dev-resource as the base. So the BAR will
be the parent. Check the code in mfd-core.c, mfd_add_device(),
if ((cell-resources[r].flags IORESOURCE_MEM) mem_base) {
res[r].parent = mem_base;
res[r].start = mem_base-start + cell-resources[r].start;
res[r].end = mem_base-start + cell-resources[r].end;
}
So the MFD resource is within its parent. When later the device driver request a
region, will it get conflict with the parent?
York
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need some guidance on i2c-ocores driver
On Mon, 20 Apr 2015, York Sun wrote:
On 04/19/2015 11:42 PM, Lee Jones wrote:
On Fri, 17 Apr 2015, York Sun wrote:
Resend to LKML
Lee,
This question is actually more about MFD. Can you point me to the possible
causes for my failure below?
It's hard to tell exactly without code, but it looks like you're
trying to allocate overlapping memory regions. Double check all of
your addresses. For DT you need to take a look at your 'reg'
properties, for traditional platform data it's best to grep for
IORESOURCE_MEM.
Lee,
It _is_ overlapping. How could it not be? The resource for the I2C is mapped
to
BAR2. So the resource is overlapping with BAR2. It is alway the case, isn't
it?
What I don't understand is how MFD works with the resources if it is
guaranteed
overlapping. Did I get something wrong?
Look at the reference code I took, drivers/mfd/timberdale.c, when
mfd_add_devices() is called, it uses dev-resource as the base. So the BAR
will
be the parent. Check the code in mfd-core.c, mfd_add_device(),
if ((cell-resources[r].flags IORESOURCE_MEM) mem_base) {
res[r].parent = mem_base;
res[r].start = mem_base-start + cell-resources[r].start;
res[r].end = mem_base-start + cell-resources[r].end;
}
So the MFD resource is within its parent. When later the device driver
request a
region, will it get conflict with the parent?
I doubt you'll want to map the same memory area in both the parent and
the child device drivers. Only map the registers you plan to use in
the driver you plan to use them. If you need multiple devices to
access the same registers then you need to create an API, complete
with locking, in the MFD parent device.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need some guidance on i2c-ocores driver
On 04/20/2015 11:16 AM, Lee Jones wrote:
On Mon, 20 Apr 2015, York Sun wrote:
On 04/19/2015 11:42 PM, Lee Jones wrote:
On Fri, 17 Apr 2015, York Sun wrote:
Resend to LKML
Lee,
This question is actually more about MFD. Can you point me to the possible
causes for my failure below?
It's hard to tell exactly without code, but it looks like you're
trying to allocate overlapping memory regions. Double check all of
your addresses. For DT you need to take a look at your 'reg'
properties, for traditional platform data it's best to grep for
IORESOURCE_MEM.
Lee,
It _is_ overlapping. How could it not be? The resource for the I2C is mapped
to
BAR2. So the resource is overlapping with BAR2. It is alway the case, isn't
it?
What I don't understand is how MFD works with the resources if it is
guaranteed
overlapping. Did I get something wrong?
Look at the reference code I took, drivers/mfd/timberdale.c, when
mfd_add_devices() is called, it uses dev-resource as the base. So the BAR
will
be the parent. Check the code in mfd-core.c, mfd_add_device(),
if ((cell-resources[r].flags IORESOURCE_MEM) mem_base) {
res[r].parent = mem_base;
res[r].start = mem_base-start + cell-resources[r].start;
res[r].end = mem_base-start + cell-resources[r].end;
}
So the MFD resource is within its parent. When later the device driver
request a
region, will it get conflict with the parent?
I doubt you'll want to map the same memory area in both the parent and
the child device drivers. Only map the registers you plan to use in
the driver you plan to use them. If you need multiple devices to
access the same registers then you need to create an API, complete
with locking, in the MFD parent device.
Thanks for pointing out. I thought at first the conflict was due to my
pci_ioremap_bar(). I went ahead to remove the mapping but still not working.
Your email inspired me to take a deeper look at my code and I found my error. I
have called pci_request_regions() which reserves all BARs. I think that's my
root cause. Thanks for helping me.
York
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need some guidance on i2c-ocores driver
On Fri, 17 Apr 2015, York Sun wrote: Resend to LKML Lee, This question is actually more about MFD. Can you point me to the possible causes for my failure below? It's hard to tell exactly without code, but it looks like you're trying to allocate overlapping memory regions. Double check all of your addresses. For DT you need to take a look at your 'reg' properties, for traditional platform data it's best to grep for IORESOURCE_MEM. Thanks. York On 04/16/2015 05:02 PM, York Sun wrote: Julia and other experts, I am seeking for help on my device driver. I am working on a module driver for a FPGA design with open core I2C controller memory-mapped to BAR2. I have searched up and down and found only one driver (drivers/mfd/timberdale.c) with similar implementation. Following timberdale driver, I am able to load the driver, but blocked by devm_ioremap_resource(). It is always in conflict with my BAR2. I wonder if I did something wrong. Here is the flow I tracked so far. (By the way, I am using an older kernel 3.12. The new 4.0 kernel crashes when booting on my platform. I plan to move to newer kernel later). mfd_add_devices() | |--mfd_add_device() | |--platform_device_add() | |--insert_resource() /* this passed */ | | | |--insert_resource_conflict() | |--device_add() | |--bus_probe_device() | |--devm_ioremap_resource() | |--devm_request_mem_region() | |--__request_region() /* this always conflicts */ | |--__request_resource() My driver is called RedStone DMA. Here is my debug output root@p1022ds:~# insmod redstone_mfd.ko RedStone DMA 0002:05:00.0: pci_enable_device() successful RedStone DMA 0002:05:00.0: MSI-X init successful York kernel: Calling devm_ioremap_resource() York kernel kernel/resource.c __request_region 977: conflict=[??? 0xc0008-0xc00087fff flags 0x8000] ocores-i2c ocores-i2c: can't request region for resource [mem 0xc00086000-0xc0008601f] ocores-i2c: probe of ocores-i2c failed with error -16 RedStone DMA 0002:05:00.0: BAR[0] 0x000c-0x000c0007 flags 0x0014220c, length 524288 RedStone DMA 0002:05:00.0: BAR[1] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[2] 0x000c0008-0x000c00087fff flags 0x00040200, length 32768 RedStone DMA 0002:05:00.0: BAR[3] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[4] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[5] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: Version 1.4, built on 4-16-15, id 0 root@p1022ds:~# Can you shed some light on this? Thanks. York -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need some guidance on i2c-ocores driver
Resend to LKML Lee, This question is actually more about MFD. Can you point me to the possible causes for my failure below? Thanks. York On 04/16/2015 05:02 PM, York Sun wrote: Julia and other experts, I am seeking for help on my device driver. I am working on a module driver for a FPGA design with open core I2C controller memory-mapped to BAR2. I have searched up and down and found only one driver (drivers/mfd/timberdale.c) with similar implementation. Following timberdale driver, I am able to load the driver, but blocked by devm_ioremap_resource(). It is always in conflict with my BAR2. I wonder if I did something wrong. Here is the flow I tracked so far. (By the way, I am using an older kernel 3.12. The new 4.0 kernel crashes when booting on my platform. I plan to move to newer kernel later). mfd_add_devices() | |--mfd_add_device() | |--platform_device_add() | |--insert_resource() /* this passed */ | | | |--insert_resource_conflict() | |--device_add() | |--bus_probe_device() | |--devm_ioremap_resource() | |--devm_request_mem_region() | |--__request_region() /* this always conflicts */ | |--__request_resource() My driver is called RedStone DMA. Here is my debug output root@p1022ds:~# insmod redstone_mfd.ko RedStone DMA 0002:05:00.0: pci_enable_device() successful RedStone DMA 0002:05:00.0: MSI-X init successful York kernel: Calling devm_ioremap_resource() York kernel kernel/resource.c __request_region 977: conflict=[??? 0xc0008-0xc00087fff flags 0x8000] ocores-i2c ocores-i2c: can't request region for resource [mem 0xc00086000-0xc0008601f] ocores-i2c: probe of ocores-i2c failed with error -16 RedStone DMA 0002:05:00.0: BAR[0] 0x000c-0x000c0007 flags 0x0014220c, length 524288 RedStone DMA 0002:05:00.0: BAR[1] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[2] 0x000c0008-0x000c00087fff flags 0x00040200, length 32768 RedStone DMA 0002:05:00.0: BAR[3] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[4] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[5] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: Version 1.4, built on 4-16-15, id 0 root@p1022ds:~# Can you shed some light on this? Thanks. York -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Need some guidance on i2c-ocores driver
Julia and other experts, I am seeking for help on my device driver. I am working on a module driver for a FPGA design with open core I2C controller memory-mapped to BAR2. I have searched up and down and found only one driver (drivers/mfd/timberdale.c) with similar implementation. Following timberdale driver, I am able to load the driver, but blocked by devm_ioremap_resource(). It is always in conflict with my BAR2. I wonder if I did something wrong. Here is the flow I tracked so far. (By the way, I am using an older kernel 3.12. The new 4.0 kernel crashes when booting on my platform. I plan to move to newer kernel later). mfd_add_devices() | |--mfd_add_device() | |--platform_device_add() | |--insert_resource() /* this passed */ | | | |--insert_resource_conflict() | |--device_add() | |--bus_probe_device() | |--devm_ioremap_resource() | |--devm_request_mem_region() | |--__request_region() /* this always conflicts */ | |--__request_resource() My driver is called RedStone DMA. Here is my debug output root@p1022ds:~# insmod redstone_mfd.ko RedStone DMA 0002:05:00.0: pci_enable_device() successful RedStone DMA 0002:05:00.0: MSI-X init successful York kernel: Calling devm_ioremap_resource() York kernel kernel/resource.c __request_region 977: conflict=[??? 0xc0008-0xc00087fff flags 0x8000] ocores-i2c ocores-i2c: can't request region for resource [mem 0xc00086000-0xc0008601f] ocores-i2c: probe of ocores-i2c failed with error -16 RedStone DMA 0002:05:00.0: BAR[0] 0x000c-0x000c0007 flags 0x0014220c, length 524288 RedStone DMA 0002:05:00.0: BAR[1] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[2] 0x000c0008-0x000c00087fff flags 0x00040200, length 32768 RedStone DMA 0002:05:00.0: BAR[3] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[4] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: BAR[5] 0x-0x flags 0x, length 0 RedStone DMA 0002:05:00.0: Version 1.4, built on 4-16-15, id 0 root@p1022ds:~# Can you shed some light on this? Thanks. York -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
