On Thu, Aug 15, 2013 at 11:28 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Wed, Aug 14, 2013 at 04:47:38PM -0400, Sean Paul wrote: > [...] >> +int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder, >> + struct i2c_client *client, struct device_node *node) > [...] >> + ptn_bridge->gpio_pd_n = of_get_named_gpio(node, "powerdown-gpio", 0); > > of_get_named_gpio() can return -EPROBE_DEFER and I wonder how you handle > that in the driver that uses ptn3460_init(). Since you pass in an > initialized drm_device, you'd need to undo all of that in case of > -EPROBE_DEFER. Well I guess you'd have to do that in case of any error, > but it makes things difficult to handle for drivers. > > For instance on Tegra we pretty much delay DRM initialization until all > required subdevices (there are quite a few) have been probed, so if we > wanted to use this function we'd have to call it after all drivers have > been probed because only then do we have access to a struct drm_device. > That will cause other problems, however, because at that point we can't > defer probing anymore. > I suppose I could add another init that performs the deferrable tasks (ptn3460_init_deferrable or something). This would be called before drm init has been started from one of the probe functions. Alternatively, I could set this up as a standalone i2c driver and do this stuff in the probe. Any other options? Adding another init call adds yet another thing the drm driver has to do to use this bridge. Making the ptn driver standalone requires you to set things up such that drm init is dependent on ptn probe running successfully. I'm not sure which is more desirable. Practically speaking, do you expect to call drm_init before the gpio is available? Sean > Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
