Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

Russell King - ARM Linux wrote, On 01.05.2014 00:28:
> On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
> > The main problem with component framework is that componentization
> > significantly changes every driver and changes it in a way which is not
> > compatible with traditional drivers, so devices which are intended to
> > work with different DRM masters are hard to componentize if some of DRMs
> > are componentized and some not.
> Many of the problems which the component helpers are designed to solve
> are those where you need the drm_device structure (or snd_card, or whatever
> subsystem specific card/device representation structure) pre-created in
> order to initialise the components.
>
> In the case of DRM, you can't initialise encoders or connectors without
> their drm_device structure pre-existing - because these components are
> attached to the drm_device.
>
> Your solution to that is to delay those calls, but the DRM subsystem is
> not designed to cope like that - it's designed such that when the
> connector or encoder initialisation functions are called, it is assumed
> that the driver is initialising its state. (I've raised this point before
> but you've just fobbed it off in the past.)
>
> Another issue here is that the order of initialisation matters greatly.
> Take CRTCs for example.  In DRM, the order of attachment of CRTCs defines
> their identity, changing the order changes their identity, and changes
> how they are bound to their respective connectors.
The two problems you show here are not a real problems in this framework:
1. making real device initialization during drm initialization - 
decision is left
to driver developer what should be done in probe, what should be done in
'bind', I guess this is also true for components, at least the framework 
allows it.
2. initialization order - if you put initialization into components 
'bind' function,
master can choose any order of calls to 'bind'.

Anyway you can implement the same behaviour as components with
interface_tracker. Just simple proof of concept, how to convert 
componentized
drivers to interface_tracker:
Components:
1. you can reuse component_ops
2. You replace calls of component_add and component_del with calls
to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT, 
&specific_component_ops),
or interface_tracker_ifdown.
Thats all for components.

Master:
1. you register callback for tracking all components.
2. in the callback you check if all components are up, if yes you do the
same as in component framework initialization, to simplify it
helper function can be added.

I guess it should work the same way, if there is interest in it I can 
develop the
helper next week, I hope.

What is the benefit of interface_tracker:
1. interface_tracker is more generic - it can track not only components.
2. you put component initialization code into helper function - sounds 
like mid-layer removal,
developer can choose different helper if it suits better.

So from component point of view interface_tracker can be treated as kind 
of extensions
of the component framework.

I hope I have answerer all your concerns.

I have holidays till Sunday and I am not sure if I will be able to 
answer next emails before
Monday.

Regards
Andrzej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/