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-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
