On Tue, Oct 20, 2015 at 09:08:09AM +0530, Vinod Koul wrote: > On Mon, Oct 19, 2015 at 03:20:30PM +0200, Takashi Iwai wrote: > > On Sun, 18 Oct 2015 19:16:42 +0200, > > Russell King - ARM Linux wrote: > > > > > > On Sun, Oct 18, 2015 at 09:43:29PM +0530, Vinod Koul wrote: > > > > Right but can I ask why you didn't try making video as component and then > > > > CEC, audio and others receive the notification over this. > > > > > > Okay, I think I see what you're getting at. No, I don't want to tie > > > this stuff into the component helpers because that's the wrong approach. > > > > > > The component helper is purely about combining several struct devices > > > into one larger component for a subsystem which deals with card-level > > > components. It's not about cross-subsystem stuff. > > > > > > The problem with using it for cross-subsystem stuff is that it becomes > > > too tightly bound together: why should the graphics side get torn down > > > if you unload the audio or CEC driver? > > > > > > Audio and CEC are rather optional for HDMI - HDMI can work without audio > > > and CEC being present. However, audio can't be conveyed across the link > > > without the video side being configured. So, it makes sense to allow > > > the CEC and audio parts to be loaded separately (possibly as modules) > > > while having the video parts built-in to the kernel - especially if you > > > want to use the HDMI output as the console. > > > > > > Binding CEC and audio into the component helper alongside the video part > > > will mean that nothing will come up until all the components are present, > > > and everything will be torn down when any one of those components are > > > removed. Clearly, that's undesirable. > > > > Currently i915/audio component works as you described. The audio is > > optional and HDMI graphics works without audio, while HDMI HD-audio > > mandates i915 graphics. > > Right, but we also add additional interface on top of this to allow things > like ensuring display is on when audio wants to run and now notification for > events. > > I don't see a reason why this can be used as single interface to bind as well > as talk to display from various components, unless I missed obvious which > prevent us from doing this in non i915 cases... Maybe I can comment more specifically if I saw the code. Right now all I'm aware of is this idea without any code, and I don't like it. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
