| Message ID | CAC63_iTf696D6Q_EzFeUUp5R38pYNEJBkmKviEu6-yuF0y=bNA@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Manjunath, Comments below. I left in a lot of context for the new folks that I've cc'd (Tony and Kevin). On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote: > On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely <grant.likely@secretlab.ca> wrote: >>> > +static void __init omap3_init(void) >>> > +{ >>> > + struct device_node *node; >>> > + >>> > + node = of_find_matching_node_by_address(NULL, omap3_dt_intc_match, >>> > + OMAP34XX_IC_BASE); >>> > + if (node) >>> > + irq_domain_add_simple(node, 0); >>> > + >>> > + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); >>> > + omap3_beagle_init_rev(); >>> > + omap3_beagle_i2c_init(); >>> > + platform_add_devices(omap3_beagle_devices, >>> > + ARRAY_SIZE(omap3_beagle_devices)); >>> > + omap_display_init(&beagle_dss_data); >>> > + omap_serial_init(); >>> > + >>> > + omap_mux_init_gpio(170, OMAP_PIN_INPUT); >>> > + /* REVISIT leave DVI powered down until it's needed ... */ >>> > + gpio_request_one(170, GPIOF_OUT_INIT_HIGH, "DVI_nPD"); >>> > + >>> > + usb_musb_init(NULL); >>> > + usbhs_init(&usbhs_bdata); >>> > + omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions, >>> > + ARRAY_SIZE(omap3beagle_nand_partitions)); >>> > + >>> > + /* Ensure msecure is mux'd to be able to set the RTC. */ >>> > + omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH); >>> > + >>> > + /* Ensure SDRC pins are mux'd for self-refresh */ >>> > + omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT); >>> > + omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT); >>> > + >>> > + beagle_display_init(); >>> > + beagle_opp_init(); >>> > + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); >>> >>> Hmmm, I don't think this will work for OMAP because it will not create >>> the i2c bus as an omap_device. It will only be a plane >>> platform_deevice. You'll need to have a hook in >>> of_platform_populate() to create devices the way omap3 infrastructure >>> expects. >>> >> > This dependency is mentioned in patch series. Since you pointed out this > issue, I would like to propose following approach for hooking up omap hwmod· > framework with dt. Though, the current approach focus only on i2c driver, it > can be extended and generalized as it evolves with other board and > driver cleanup > activities. The following changes are not tested and also not compiled, it is > only proposal I am thinking to implement. > > Let me know if you see any serious issues with the approach. > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c > index c1773456..104ef31 100644 > --- a/drivers/of/platform.c > +++ b/drivers/of/platform.c > @@ -457,6 +457,8 @@ void of_platform_prepare(struct device_node *root, > } > } > > + > + > #ifdef CONFIG_ARM_AMBA > static struct amba_device *of_amba_device_create(struct device_node *node, > const char *bus_id, > @@ -537,13 +539,60 @@ static const struct of_dev_auxdata > *of_dev_lookup(const struct of_dev_auxdata *l > continue; > if (res.start != lookup->phys_addr) > continue; > - pr_debug("%s: devname=%s\n", np->full_name, > lookup->name); > + printk("%s: devname=%s\n", np->full_name, lookup->name); > return lookup; > } > } > return NULL; > } > > +static struct omap_device *of_omap_i2c_device_create(struct device_node *node, > + const char *bus_id, > + void *platform_data, > + struct device *parent) > +{ > + struct platform_device *pdev; > + struct i2c_board_info *i2c_board_info; > + u8 id; > + > + printk("Creating omap i2c device %s\n", node->full_name); > + > + if (!of_device_is_available(node)) > + return NULL; > + > + id = simple_strtol(bus_id, NULL, 0); > + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL); > + pdev->dev.of_node = of_node_get(node); > + if (!pdev->dev.of_node) { > + speed = 100; > + } else { > + u32 prop; > + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", > + &prop)) > + speed = prop/100; > + else > + speed = 100; > + } > + printk("%s : speed->%d\n",__func__, speed); > + > + for_each_child_of_node(bus, child) { > + u32 prop; > + > + printk(" create child: %s\n", child->full_name); > + i2c_board_info = kzalloc(sizeof(*i2c_board_info), GFP_KERNEL); > + if (!of_property_read_u32(pdev->dev.of_node, "reg", > + &prop)) > + i2c_board_info->addr = prop; > + if (!of_property_read_u32(pdev->dev.of_node, "interrupts", > + &prop)) > + i2c_board_info->irq = prop; > + i2c_board_info->platform_data = platform_data; > + strncpy(i2c_board_info->type, child->name, > + sizeof(i2c_board_info->type)); > + } > + omap_register_i2c_bus(id, speed, i2c_board_info, 1); While this does in a sense work, and creates an omap_device for the i2c bus that does get probed, it ends up encoding an awful lot of device specific details into the generic devicetree support code. The i2c bus driver itself must be responsible for decoding the speed and child nodes, and in fact it can easily be modified to do so (I've already demonstrated how to do so). The real problem is making sure the platform_device is created in a way that attaches the correct hwmod data. For this context, the current omap_register_i2c_bus() isn't a useful method for doing so. So what is to be done? omap_register_i2c_bus() does three things; 1) register an i2c board info for the bus with i2c_register_board_info(), 2) fill platform_data for the device, and 3) use omap_i2c_add_bus to create the platform_device with attached hwmod. Of these three, 1 & 2 must not be done when using the DT. Only omap_i2c_add_bus() does something useful, but that is still specific to the i2c device. omap_i2c_add_bus() splits to omap{1,2}_add_bus(). omap1_i2c_add_bus() sets up pinmux and calls platform_device register. pinmux setup needs to be factored out anyway for generic DT platform device registration, which just leaves platform_device creation which is already handled by of_platform_populate(). omap2_i2c_add_bus() does the same thing, except it also looks up the hwmod data (*oh) and uses it to call omap_device_build(). omap_device_build() or something equivalent needs to be called for every omap device in the system, which is to create platform_devices with hwmod attached. Now we're starting to hit generic code. :-) The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match "ti,omap3-device" or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. > +} > + > /** > * of_platform_bus_create() - Create a device for a node and its children. > * @bus: device node of the bus to instantiate > @@ -593,6 +642,11 @@ static int of_platform_bus_create(struct device_node *bus, > return 0; > } > > + if (of_device_is_compatible(bus, "ti,omap3-i2c")) { > + of_omap_i2c_device_create(bus, bus_id, platform_data, parent); > + return 0; > + } > + > dev = of_platform_device_create_pdata(bus, bus_id, > platform_data, parent); > if (!dev || !of_match_node(matches, bus)) > return 0; > > -M >
* Grant Likely <grant.likely@secretlab.ca> [110716 22:08]: > > The way I see it, you've got two options: > > 1) modify the of_platform_bus_create() to call some kind of > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > or something. > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > hwmod data to normal platform devices. omap_device_build() is > actually pretty simple. It allocated a device, it attaches > platform_data and hwmod pointers to the device and registers it. > omap_device_register() is just a wrapper around > platform_device_register(). > > My preference is definitely #2, but there is a wrinkle in this > approach. Unfortunately omap_devices are not simply plain > platform_devices with extra data attached, an omap_device actually > embeds the platform_device inside it, which cannot be attached after > the fact. I think I had talked with Kevin (cc'd) about eliminating > the embedding, but I cannot remember clearly on this point. As long > as platform_device remains embedded inside struct omap_device, #2 > won't work. > > In either case, looking up the correct hwmod data should be easy for > any device provided the omap code maintains a lookup table of > compatible strings and base addresses of devices (much like auxdata). > In fact, I'd be okay with extending auxdata to include OMAP fields if > that would be easiest since the whole point of auxdata is to ease the > transition to DT support. When a matching device is created, the > hwmod pointer can easily be attached. This should work transparently > for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) How about if we just have the hwmod code call omap_device_build for each device tree entry? Regards, Tony
Hi Grant, On 17 July 2011 10:43, Grant Likely <grant.likely@secretlab.ca> wrote: > Hi Manjunath, > > Comments below. I left in a lot of context for the new folks that > I've cc'd (Tony and Kevin). > > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote: >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely <grant.likely@secretlab.ca> wrote: >>>> > +static void __init omap3_init(void) >>>> > +{ >>>> > + struct device_node *node; >>>> > + [...] >> +static struct omap_device *of_omap_i2c_device_create(struct device_node *node, >> + const char *bus_id, >> + void *platform_data, >> + struct device *parent) >> +{ >> + struct platform_device *pdev; >> + struct i2c_board_info *i2c_board_info; >> + u8 id; >> + >> + printk("Creating omap i2c device %s\n", node->full_name); >> + >> + if (!of_device_is_available(node)) >> + return NULL; >> + >> + id = simple_strtol(bus_id, NULL, 0); >> + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL); >> + pdev->dev.of_node = of_node_get(node); >> + if (!pdev->dev.of_node) { >> + speed = 100; >> + } else { >> + u32 prop; >> + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", >> + &prop)) >> + speed = prop/100; >> + else >> + speed = 100; >> + } >> + printk("%s : speed->%d\n",__func__, speed); >> + >> + for_each_child_of_node(bus, child) { >> + u32 prop; >> + >> + printk(" create child: %s\n", child->full_name); >> + i2c_board_info = kzalloc(sizeof(*i2c_board_info), GFP_KERNEL); >> + if (!of_property_read_u32(pdev->dev.of_node, "reg", >> + &prop)) >> + i2c_board_info->addr = prop; >> + if (!of_property_read_u32(pdev->dev.of_node, "interrupts", >> + &prop)) >> + i2c_board_info->irq = prop; >> + i2c_board_info->platform_data = platform_data; >> + strncpy(i2c_board_info->type, child->name, >> + sizeof(i2c_board_info->type)); >> + } >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1); > > While this does in a sense work, and creates an omap_device for the > i2c bus that does get probed, it ends up encoding an awful lot of > device specific details into the generic devicetree support code. The > i2c bus driver itself must be responsible for decoding the speed and > child nodes, and in fact it can easily be modified to do so (I've Decoding speed in i2c driver seems to be fine. But the i2c child nodes are board specific. We might bring board specific handling code into i2c driver with this approach. BTW, I have observed that, if we create i2c device node in omapx-soc.dtsi file and the define i2c bus clock-frequency in beagle.dts, the clock-frequency is not available in driver probe. Is this expected behavior? -M
Grant/Kevin, On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely <grant.likely@secretlab.ca> wrote: > Hi Manjunath, > > Comments below. I left in a lot of context for the new folks that > I've cc'd (Tony and Kevin). > > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote: >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely <grant.likely@secretlab.ca> wrote: >>>> > +static void __init omap3_init(void) >>>> > +{ [...] >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1); > > While this does in a sense work, and creates an omap_device for the > i2c bus that does get probed, it ends up encoding an awful lot of > device specific details into the generic devicetree support code. The > i2c bus driver itself must be responsible for decoding the speed and > child nodes, and in fact it can easily be modified to do so (I've > already demonstrated how to do so). The real problem is making sure > the platform_device is created in a way that attaches the correct > hwmod data. For this context, the current omap_register_i2c_bus() > isn't a useful method for doing so. > > So what is to be done? omap_register_i2c_bus() does three things; > 1) register an i2c board info for the bus with i2c_register_board_info(), > 2) fill platform_data for the device, and > 3) use omap_i2c_add_bus to create the platform_device with attached hwmod. > > Of these three, 1 & 2 must not be done when using the DT. Only > omap_i2c_add_bus() does something useful, but that is still specific > to the i2c device. > > omap_i2c_add_bus() splits to omap{1,2}_add_bus(). > > omap1_i2c_add_bus() sets up pinmux and calls platform_device register. > pinmux setup needs to be factored out anyway for generic DT platform > device registration, which just leaves platform_device creation which > is already handled by of_platform_populate(). > > omap2_i2c_add_bus() does the same thing, except it also looks up the > hwmod data (*oh) and uses it to call omap_device_build(). > omap_device_build() or something equivalent needs to be called for > every omap device in the system, which is to create platform_devices > with hwmod attached. Now we're starting to hit generic code. :-) > > The way I see it, you've got two options: > > 1) modify the of_platform_bus_create() to call some kind of > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > or something. > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > hwmod data to normal platform devices. omap_device_build() is > actually pretty simple. It allocated a device, it attaches > platform_data and hwmod pointers to the device and registers it. > omap_device_register() is just a wrapper around > platform_device_register(). > > My preference is definitely #2, but there is a wrinkle in this > approach. Unfortunately omap_devices are not simply plain > platform_devices with extra data attached, an omap_device actually > embeds the platform_device inside it, which cannot be attached after > the fact. I think I had talked with Kevin (cc'd) about eliminating > the embedding, but I cannot remember clearly on this point. As long > as platform_device remains embedded inside struct omap_device, #2 > won't work. Can you please elaborate more on this issue? -Manjunath
On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: > * Grant Likely <grant.likely@secretlab.ca> [110716 22:08]: > > > > The way I see it, you've got two options: > > > > 1) modify the of_platform_bus_create() to call some kind of > > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > > or something. > > > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > > hwmod data to normal platform devices. omap_device_build() is > > actually pretty simple. It allocated a device, it attaches > > platform_data and hwmod pointers to the device and registers it. > > omap_device_register() is just a wrapper around > > platform_device_register(). > > > > My preference is definitely #2, but there is a wrinkle in this > > approach. Unfortunately omap_devices are not simply plain > > platform_devices with extra data attached, an omap_device actually > > embeds the platform_device inside it, which cannot be attached after > > the fact. I think I had talked with Kevin (cc'd) about eliminating > > the embedding, but I cannot remember clearly on this point. As long > > as platform_device remains embedded inside struct omap_device, #2 > > won't work. > > > > In either case, looking up the correct hwmod data should be easy for > > any device provided the omap code maintains a lookup table of > > compatible strings and base addresses of devices (much like auxdata). > > In fact, I'd be okay with extending auxdata to include OMAP fields if > > that would be easiest since the whole point of auxdata is to ease the > > transition to DT support. When a matching device is created, the > > hwmod pointer can easily be attached. This should work transparently > > for all omap devices, not just the i2c bus. > > Well we should be able to automgagically build the omap_device for > each device tree entry. > > And then the device driver probe and runtime PM should be able to take > care of the rest for the driver. And then there's no more driver > specific platform init code needed ;) Right! That's the solution I'd like to see. > How about if we just have the hwmod code call omap_device_build for > each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The "of_platform_bus_create_omap()" function suggested above I assumed would directly call omap_device_build(). There are already hooks in the _populate call path to handle the creation of amba_devices. I have no problem doing the same thing for omap devices. g.
On Mon, Jul 18, 2011 at 03:45:57PM +0530, G, Manjunath Kondaiah wrote: > Hi Grant, > > On 17 July 2011 10:43, Grant Likely <grant.likely@secretlab.ca> wrote: > > Hi Manjunath, > > > > Comments below. I left in a lot of context for the new folks that > > I've cc'd (Tony and Kevin). > > > > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote: > >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely <grant.likely@secretlab.ca> wrote: > >>>> > +static void __init omap3_init(void) > >>>> > +{ > >>>> > + struct device_node *node; > >>>> > + > [...] > >> +static struct omap_device *of_omap_i2c_device_create(struct device_node *node, > >> + const char *bus_id, > >> + void *platform_data, > >> + struct device *parent) > >> +{ > >> + struct platform_device *pdev; > >> + struct i2c_board_info *i2c_board_info; > >> + u8 id; > >> + > >> + printk("Creating omap i2c device %s\n", node->full_name); > >> + > >> + if (!of_device_is_available(node)) > >> + return NULL; > >> + > >> + id = simple_strtol(bus_id, NULL, 0); > >> + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL); > >> + pdev->dev.of_node = of_node_get(node); > >> + if (!pdev->dev.of_node) { > >> + speed = 100; > >> + } else { > >> + u32 prop; > >> + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", > >> + &prop)) > >> + speed = prop/100; > >> + else > >> + speed = 100; > >> + } > >> + printk("%s : speed->%d\n",__func__, speed); > >> + > >> + for_each_child_of_node(bus, child) { > >> + u32 prop; > >> + > >> + printk(" create child: %s\n", child->full_name); > >> + i2c_board_info = kzalloc(sizeof(*i2c_board_info), GFP_KERNEL); > >> + if (!of_property_read_u32(pdev->dev.of_node, "reg", > >> + &prop)) > >> + i2c_board_info->addr = prop; > >> + if (!of_property_read_u32(pdev->dev.of_node, "interrupts", > >> + &prop)) > >> + i2c_board_info->irq = prop; > >> + i2c_board_info->platform_data = platform_data; > >> + strncpy(i2c_board_info->type, child->name, > >> + sizeof(i2c_board_info->type)); > >> + } > >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1); > > > > While this does in a sense work, and creates an omap_device for the > > i2c bus that does get probed, it ends up encoding an awful lot of > > device specific details into the generic devicetree support code. The > > i2c bus driver itself must be responsible for decoding the speed and > > child nodes, and in fact it can easily be modified to do so (I've > > Decoding speed in i2c driver seems to be fine. But the i2c child nodes are > board specific. We might bring board specific handling code into i2c driver > with this approach. It shouldn't. They're just i2c devices, and the child nodes will always follow the i2c device binding. > BTW, I have observed that, if we create i2c device node in omapx-soc.dtsi > file and the define i2c bus clock-frequency in beagle.dts, the clock-frequency > is not available in driver probe. Is this expected behavior? No, it sounds like something isn't getting set up correctly. Send me your current beagle.dts and omap3-soc.dtsi files. g.
On Tue, Jul 19, 2011 at 11:28:53AM +0530, G, Manjunath Kondaiah wrote: > Grant/Kevin, > > On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely > <grant.likely@secretlab.ca> wrote: > > Hi Manjunath, > > > > Comments below. I left in a lot of context for the new folks that > > I've cc'd (Tony and Kevin). > > > > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote: > >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely <grant.likely@secretlab.ca> wrote: > >>>> > +static void __init omap3_init(void) > >>>> > +{ > [...] > >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1); > > > > While this does in a sense work, and creates an omap_device for the > > i2c bus that does get probed, it ends up encoding an awful lot of > > device specific details into the generic devicetree support code. The > > i2c bus driver itself must be responsible for decoding the speed and > > child nodes, and in fact it can easily be modified to do so (I've > > already demonstrated how to do so). The real problem is making sure > > the platform_device is created in a way that attaches the correct > > hwmod data. For this context, the current omap_register_i2c_bus() > > isn't a useful method for doing so. > > > > So what is to be done? omap_register_i2c_bus() does three things; > > 1) register an i2c board info for the bus with i2c_register_board_info(), > > 2) fill platform_data for the device, and > > 3) use omap_i2c_add_bus to create the platform_device with attached hwmod. > > > > Of these three, 1 & 2 must not be done when using the DT. Only > > omap_i2c_add_bus() does something useful, but that is still specific > > to the i2c device. > > > > omap_i2c_add_bus() splits to omap{1,2}_add_bus(). > > > > omap1_i2c_add_bus() sets up pinmux and calls platform_device register. > > pinmux setup needs to be factored out anyway for generic DT platform > > device registration, which just leaves platform_device creation which > > is already handled by of_platform_populate(). > > > > omap2_i2c_add_bus() does the same thing, except it also looks up the > > hwmod data (*oh) and uses it to call omap_device_build(). > > omap_device_build() or something equivalent needs to be called for > > every omap device in the system, which is to create platform_devices > > with hwmod attached. Now we're starting to hit generic code. :-) > > > > The way I see it, you've got two options: > > > > 1) modify the of_platform_bus_create() to call some kind of > > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > > or something. > > > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > > hwmod data to normal platform devices. omap_device_build() is > > actually pretty simple. It allocated a device, it attaches > > platform_data and hwmod pointers to the device and registers it. > > omap_device_register() is just a wrapper around > > platform_device_register(). > > > > My preference is definitely #2, but there is a wrinkle in this > > approach. Unfortunately omap_devices are not simply plain > > platform_devices with extra data attached, an omap_device actually > > embeds the platform_device inside it, which cannot be attached after > > the fact. I think I had talked with Kevin (cc'd) about eliminating > > the embedding, but I cannot remember clearly on this point. As long > > as platform_device remains embedded inside struct omap_device, #2 > > won't work. > > Can you please elaborate more on this issue? Look at the of_platform_populate() call path (in devicetree/next) and see how it handles amba devices. Do the same thing for omap_devices. g.
* Grant Likely <grant.likely@secretlab.ca> [110719 14:29]: > On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: > > * Grant Likely <grant.likely@secretlab.ca> [110716 22:08]: > > > > > > The way I see it, you've got two options: > > > > > > 1) modify the of_platform_bus_create() to call some kind of > > > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > > > or something. > > > > > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > > > hwmod data to normal platform devices. omap_device_build() is > > > actually pretty simple. It allocated a device, it attaches > > > platform_data and hwmod pointers to the device and registers it. > > > omap_device_register() is just a wrapper around > > > platform_device_register(). > > > > > > My preference is definitely #2, but there is a wrinkle in this > > > approach. Unfortunately omap_devices are not simply plain > > > platform_devices with extra data attached, an omap_device actually > > > embeds the platform_device inside it, which cannot be attached after > > > the fact. I think I had talked with Kevin (cc'd) about eliminating > > > the embedding, but I cannot remember clearly on this point. As long > > > as platform_device remains embedded inside struct omap_device, #2 > > > won't work. > > > > > > In either case, looking up the correct hwmod data should be easy for > > > any device provided the omap code maintains a lookup table of > > > compatible strings and base addresses of devices (much like auxdata). > > > In fact, I'd be okay with extending auxdata to include OMAP fields if > > > that would be easiest since the whole point of auxdata is to ease the > > > transition to DT support. When a matching device is created, the > > > hwmod pointer can easily be attached. This should work transparently > > > for all omap devices, not just the i2c bus. > > > > Well we should be able to automgagically build the omap_device for > > each device tree entry. > > > > And then the device driver probe and runtime PM should be able to take > > care of the rest for the driver. And then there's no more driver > > specific platform init code needed ;) > > Right! That's the solution I'd like to see. > > > How about if we just have the hwmod code call omap_device_build for > > each device tree entry? > > I think that is pretty much equivalent to suggestion #1 above, only > I'm suggesting to take advantage of the infrastructure already > available in driver/of/platform.c in the form of > of_platform_populate(). The "of_platform_bus_create_omap()" function > suggested above I assumed would directly call omap_device_build(). OK > There are already hooks in the _populate call path to handle the > creation of amba_devices. I have no problem doing the same thing for > omap devices. OK Regards, Tony
On 7/20/2011 3:04 AM, Grant Likely wrote: > On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: >> * Grant Likely<grant.likely@secretlab.ca> [110716 22:08]: >>> >>> The way I see it, you've got two options: >>> >>> 1) modify the of_platform_bus_create() to call some kind of >>> of_platform_bus_create_omap() for devices that match "ti,omap3-device" >>> or something. >>> >>> 2) Leave of_platform_bus_create(), and instead us a notifier to attach >>> hwmod data to normal platform devices. omap_device_build() is >>> actually pretty simple. It allocated a device, it attaches >>> platform_data and hwmod pointers to the device and registers it. >>> omap_device_register() is just a wrapper around >>> platform_device_register(). >>> >>> My preference is definitely #2, but there is a wrinkle in this >>> approach. Unfortunately omap_devices are not simply plain >>> platform_devices with extra data attached, an omap_device actually >>> embeds the platform_device inside it, which cannot be attached after >>> the fact. I think I had talked with Kevin (cc'd) about eliminating >>> the embedding, but I cannot remember clearly on this point. As long >>> as platform_device remains embedded inside struct omap_device, #2 >>> won't work. >>> >>> In either case, looking up the correct hwmod data should be easy for >>> any device provided the omap code maintains a lookup table of >>> compatible strings and base addresses of devices (much like auxdata). >>> In fact, I'd be okay with extending auxdata to include OMAP fields if >>> that would be easiest since the whole point of auxdata is to ease the >>> transition to DT support. When a matching device is created, the >>> hwmod pointer can easily be attached. This should work transparently >>> for all omap devices, not just the i2c bus. >> >> Well we should be able to automgagically build the omap_device for >> each device tree entry. >> >> And then the device driver probe and runtime PM should be able to take >> care of the rest for the driver. And then there's no more driver >> specific platform init code needed ;) > > Right! That's the solution I'd like to see. > >> How about if we just have the hwmod code call omap_device_build for >> each device tree entry? > > I think that is pretty much equivalent to suggestion #1 above, only > I'm suggesting to take advantage of the infrastructure already > available in driver/of/platform.c in the form of > of_platform_populate(). The "of_platform_bus_create_omap()" function > suggested above I assumed would directly call omap_device_build(). In fact a lot of what omap_device_build() does today might not even be needed anymore. A lot of what it does is populate the platform_device structure by looking up the hwmod structs. Most of that information would now come from DT and hence all of that can be taken off from the hwmod structs. What will still be needed in hwmod is other data needed to runtime enable/idle the devices. That data however still needs to be linked with the platform_device's that DT would create which is what I guess could be done in something like a of_platform_bus_create_omap(). Paul/Benoit, do you guys agree we can get rid of some of the data from hwmod, whatever would now get passed in from DT, and keep only the PRCM/OCP related stuff for runtime handling? > > There are already hooks in the _populate call path to handle the > creation of amba_devices. I have no problem doing the same thing for > omap devices. > > g. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi, On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote: > On 7/20/2011 3:04 AM, Grant Likely wrote: > >On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: > >>* Grant Likely<grant.likely@secretlab.ca> [110716 22:08]: > >>> > >>>The way I see it, you've got two options: > >>> > >>>1) modify the of_platform_bus_create() to call some kind of > >>>of_platform_bus_create_omap() for devices that match "ti,omap3-device" > >>>or something. > >>> > >>>2) Leave of_platform_bus_create(), and instead us a notifier to attach > >>>hwmod data to normal platform devices. omap_device_build() is > >>>actually pretty simple. It allocated a device, it attaches > >>>platform_data and hwmod pointers to the device and registers it. > >>>omap_device_register() is just a wrapper around > >>>platform_device_register(). > >>> > >>>My preference is definitely #2, but there is a wrinkle in this > >>>approach. Unfortunately omap_devices are not simply plain > >>>platform_devices with extra data attached, an omap_device actually > >>>embeds the platform_device inside it, which cannot be attached after > >>>the fact. I think I had talked with Kevin (cc'd) about eliminating > >>>the embedding, but I cannot remember clearly on this point. As long > >>>as platform_device remains embedded inside struct omap_device, #2 > >>>won't work. > >>> > >>>In either case, looking up the correct hwmod data should be easy for > >>>any device provided the omap code maintains a lookup table of > >>>compatible strings and base addresses of devices (much like auxdata). > >>>In fact, I'd be okay with extending auxdata to include OMAP fields if > >>>that would be easiest since the whole point of auxdata is to ease the > >>>transition to DT support. When a matching device is created, the > >>>hwmod pointer can easily be attached. This should work transparently > >>>for all omap devices, not just the i2c bus. > >> > >>Well we should be able to automgagically build the omap_device for > >>each device tree entry. > >> > >>And then the device driver probe and runtime PM should be able to take > >>care of the rest for the driver. And then there's no more driver > >>specific platform init code needed ;) > > > >Right! That's the solution I'd like to see. > > > >>How about if we just have the hwmod code call omap_device_build for > >>each device tree entry? > > > >I think that is pretty much equivalent to suggestion #1 above, only > >I'm suggesting to take advantage of the infrastructure already > >available in driver/of/platform.c in the form of > >of_platform_populate(). The "of_platform_bus_create_omap()" function > >suggested above I assumed would directly call omap_device_build(). > > In fact a lot of what omap_device_build() does today might not even be > needed anymore. A lot of what it does is populate the platform_device > structure by looking up the hwmod structs. > Most of that information would now come from DT and hence all of that > can be taken off from the hwmod structs. What will still be needed in > hwmod is other data needed to runtime enable/idle the devices. That > data however still needs to be linked with the platform_device's that > DT would create which is what I guess could be done in something > like a of_platform_bus_create_omap(). > > Paul/Benoit, do you guys agree we can get rid of some of the data > from hwmod, whatever would now get passed in from DT, and keep > only the PRCM/OCP related stuff for runtime handling? IMHO, all omap_hwmod_*_data.c files become pretty much useless if we move completely to DT. All hwmod data is passing today, can be passed via DT and in a similar Hierarchical manner. Now WRT omap_device_build() and PM, I think that's still necessary because it simplifies a lot PM handling. But the data files themselves can "easily" be purged from kernel and converted into DT.
On 7/21/2011 2:39 PM, Felipe Balbi wrote: > Hi, > > On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote: >> On 7/20/2011 3:04 AM, Grant Likely wrote: >>> On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: >>>> * Grant Likely<grant.likely@secretlab.ca> [110716 22:08]: >>>>> >>>>> The way I see it, you've got two options: >>>>> >>>>> 1) modify the of_platform_bus_create() to call some kind of >>>>> of_platform_bus_create_omap() for devices that match "ti,omap3-device" >>>>> or something. >>>>> >>>>> 2) Leave of_platform_bus_create(), and instead us a notifier to attach >>>>> hwmod data to normal platform devices. omap_device_build() is >>>>> actually pretty simple. It allocated a device, it attaches >>>>> platform_data and hwmod pointers to the device and registers it. >>>>> omap_device_register() is just a wrapper around >>>>> platform_device_register(). >>>>> >>>>> My preference is definitely #2, but there is a wrinkle in this >>>>> approach. Unfortunately omap_devices are not simply plain >>>>> platform_devices with extra data attached, an omap_device actually >>>>> embeds the platform_device inside it, which cannot be attached after >>>>> the fact. I think I had talked with Kevin (cc'd) about eliminating >>>>> the embedding, but I cannot remember clearly on this point. As long >>>>> as platform_device remains embedded inside struct omap_device, #2 >>>>> won't work. >>>>> >>>>> In either case, looking up the correct hwmod data should be easy for >>>>> any device provided the omap code maintains a lookup table of >>>>> compatible strings and base addresses of devices (much like auxdata). >>>>> In fact, I'd be okay with extending auxdata to include OMAP fields if >>>>> that would be easiest since the whole point of auxdata is to ease the >>>>> transition to DT support. When a matching device is created, the >>>>> hwmod pointer can easily be attached. This should work transparently >>>>> for all omap devices, not just the i2c bus. >>>> >>>> Well we should be able to automgagically build the omap_device for >>>> each device tree entry. >>>> >>>> And then the device driver probe and runtime PM should be able to take >>>> care of the rest for the driver. And then there's no more driver >>>> specific platform init code needed ;) >>> >>> Right! That's the solution I'd like to see. >>> >>>> How about if we just have the hwmod code call omap_device_build for >>>> each device tree entry? >>> >>> I think that is pretty much equivalent to suggestion #1 above, only >>> I'm suggesting to take advantage of the infrastructure already >>> available in driver/of/platform.c in the form of >>> of_platform_populate(). The "of_platform_bus_create_omap()" function >>> suggested above I assumed would directly call omap_device_build(). >> >> In fact a lot of what omap_device_build() does today might not even be >> needed anymore. A lot of what it does is populate the platform_device >> structure by looking up the hwmod structs. >> Most of that information would now come from DT and hence all of that >> can be taken off from the hwmod structs. What will still be needed in >> hwmod is other data needed to runtime enable/idle the devices. That >> data however still needs to be linked with the platform_device's that >> DT would create which is what I guess could be done in something >> like a of_platform_bus_create_omap(). >> >> Paul/Benoit, do you guys agree we can get rid of some of the data >> from hwmod, whatever would now get passed in from DT, and keep >> only the PRCM/OCP related stuff for runtime handling? > > IMHO, all omap_hwmod_*_data.c files become pretty much useless if we > move completely to DT. All hwmod data is passing today, can be passed > via DT and in a similar Hierarchical manner. Would the data representation be equally readable? That's one of the problems I faced when I started looking at it initially trying to move a lot of these structures. > > Now WRT omap_device_build() and PM, I think that's still necessary > because it simplifies a lot PM handling. But the data files themselves > can "easily" be purged from kernel and converted into DT. >
Hi, On Thu, Jul 21, 2011 at 03:03:24PM +0530, Rajendra Nayak wrote: > >IMHO, all omap_hwmod_*_data.c files become pretty much useless if we > >move completely to DT. All hwmod data is passing today, can be passed > >via DT and in a similar Hierarchical manner. > > Would the data representation be equally readable? > That's one of the problems I faced when I started > looking at it initially trying to move a lot of these > structures. not to my eyes, heh. I'm too used to C, though.
Hi Grant, On Wed, Jul 20, 2011 at 3:07 AM, Grant Likely <grant.likely@secretlab.ca> wrote: > On Tue, Jul 19, 2011 at 11:28:53AM +0530, G, Manjunath Kondaiah wrote: >> Grant/Kevin, >> >> On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely >> <grant.likely@secretlab.ca> wrote: >> > Hi Manjunath, >> > >> > Comments below. I left in a lot of context for the new folks that >> > I've cc'd (Tony and Kevin). >> > >> > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote: >> >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely <grant.likely@secretlab.ca> wrote: >> >>>> > +static void __init omap3_init(void) >> >>>> > +{ >> [...] >> >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1); >> > >> > While this does in a sense work, and creates an omap_device for the >> > i2c bus that does get probed, it ends up encoding an awful lot of >> > device specific details into the generic devicetree support code. The >> > i2c bus driver itself must be responsible for decoding the speed and >> > child nodes, and in fact it can easily be modified to do so (I've >> > already demonstrated how to do so). The real problem is making sure >> > the platform_device is created in a way that attaches the correct >> > hwmod data. For this context, the current omap_register_i2c_bus() >> > isn't a useful method for doing so. >> > >> > So what is to be done? omap_register_i2c_bus() does three things; >> > 1) register an i2c board info for the bus with i2c_register_board_info(), >> > 2) fill platform_data for the device, and >> > 3) use omap_i2c_add_bus to create the platform_device with attached hwmod. >> > >> > Of these three, 1 & 2 must not be done when using the DT. Only >> > omap_i2c_add_bus() does something useful, but that is still specific >> > to the i2c device. >> > >> > omap_i2c_add_bus() splits to omap{1,2}_add_bus(). >> > >> > omap1_i2c_add_bus() sets up pinmux and calls platform_device register. >> > pinmux setup needs to be factored out anyway for generic DT platform >> > device registration, which just leaves platform_device creation which >> > is already handled by of_platform_populate(). >> > >> > omap2_i2c_add_bus() does the same thing, except it also looks up the >> > hwmod data (*oh) and uses it to call omap_device_build(). >> > omap_device_build() or something equivalent needs to be called for >> > every omap device in the system, which is to create platform_devices >> > with hwmod attached. Now we're starting to hit generic code. :-) >> > >> > The way I see it, you've got two options: >> > >> > 1) modify the of_platform_bus_create() to call some kind of >> > of_platform_bus_create_omap() for devices that match "ti,omap3-device" >> > or something. >> > >> > 2) Leave of_platform_bus_create(), and instead us a notifier to attach >> > hwmod data to normal platform devices. omap_device_build() is >> > actually pretty simple. It allocated a device, it attaches >> > platform_data and hwmod pointers to the device and registers it. >> > omap_device_register() is just a wrapper around >> > platform_device_register(). >> > >> > My preference is definitely #2, but there is a wrinkle in this >> > approach. Unfortunately omap_devices are not simply plain >> > platform_devices with extra data attached, an omap_device actually >> > embeds the platform_device inside it, which cannot be attached after >> > the fact. I think I had talked with Kevin (cc'd) about eliminating >> > the embedding, but I cannot remember clearly on this point. As long >> > as platform_device remains embedded inside struct omap_device, #2 >> > won't work. >> >> Can you please elaborate more on this issue? > > Look at the of_platform_populate() call path (in devicetree/next) and > see how it handles amba devices. Do the same thing for omap_devices. As per the discussion so far, I am trying to take following approach: |--->of_platform_populate(...) |--->of_platform_bus_create_omap()-->Here notifiers are added |--->platform_device_register() ---> calls registered notifiers |--->notifier_callback - look up hwmod entry by name - call omap_device_build(need to pass platform_device pointer) - get all the details such as resource structures, irqs,platform_data etc from hwmod database and auxdata and assign it to platform_device pointer received from notifier callback function. - there will be no platform_device_register from omap_device_build since it is already called from "of_platform_bus_create_omap" Please note that, with the above approach, the platform_device pointer which is embedded inside omap_device is not used and omap_device_build api will expect platform device pointer. -M
Grant Likely <grant.likely@secretlab.ca> writes: [...] > The way I see it, you've got two options: > > 1) modify the of_platform_bus_create() to call some kind of > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > or something. > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > hwmod data to normal platform devices. omap_device_build() is > actually pretty simple. It allocated a device, it attaches > platform_data and hwmod pointers to the device and registers it. > omap_device_register() is just a wrapper around > platform_device_register(). > > My preference is definitely #2, but there is a wrinkle in this > approach. Unfortunately omap_devices are not simply plain > platform_devices with extra data attached, an omap_device actually > embeds the platform_device inside it, which cannot be attached after > the fact. I think I had talked with Kevin (cc'd) about eliminating > the embedding, but I cannot remember clearly on this point. As long > as platform_device remains embedded inside struct omap_device, #2 > won't work. I agree with #2, and I think we need to go down this de-coupling route also. I just sent an RFC series that starts down this path to at least demonstrate that it's possible. Kevin
Hi Rajendra, On 7/21/2011 10:55 AM, Nayak, Rajendra wrote: > On 7/20/2011 3:04 AM, Grant Likely wrote: >> On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: >>> * Grant Likely<grant.likely@secretlab.ca> [110716 22:08]: >>>> >>>> The way I see it, you've got two options: >>>> >>>> 1) modify the of_platform_bus_create() to call some kind of >>>> of_platform_bus_create_omap() for devices that match "ti,omap3-device" >>>> or something. >>>> >>>> 2) Leave of_platform_bus_create(), and instead us a notifier to attach >>>> hwmod data to normal platform devices. omap_device_build() is >>>> actually pretty simple. It allocated a device, it attaches >>>> platform_data and hwmod pointers to the device and registers it. >>>> omap_device_register() is just a wrapper around >>>> platform_device_register(). >>>> >>>> My preference is definitely #2, but there is a wrinkle in this >>>> approach. Unfortunately omap_devices are not simply plain >>>> platform_devices with extra data attached, an omap_device actually >>>> embeds the platform_device inside it, which cannot be attached after >>>> the fact. I think I had talked with Kevin (cc'd) about eliminating >>>> the embedding, but I cannot remember clearly on this point. As long >>>> as platform_device remains embedded inside struct omap_device, #2 >>>> won't work. >>>> >>>> In either case, looking up the correct hwmod data should be easy for >>>> any device provided the omap code maintains a lookup table of >>>> compatible strings and base addresses of devices (much like auxdata). >>>> In fact, I'd be okay with extending auxdata to include OMAP fields if >>>> that would be easiest since the whole point of auxdata is to ease the >>>> transition to DT support. When a matching device is created, the >>>> hwmod pointer can easily be attached. This should work transparently >>>> for all omap devices, not just the i2c bus. >>> >>> Well we should be able to automgagically build the omap_device for >>> each device tree entry. >>> >>> And then the device driver probe and runtime PM should be able to take >>> care of the rest for the driver. And then there's no more driver >>> specific platform init code needed ;) >> >> Right! That's the solution I'd like to see. >> >>> How about if we just have the hwmod code call omap_device_build for >>> each device tree entry? >> >> I think that is pretty much equivalent to suggestion #1 above, only >> I'm suggesting to take advantage of the infrastructure already >> available in driver/of/platform.c in the form of >> of_platform_populate(). The "of_platform_bus_create_omap()" function >> suggested above I assumed would directly call omap_device_build(). > > In fact a lot of what omap_device_build() does today might not even be > needed anymore. A lot of what it does is populate the platform_device > structure by looking up the hwmod structs. > Most of that information would now come from DT and hence all of that > can be taken off from the hwmod structs. What will still be needed in > hwmod is other data needed to runtime enable/idle the devices. That > data however still needs to be linked with the platform_device's that > DT would create which is what I guess could be done in something > like a of_platform_bus_create_omap(). > > Paul/Benoit, do you guys agree we can get rid of some of the data > from hwmod, whatever would now get passed in from DT, and keep > only the PRCM/OCP related stuff for runtime handling? We need to discuss that further, but last time we discussed with Paul and Tony, we were considering starting with a DT that will just contain the list of devices and a reference to one of several hwmod name. That will allow us to get rid of all the crappy devices init code we have here and there in OMAP today. That phase can already keep us busy for some time :-) The DT format has some limitation today to describe a device that is connected to several buses and thus have several addresses. The DT format is providing only the CPU view of the system, meaning that we cannot take advantage of it to give the memory map of the DSP, or the CortexM3 inside OMAP4 for example. OK, I know, hwmod is not providing that information either today... but that was the plan:-) Because of that we will miss a lot of data we are retrieving today from hwmod. So for sure, we can define any kind of data in DT, but it will be much better to support that kind of details in the format directly instead of adding some custom TI nodes. For my point of view, the DT format should evolve toward a full hierarchical HW representation from the board level instead of a CPU centric one. But that just my .2 cents. Meanwhile, maybe we can start moving basic data from hwmod to DT. At first we should probably just do the device -> hwmod binding using DT. There is so much stuff to do, that the hardest part is to figure out where to start:-) Regards, Benoit
diff --git a/drivers/of/platform.c b/drivers/of/platform.c index c1773456..104ef31 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -457,6 +457,8 @@ void of_platform_prepare(struct device_node *root, } } + + #ifdef CONFIG_ARM_AMBA static struct amba_device *of_amba_device_create(struct device_node *node, const char *bus_id, @@ -537,13 +539,60 @@ static const struct of_dev_auxdata *of_dev_lookup(const struct of_dev_auxdata *l continue; if (res.start != lookup->phys_addr) continue; - pr_debug("%s: devname=%s\n", np->full_name, lookup->name); + printk("%s: devname=%s\n", np->full_name, lookup->name); return lookup; } } return NULL; } +static struct omap_device *of_omap_i2c_device_create(struct device_node *node, + const char *bus_id, + void *platform_data, + struct device *parent) +{ + struct platform_device *pdev; + struct i2c_board_info *i2c_board_info; + u8 id; + + printk("Creating omap i2c device %s\n", node->full_name); + + if (!of_device_is_available(node)) + return NULL; + + id = simple_strtol(bus_id, NULL, 0); + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL); + pdev->dev.of_node = of_node_get(node); + if (!pdev->dev.of_node) { + speed = 100; + } else { + u32 prop; + if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency", + &prop)) + speed = prop/100; + else + speed = 100; + } + printk("%s : speed->%d\n",__func__, speed); + + for_each_child_of_node(bus, child) { + u32 prop; + + printk(" create child: %s\n", child->full_name); + i2c_board_info = kzalloc(sizeof(*i2c_board_info), GFP_KERNEL); + if (!of_property_read_u32(pdev->dev.of_node, "reg", + &prop)) + i2c_board_info->addr = prop; + if (!of_property_read_u32(pdev->dev.of_node, "interrupts", + &prop)) + i2c_board_info->irq = prop; + i2c_board_info->platform_data = platform_data; + strncpy(i2c_board_info->type, child->name, + sizeof(i2c_board_info->type)); + } + omap_register_i2c_bus(id, speed, i2c_board_info, 1); +} + /**