Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thierry Reding <thierry.reding@xxxxxxxxx> wrote @ Fri, 1 Nov 2013 10:53:50 +0100:

> * PGP Signed by an unknown key
> 
> On Thu, Oct 31, 2013 at 10:37:40AM -0600, Stephen Warren wrote:
> > On 10/31/2013 02:14 AM, Hiroshi Doyu wrote:
> > > Thierry Reding <thierry.reding@xxxxxxxxx> wrote @ Wed, 30 Oct 2013 23:41:09 +0100:
> > > 
> > >> My earlier proposal for deferred interrupt reference resolution actually
> > >> tries to solve that problem within the core. Essentially what it does is
> > >> add a new function that gets called right before the driver's .probe()
> > >> function, so that it can parse standard resources and services from DT,
> > >> such as the interrupts property. This could theoretically be done for
> > >> other resources such as reg as well, but it really only matters where
> > >> the resource can be dynamic (as is the case for interrupts).
> > >>
> > >> In this case I would envision a standard OF function to associate a
> > >> device with its IOMMU. Perhaps something like:
> > >>
> > >> 	int of_iommu_attach(struct device *dev);
> > >>
> > >> That could be called by the core independent of the specific device and
> > >> IOMMU. IOMMU-specifics can probably be handled using .of_xlate(), quite
> > >> in a similar way to GPIO or regulators.
> > >>
> > >> That way drivers can remain agnostic of the IOMMU while still being able
> > >> to take advantage of deferred probing.
> > > 
> > > This could be simpler than making "bus_notifier" return "-EPROBE_DEFER".
> > > 
> > > The disadvantage of this is that we may need to provide the similar
> > > of_<"subsystem">_attach() per subsytem if needed.
> > 
> > Well, "per subsystem" here means per subsystem that is providing
> > resources, not per subsystem that is consuming resources. How many
> > subsystems are you expecting to provide resources like this? At present,
> > I believe IOMMU is the only subsystem missing some kind of API for
> > clients to acquire the relevant resource. I don't think there's any
> > scalability problem here.
> 
> Furthermore if the subsystem wants to provide resources then it needs
> such a function anyway, so there really isn't any overhead here.

Ok, the scalability won't be an issue since the number of subsystems
to provide resources/services is usually limited, anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux