On Fri, Jun 21, 2019 at 5:12 AM Daniel Vetter daniel@ffwll.ch wrote:
Massively cutting this thread, since halfway through in my previous reply I realized that maybe hdmi_codec is a much better starting point.
ACK
On Thu, Jun 20, 2019 at 09:23:23PM +0800, Cheng-yi Chiang wrote:
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter daniel@ffwll.ch wrote:
Yeah fully agreeing that hdmi_audio_code is probably a better starting point. Problem is that becuase hdmi_codec is built on top of platform device it's quite a bit harder to extend with callbacks and things like that, without breaking the driver model.
I need to think about this more, but if all we need to look at is hdmi_codec, then I think this becomes a lot easier. And we can ignore drm_audio_component.h completely.
It is surprising that you think this way. Maybe the original patch before hdmi-notifier was introduced is the better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
Hm, this doesn't seem to be the hdmi_codec driver I meant, but another, new one. I was talking about SND_SOC_HDMI_CODEC.
Yes you are right. They are different codec drivers. Sorry for the confusion. What I meant was that my use case on RK3288 was using dw-hdmi-audio.c codec driver, which was later replaced by a more general version hdmi-codec.c.
There was a callback mechanism implemented between dw-hdmi and hdmi codec driver. It was later consolidated by Doug in this patch for better jack status reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3...
Hm that still seems entirely separate hdmi-codec specific to dw-hdmi only ...
Again you are right. Sorry for the confusion. What I meant is that this callback mechanism should work on hdmi-codec.c driver as well.
I am not sure why the original patch series did not get fully accepted in the upstream. It was quite long time ago.
But if you think this might be the right way to do, then it is even better for us because the patch series and Doug's patch had been quite stable on our RK3288 products for about four years with plenty of users, so we have much higher confidence in them. I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better. Thanks again!
Not sure we're talking about the same. What I had in mind is to add jack status to the hdmi-codec.c stuff, which is used by multiple soc drm display drivers already. Looking at git grep output, there seems to be already some support for dw-hdmi synopsys drm_bridge driver. I thought of extending that. Does that not work for you?
I think extending current interface will work. There is a struct hdmi_codec_pdata to let ALSA codec driver access some ops through platform data. And after this patch
https://lore.kernel.org/patchwork/patch/692324/
ALSA codec driver can get access to the struct on DRM side. Based on this I can add a new ops to register callback function for jack status. It will be similar to Doug's chromium patch above. I think that is quite a feasible way, and can benefit all boards using hdmi-codec.c.
Thanks a lot!!
Thanks, Daniel
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch