[PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Pantelis Antoniou]

Hi Guennadi,

On Jan 8, 2013, at 11:51 AM, Guennadi Liakhovetski wrote:

> (adding linux-media ML to cc)
> 
> Hi Pantelis
> 
> On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
> 
>> Hi Arnd,
>> 
>> On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
>> 
>>> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
>>> 
>>> On Monday 07 January 2013, Tony Lindgren wrote:
>>>>> 
>>>>> At the end of the line, some kind of hardware glue is going to be needed.
>>>>> 
>>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>>>> in the beagleboard), it is a bit premature to think about making it overly
>>>>> general, besides the part that are obviously part of the infrastructure 
>>>>> (like the DT overlay stuff).
>>>>> 
>>>>> What I'm getting at, is that we need some user experience about this, before
>>>>> going away and creating structure out of possible misconception about the uses. 
>>>> 
>>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>>>> things for omaps that have eventually become generic frameworks have been
>>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>>>> so on.
>>>> 
>>>> So I suggest a minimal generic API from the start as that will make things
>>>> a lot easier in the long run.
>>> 
>>> I agree. The ux500 platform already has the concept of "user interface boards",
>>> which currently is not well integrated into devicetree. I believe Sascha
>>> mentioned that Pengutronix had been shipping some other systems with add-on
>>> boards and generating device tree binaries from source for each combination.
>>> 
>>> Ideally, both of the above should be able to use the same DT overlay logic
>>> as BeagleBone, and I'm sure there are more of those.
>>> 
>>> 	Arnd
>> 
>> Hmm, I see. 
>> 
>> I will need some more information about the interface of the 'user interface boards'.
>> I.e. how is the board identified, what is typically present on those boards, etc.
>> 
>> Can we get some input by the owner of other similar hardware? I know the FPGA
>> people have similar requirements for example. There are other people that are hitting
>> problems getting DT to work with their systems, like the V4L people with the order
>> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
>> cleanly solved by the overlay being contained in the V4L device node and applied just before
>> the device is probed.
> 
> You probably mean these related V4L patches: 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 
> that base upon of asynchronous V4L2 subdevice probing, referenced above. 
> Yes, V4L DT nodes, as documented in 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 
> contain "port" and "endpoint" nodes, that describe the configuration of 
> the hardware port and link to devices, connected to it. Not sure how well 
> this would work with DT overlays, because endpoint nodes on both sides of 
> the video data bus contain references to the other side and I don't know 
> whether and how these can be created and / or updated at run-time. 
> Otherwise, yes, the approach that we're currently developing on V4L allows 
> us to build video data pipelines independent of (sub)device driver probing 
> order.
> 

I'm not very well versed at the V4L intricacies, and correct me if I got it wrong,
but it seems like you have the  problem on needing to probe a bunch of devices only after 
the parent device has been probed successfully. 
Your async subdevice probing method seems to be doing this.

It might be simpler to do something like this:

v4ldevice {
	compatible = "foo,v4ldev";
	...
	overlay {
		fragment at 0 {
			target = <&i2c0>;
			__overlay__ {
				...
				/* i2c devices */
			};
		};
		fragment at 0 {
			target = <&ocp>;
			__overlay__ {
				..
				/* platform devices */
			};
		};
		...
	}:
};

And in the probe of the v4ldev apply the overlay. The i2c devices will end up in the
i2c node, the platform devices to the ocp node, etc, and will be registered.

There is nothing preventing the overlay being in a part of the board dts file. 
You will need to do a resolve pass for the phandles, but it's not insurmountable IMO.

Regards

-- Pantelis

> Thanks
> Guennadi
> 
>> In the meantime it would be better to wait until we have some ack from the maintainers
>> of the core subsystems about what they think.
>> 
>> Regards
>> 
>> -- Pantelis
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/