On Sat, Mar 19, 2011 at 8:39 PM, Shawn Guo <shawn....@freescale.com> wrote: > On Thu, Mar 17, 2011 at 11:08:19AM -0600, Grant Likely wrote: >> On Thu, Mar 17, 2011 at 12:31:15PM +0800, Shawn Guo wrote: >> > On Wed, Mar 16, 2011 at 05:05:00PM -0600, Grant Likely wrote: >> > > >> > [...] >> > > I'd like to have feedback on the new code to make sure that the model >> > > is sane. There are some fiddly code it there which is used to match >> > > platform_device registrations to nodes in the device tree. I *think* >> > > it makes sense, but I'd like to hear other opinions. >> > > >> > Binding platform_device with of_node via resources matching seems a >> > little fiddly, but your implementation looks solid to me. I made a >> > quick scan on all the platform_device registration under >> > arch/arm/plat-mxc/devices, nothing would be broken, only except >> > platform-gpio_keys which is not an on-chip device. >> >> Right; and doing it this way doesn't make sense for anything that is >> board/system specific because if the board is using the DT, then it is >> simpler and more reliable to avoid the matching heuristic entirely. >> >> > Looking at the code, I'm wondering how the binding of resource type >> > IORESOURCE_DMA looks like. I'm seeing some platform_device is using >> > this flag to tell dma channel fixed for the device. I'm not sure if >> > it can be fit in property 'dma-ranges'. And I only see IORESOURCE_MEM >> > and IORESOURCE_IRQ being used in the matching model. >> >> The matching is simply a heuristic that makes a best guess about how >> how device nodes line up with platform_device registrations. Right >> now the heuristic is to look at the register ranges and irqs described >> in the node and make sure that each of them are listed in the >> platform_device. If the platform_device has additional resources, >> then it simply ignores them. That seems to be sufficient for accurate >> matching, but I won't know for sure until people start using it. >> >> If there are situations where the heuristic does not work, then I'd >> like to know what they are so that the algorithm can be fixed, or in >> the absolute worst case implement workaround logic. >> >> One option I'm considering which would improve the accuracy of the >> heuristic is to add a 'char *of_compatible' field to struct >> platform_device. Then platform_devices could optionally be tagged >> with the compatible value that must be present in order to be matched >> with a node. >> >> I definitely want feedback on the matching heuristic! >> > Tested on babbage with serial, fec and esdhc drivers, and I did see > it solves problems of clkdev dev_id matching and pdev->id use. And > it even helped to discover one problem with .end definition of fec > resource IORESOURCE_MEM. I will send mainline a patch for that soon.
Awesome, thanks! g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
