On Tue, Jul 18, 2017 at 02:21:47PM +0100, Mark Brown wrote: > On Mon, Jul 17, 2017 at 11:01:07AM +0200, Maxime Ripard wrote: > > On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote: > > > > > This might be problematic if the clock to enable is stored in another node. > > > > Let's add a function that allows to attach a clock that has already been > > > > retrieved to a regmap in order to fix this. > > > > What is the use case for this? > > > This is useful when the clock you want to be handled by the regmap is > > not described in the device node that probed the driver, but one of > > its subnode, or an another node entirely. > > > We're in the latter case, where we have two controllers in the DT, but > > are driven by the same driver. We'll create two regmaps, but one will > > not have the proper of_node used to retrieve the clock. > > I'm sorry but I'm still not seeing why you're doing this. Can you be > more concrete please? We have two devices needed to bring DSI: the DSI controller itself and its associated PHY. The PHY configuration cannot be done through a framework because it requires more information than the various phy frameworks allow to pass through to the driver. Therefore, we have a single driver, attached to the DSI controller, which handles both the PHY and the DSI controller. Both the PHY and the DSI controller are separate device, with different memory regions. Therefore, we need to create two regmaps, with clocks attached to them. However, the default clock retrieval mechanism doesn't work for the phy regmap, since only the DSI controller device of_node is considered, while its clock is stored in a separate node. I hope it's clearer, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
