dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jyri Sarha <jsarha@ti.com>
To: Arnaud Pouliquen <arnaud.pouliquen@st.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Cc: "moinejf@free.fr" <moinejf@free.fr>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Takashi Iwai <tiwai@suse.de>,
	"tomi.valkeinen@ti.com" <tomi.valkeinen@ti.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"peter.ujfalusi@ti.com" <peter.ujfalusi@ti.com>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"tony@atomide.com" <tony@atomide.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"bcousson@baylibre.com" <bcousson@baylibre.com>
Subject: Re: [RFC 3/5] ASoC: codec: hdmi drm codec driver
Date: Tue, 29 Sep 2015 16:53:44 +0300	[thread overview]
Message-ID: <560A97E8.4050303@ti.com> (raw)
In-Reply-To: <56056D52.3@st.com>

On 09/25/15 18:50, Arnaud Pouliquen wrote:
> Hello Jyri,
>
> Yes using or not DRM bridge we should be able to have a common
> implementation
>
> Please find,my answer belows
>
> BR,
> Arnaud
>
> On 09/25/2015 04:11 PM, Jyri Sarha wrote:
>> Despite my earlier comment this implementation and the related HW is
>> quite similar in all significant aspects to the patch set posted couple
>> of days ago [1] for Beaglebone-Black HDMI audio.
>>
>> [1] http://permalink.gmane.org/gmane.linux.alsa.devel/144144
> yes i trying to align my dev on it. to match with your development.
> Aim for me is to reuse it and adapt it using a DRM bridge interface.
> i hope to provide a V2 next week.
>>
>> I have not yet gotten to bottom of drm-side audio bride part, but I am
>> working on it. Bellow is couple of early comments to the ASoC part.
>>
>> Best regards,
>> Jyri
>>
>> On 09/21/15 16:19, Arnaud Pouliquen wrote:
>>> +
>>> +static int st_hdmi_dai_probe(struct snd_soc_dai *dai)
>>> +{
>>> +    struct hdmi_drm_dai_data *priv;
>>> +
>>> +    dev_err(dai->dev, "%s: enter\n", __func__);
>>> +    priv = devm_kzalloc(dai->dev, sizeof(*priv), GFP_KERNEL);
>>> +
>>> +    priv->bridge = of_drm_find_bridge(dai->dev->of_node);
>>> +
>>> +    dev_err(dai->dev, "%s: bridge %p\n", __func__, priv->bridge);
>>> +
>>> +    snd_soc_dai_set_drvdata(dai, priv);
>>> +
>>
>> The call above overwrites the private data pointer of the drivers that
>> registering the codec. This hardly works in general.
>>
>> A separate platform driver - with this already merged patch [2] - that I
>> use with my patch-set solves this issue quite nicely.
>>
>> [2] http://lists.freedesktop.org/archives/dri-devel/2015-May/083517.html
> Yes same dev,(but no crash...?).i need to define sub node.
>>> +    return 0;
>>> +}here are several important callbacks missing here
>>> +
>>> +static const struct snd_soc_dai_ops hdmi_drm_codec_ops = {
>>> +        .prepare =  hdmi_drm_dai_prepare,
>>> +        .trigger = hdmi_drm_dai_trigger,
>>> +};
>>
>>
>> At least set_daifmt() and hw_params() callbacks should be defined before
>> this could be generally usable. HDMI encoders do not usually support too
>> many daifmts, but the driver should be able the check that the selected
>> format is supported. But as you said this not complete code yet.
> I'm trying to match codec ops with following DRM audio bridge ops,
> that is similar to the existing drm_bridge_funcs structure.

I am not yet too familiar with drm way of doing things. My code is 
trying to follow the way how ALSA does things. I tried to survive with 
as few callback as possible, but if you think more is needed I can add 
those if there is a corresponding callback in ALSA.

> struct drm_audio_bridge_funcs {
>      void (*disable)(struct drm_bridge *bridge);

There is no such thing in my HDMI codec. However, there is digital_mute 
callback that is used by alsa before the streams are shut down to avoid 
undesired pops and clicks.

>      void (*post_disable)(struct drm_bridge *bridge);

Post_disable should map more or less directly to audio_shutdown() in my 
code.

>      void (*pre_enable)(struct drm_bridge *bridge);

audio_startup() and hw_params() should both be called at pre_enable() 
phase.

>      void (*enable)(struct drm_bridge *bridge);

... or one could see hw_params() to map to enable. And there is 
digital_mute which is toggled by ALSA at this phase.

>      int  (*mode_set)(struct drm_bridge *bridge,
>              struct hdmi_audio_mode *mode);

Actually hw_params() does pretty much the same thing as set_mode(), but 
it should be called after audio_startup() has been called.

>      uint8_t *(*mode_get)(struct drm_bridge *bridge); /*return eld*/
> };

For this there is get_eld() in my HDMI codec code.

> audio parameters should be part of struct hdmi_audio_mode that contains
> audio configurations ( info frame,iec, format, clk...)
>
>

BTW, the HDMI codec is made in such a way that one can get by with only 
hw_params() and audio_shutdown(). In such an implementation hw_params() 
sets the HDMI encoder ready for receiving i2s or spdif from CPU DAI and 
audio_shutdown() disables the audio stream.

Best regards,
Jyri

  reply	other threads:[~2015-09-29 13:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-21 13:19 [RFC 0/5] another generic audio hdmi codec proposal Arnaud Pouliquen
2015-09-21 13:19 ` [RFC 1/5] video: hdmi: add help function for N and CTS Arnaud Pouliquen
2015-09-21 13:19 ` [RFC 2/5] drm: add helper functions to add bridge audio capabilities Arnaud Pouliquen
2015-09-21 13:19 ` [RFC 3/5] ASoC: codec: hdmi drm codec driver Arnaud Pouliquen
2015-09-25 14:11   ` Jyri Sarha
2015-09-25 15:50     ` Arnaud Pouliquen
2015-09-29 13:53       ` Jyri Sarha [this message]
2015-09-21 13:19 ` [RFC 4/5] drm: sti: connect audio driver Arnaud Pouliquen
2015-09-21 13:19 ` [RFC 5/5] DT: sti: add audio HDMI dai link in audio card Arnaud Pouliquen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=560A97E8.4050303@ti.com \
    --to=jsarha@ti.com \
    --cc=airlied@linux.ie \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=bcousson@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux@arm.linux.org.uk \
    --cc=moinejf@free.fr \
    --cc=peter.ujfalusi@ti.com \
    --cc=tiwai@suse.de \
    --cc=tomi.valkeinen@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox