On Wed, Jul 22, 2015 at 10:31:45PM +0200, Takashi Iwai wrote:
That depends on the device we register this with. Actually this makes more sense to me :)
If we register with struct device *audio_dev, which in this case would be the codec device we create while probing the bus. This way you are linking i915 ops to the codec device. Ofcourse hdac_device has bus pointer but you can invoke device callback without even searching for the device :)
It would require some extra setup, so I skipped it (at least for now).
I e, in order to detect codecs, we need to call hdac_i915 functions to turn the power well on. And in order to connect the codec to the i915_audio_component, we need to have detected a codec.
Yes that is true but when driver registers the callback you can assign the callback to i915 component, so afterwards the call from i915 lands up in codec. If not registered we have default bus handler :)
Which, now that I think of it, actually gives an interesting potential race condition, in case the following happens:
- Monitor is plugged in at boot time
- i915 initializes
- hda starts initializing and sets up the audio component
- i915 finishes initialization and as part of that, calls the hotplug
notify to let hda know that the monitor is plugged in. However, at this point, hda has not finished initialization yet, so there are no codecs that listen for this information.
Anyhow, this is not a problem really yet, but it might be if we ever decide to not write the ELD to the hardware.
For avoid such a problem, maybe we need two ops, one for notification and one for getting the assigned data. At the initialization time, the audio driver queries the assigned status and data. When a hotplug happens, it's just notified. That is, it simply replaces the current unsol event and the ELD data read via two ops.
Yeah, I do favour adding new ops so that we can query the current values and setup whenever driver probes