Message ID | ce10548e1c28270d80ee99a525e117d0d25f5656.1470129989.git.jsarha@ti.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote: > + memcpy(audio.status, params->iec.status, > + min(sizeof(audio.status), sizeof(params->iec.status))); As mentioned in the other patch, the audio status does not directly correspond with the AES bytes, so this ends up causing the driver to write the wrong bytes to the wrong registers. > + ret = tda998x_configure_audio(priv, > + &audio, > + priv->encoder.crtc->hwmode.clock); What happens if audio changes at the same time that the video mode changes? What protection is there against two threads concurrently executing tda998x_configure_audio() ? > + priv->audio_pdev = platform_device_register_data( > + dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO, > + &codec_data, sizeof(codec_data)); I'd much prefer that this was a child of the I2C device, which will show the relationship between this virtual platform device and the device which it's associated with. That can be done via platform_device_register_full(). Thanks.
On 08/04/16 17:07, Russell King - ARM Linux wrote: > On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote: >> + memcpy(audio.status, params->iec.status, >> + min(sizeof(audio.status), sizeof(params->iec.status))); > > As mentioned in the other patch, the audio status does not directly > correspond with the AES bytes, so this ends up causing the driver to > write the wrong bytes to the wrong registers. > As I said earlier, I'd rather have it as plain AES/IEC958 channel status bits buffer. >> + ret = tda998x_configure_audio(priv, >> + &audio, >> + priv->encoder.crtc->hwmode.clock); > > What happens if audio changes at the same time that the video mode > changes? What protection is there against two threads concurrently > executing tda998x_configure_audio() ? > Oh, yes. I definitely need some locking here. The same lock could protect the atomicity of tda998x_audio_params update and usage. >> + priv->audio_pdev = platform_device_register_data( >> + dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO, >> + &codec_data, sizeof(codec_data)); > > I'd much prefer that this was a child of the I2C device, which will > show the relationship between this virtual platform device and the > device which it's associated with. That can be done via > platform_device_register_full(). > That may be a problem. The ASoC card device tree binding current looks for the ASoC DAI's parent's of-node if it can not find the node for the DAI-device itself. Indicating ASoC DAI-link by referencing the parent i2c device simply won't work, because there may be other ASoC codecs on the same i2c bus. Adding a separate DT-node for a virtual audio device should be possible, but it needs some thinking and may have its own problems. I can not follow the reasoning behind this, is this really necessary? Best regards, Jyri
On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote: > On 08/04/16 17:07, Russell King - ARM Linux wrote: > > On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote: > >> + priv->audio_pdev = platform_device_register_data( > >> + dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO, > >> + &codec_data, sizeof(codec_data)); > > > > I'd much prefer that this was a child of the I2C device, which will > > show the relationship between this virtual platform device and the > > device which it's associated with. That can be done via > > platform_device_register_full(). > > > > That may be a problem. The ASoC card device tree binding current looks > for the ASoC DAI's parent's of-node if it can not find the node for the > DAI-device itself. I don't follow. The "parent" of this audio_pdev device above is the "platform" device - /sys/devices/platform. If ASoC is referencing the parent of the above platform device for some reason, it's probably not going to get anything useful from such an attempt. Any other ASoC codec driver where the codec platform device was declared with a NULL parent pointer also ends up as a child of that same location. I'd _really_ be surprised if ASoC is even doing what you describe, because such an action is totally illogical (as can be seen from my description above.) Moving it under the I2C device means it stays as a platform device, but the relationship between the platform device and its I2C parent is properly represented in the tree of devices, and also ensures that, should PM hooks be added, that the platform device gets properly ordered wrt the I2C device.
On Fri, Aug 05, 2016 at 05:48:45PM +0100, Russell King - ARM Linux wrote: > On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote: > > That may be a problem. The ASoC card device tree binding current looks > > for the ASoC DAI's parent's of-node if it can not find the node for the > > DAI-device itself. > I don't follow. The "parent" of this audio_pdev device above is > the "platform" device - /sys/devices/platform. If ASoC is > referencing the parent of the above platform device for some > reason, it's probably not going to get anything useful from such > an attempt. > Any other ASoC codec driver where the codec platform device was > declared with a NULL parent pointer also ends up as a child of > that same location. > I'd _really_ be surprised if ASoC is even doing what you describe, > because such an action is totally illogical (as can be seen from > my description above.) We do have some stuff in there in order to handle MFDs - they'll instantiate a Linux-internal virtual platform device as a child of the DT device that represents the device as a whole. We're definitely not expecting to find anything for parentless platform devices though, it's only done if the ASoC level device has no of_node and the parent does.
On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote: > On Fri, Aug 05, 2016 at 05:48:45PM +0100, Russell King - ARM Linux wrote: > > On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote: > > > > That may be a problem. The ASoC card device tree binding current looks > > > for the ASoC DAI's parent's of-node if it can not find the node for the > > > DAI-device itself. > > > I don't follow. The "parent" of this audio_pdev device above is > > the "platform" device - /sys/devices/platform. If ASoC is > > referencing the parent of the above platform device for some > > reason, it's probably not going to get anything useful from such > > an attempt. > > > Any other ASoC codec driver where the codec platform device was > > declared with a NULL parent pointer also ends up as a child of > > that same location. > > > I'd _really_ be surprised if ASoC is even doing what you describe, > > because such an action is totally illogical (as can be seen from > > my description above.) > > We do have some stuff in there in order to handle MFDs - they'll > instantiate a Linux-internal virtual platform device as a child of the > DT device that represents the device as a whole. We're definitely not > expecting to find anything for parentless platform devices though, it's > only done if the ASoC level device has no of_node and the parent does. And if we make the hdmi-codec device a child of the I2C device which does have an of-node, what will happen?
On Fri, Aug 05, 2016 at 06:04:50PM +0100, Russell King - ARM Linux wrote: > On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote: > > We do have some stuff in there in order to handle MFDs - they'll > > instantiate a Linux-internal virtual platform device as a child of the > > DT device that represents the device as a whole. We're definitely not > > expecting to find anything for parentless platform devices though, it's > > only done if the ASoC level device has no of_node and the parent does. > And if we make the hdmi-codec device a child of the I2C device which > does have an of-node, what will happen? It'll pick up that as the DT device to hang things off which I'd expect to be the desired outcome given that this is a very similar situation to the MFD situation. I've not been following the full thread so there is probably context I'm missing here...
On Fri, Aug 05, 2016 at 06:59:08PM +0100, Mark Brown wrote: > On Fri, Aug 05, 2016 at 06:04:50PM +0100, Russell King - ARM Linux wrote: > > On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote: > > > > We do have some stuff in there in order to handle MFDs - they'll > > > instantiate a Linux-internal virtual platform device as a child of the > > > DT device that represents the device as a whole. We're definitely not > > > expecting to find anything for parentless platform devices though, it's > > > only done if the ASoC level device has no of_node and the parent does. > > > And if we make the hdmi-codec device a child of the I2C device which > > does have an of-node, what will happen? > > It'll pick up that as the DT device to hang things off which I'd expect > to be the desired outcome given that this is a very similar situation to > the MFD situation. I've not been following the full thread so there is > probably context I'm missing here... Okay, and that sounds to me like a very reasonable thing to want to happen - so that the audio side can be clearly identified as being coupled with the video side. So, I'm not seeing a problem with my suggestion... I'm actually more reasons why it's a good thing to want.
On 08/06/16 01:19, Russell King - ARM Linux wrote: >> > It'll pick up that as the DT device to hang things off which I'd expect >> > to be the desired outcome given that this is a very similar situation to >> > the MFD situation. I've not been following the full thread so there is >> > probably context I'm missing here... > Okay, and that sounds to me like a very reasonable thing to want to > happen - so that the audio side can be clearly identified as being > coupled with the video side. > > So, I'm not seeing a problem with my suggestion... I'm actually more > reasons why it's a good thing to want. Ok, so getting back to this comment: >> + priv->audio_pdev = platform_device_register_data( >> > + dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO, >> > + &codec_data, sizeof(codec_data)); > I'd much prefer that this was a child of the I2C device, which will > show the relationship between this virtual platform device and the > device which it's associated with. That can be done via > platform_device_register_full(). The platform_device_register_data() sets the parent of the registered platform device according to the first parameter, the tda998x i2c-client in this case. Is there some reason why I should use platform_device_register_full() and should I set parent to something else than the tda998x i2c device? BR, Jyri
diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt b/Documentation/devicetree/bindings/display/bridge/tda998x.txt index e178e6b..24cc246 100644 --- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt +++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt @@ -21,8 +21,19 @@ Optional properties: - video-ports: 24 bits value which defines how the video controller output is wired to the TDA998x input - default: <0x230145> + - audio-ports: array of 8-bit values, 2 values per one DAI[1]. + The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S[2]. + The second value defines the tda998x AP_ENA reg content when the DAI + in question is used. The implementation allows one or two DAIs. If two + DAIs are defined, they must be of different type. + +[1] Documentation/sound/alsa/soc/DAI.txt +[2] include/dt-bindings/display/tda998x.h + Example: +#include <dt-bindings/display/tda998x.h> + tda998x: hdmi-encoder { compatible = "nxp,tda998x"; reg = <0x70>; @@ -30,4 +41,11 @@ Example: interrupts = <27 2>; /* falling edge */ pinctrl-0 = <&pmx_camera>; pinctrl-names = "default"; + video-ports = <0x230145>; + + #sound-dai-cells = <2>; + /* DAI-format AP_ENA reg value */ + audio-ports = < TDA998x_SPDIF 0x04 + TDA998x_I2S 0x03>; + }; diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig index 4d341db..a6c92be 100644 --- a/drivers/gpu/drm/i2c/Kconfig +++ b/drivers/gpu/drm/i2c/Kconfig @@ -22,6 +22,7 @@ config DRM_I2C_SIL164 config DRM_I2C_NXP_TDA998X tristate "NXP Semiconductors TDA998X HDMI encoder" default m if DRM_TILCDC + select SND_SOC_HDMI_CODEC if SND_SOC help Support for NXP Semiconductors TDA998X HDMI encoders. diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index f97b748..bd720cc 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -20,6 +20,7 @@ #include <linux/module.h> #include <linux/irq.h> #include <sound/asoundef.h> +#include <sound/hdmi-codec.h> #include <drm/drmP.h> #include <drm/drm_atomic_helper.h> @@ -30,6 +31,11 @@ #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) +struct tda998x_audio_port { + u8 format; /* AFMT_xxx */ + u8 config; /* AP value */ +}; + struct tda998x_priv { struct i2c_client *cec; struct i2c_client *hdmi; @@ -43,6 +49,8 @@ struct tda998x_priv { u8 vip_cntrl_2; struct tda998x_audio_params audio_params; + struct platform_device *audio_pdev; + wait_queue_head_t wq_edid; volatile int wq_edid_wait; @@ -53,6 +61,8 @@ struct tda998x_priv { struct drm_encoder encoder; struct drm_connector connector; + + struct tda998x_audio_port audio_port[2]; }; #define conn_to_tda998x_priv(x) \ @@ -743,7 +753,7 @@ tda998x_configure_audio(struct tda998x_priv *priv, break; default: - BUG(); + dev_err(&priv->hdmi->dev, "Unsupported I2S format\n"); return -EINVAL; } @@ -1160,6 +1170,8 @@ static int tda998x_connector_get_modes(struct drm_connector *connector) drm_mode_connector_update_edid_property(connector, edid); n = drm_add_edid_modes(connector, edid); priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid); + drm_edid_to_eld(connector, edid); + kfree(edid); return n; @@ -1181,6 +1193,9 @@ static void tda998x_destroy(struct tda998x_priv *priv) cec_write(priv, REG_CEC_RXSHPDINTENA, 0); reg_clear(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD); + if (priv->audio_pdev) + platform_device_unregister(priv->audio_pdev); + if (priv->hdmi->irq) free_irq(priv->hdmi->irq, priv); @@ -1190,8 +1205,180 @@ static void tda998x_destroy(struct tda998x_priv *priv) i2c_unregister_device(priv->cec); } +static int tda998x_audio_hw_params(struct device *dev, void *data, + struct hdmi_codec_daifmt *daifmt, + struct hdmi_codec_params *params) +{ + struct tda998x_priv *priv = dev_get_drvdata(dev); + int i, ret; + struct tda998x_audio_params audio = { + .sample_width = params->sample_width, + .sample_rate = params->sample_rate, + .cea = params->cea, + }; + + if (!priv->encoder.crtc) + return -ENODEV; + + memcpy(audio.status, params->iec.status, + min(sizeof(audio.status), sizeof(params->iec.status))); + + switch (daifmt->fmt) { + case HDMI_I2S: + if (daifmt->bit_clk_inv || daifmt->frame_clk_inv || + daifmt->bit_clk_master || daifmt->frame_clk_master) { + dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__, + daifmt->bit_clk_inv, daifmt->frame_clk_inv, + daifmt->bit_clk_master, + daifmt->frame_clk_master); + return -EINVAL; + } + for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++) + if (priv->audio_port[i].format == AFMT_I2S) + audio.config = priv->audio_port[i].config; + audio.format = AFMT_I2S; + break; + case HDMI_SPDIF: + for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++) + if (priv->audio_port[i].format == AFMT_SPDIF) + audio.config = priv->audio_port[i].config; + audio.format = AFMT_SPDIF; + break; + default: + dev_err(dev, "%s: Invalid format %d\n", __func__, daifmt->fmt); + return -EINVAL; + } + + if (audio.config == 0) { + dev_err(dev, "%s: No audio configutation found\n", __func__); + return -EINVAL; + } + + ret = tda998x_configure_audio(priv, + &audio, + priv->encoder.crtc->hwmode.clock); + + if (ret == 0) + priv->audio_params = audio; + + return ret; +} + +static void tda998x_audio_shutdown(struct device *dev, void *data) +{ + struct tda998x_priv *priv = dev_get_drvdata(dev); + + reg_write(priv, REG_ENA_AP, 0); + + priv->audio_params.format = AFMT_UNUSED; +} + +int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable) +{ + struct tda998x_priv *priv = dev_get_drvdata(dev); + + tda998x_audio_mute(priv, enable); + + return 0; +} + +static int tda998x_audio_get_eld(struct device *dev, void *data, + uint8_t *buf, size_t len) +{ + struct tda998x_priv *priv = dev_get_drvdata(dev); + struct drm_mode_config *config = &priv->encoder.dev->mode_config; + struct drm_connector *connector; + int ret = -ENODEV; + + mutex_lock(&config->mutex); + list_for_each_entry(connector, &config->connector_list, head) { + if (&priv->encoder == connector->encoder) { + memcpy(buf, connector->eld, + min(sizeof(connector->eld), len)); + ret = 0; + } + } + mutex_unlock(&config->mutex); + + return ret; +} + +static const struct hdmi_codec_ops audio_codec_ops = { + .hw_params = tda998x_audio_hw_params, + .audio_shutdown = tda998x_audio_shutdown, + .digital_mute = tda998x_audio_digital_mute, + .get_eld = tda998x_audio_get_eld, +}; + +static int tda998x_audio_codec_init(struct tda998x_priv *priv, + struct device *dev) +{ + struct hdmi_codec_pdata codec_data = { + .ops = &audio_codec_ops, + .max_i2s_channels = 2, + }; + int i; + + for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++) { + if (priv->audio_port[i].format == AFMT_I2S && + priv->audio_port[i].config != 0) + codec_data.i2s = 1; + if (priv->audio_port[i].format == AFMT_SPDIF && + priv->audio_port[i].config != 0) + codec_data.spdif = 1; + } + + priv->audio_pdev = platform_device_register_data( + dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO, + &codec_data, sizeof(codec_data)); + + return PTR_ERR_OR_ZERO(priv->audio_pdev); +} + /* I2C driver functions */ +static int tda998x_get_audio_ports(struct tda998x_priv *priv, + struct device_node *np) +{ + const u32 *port_data; + u32 size; + int i; + + port_data = of_get_property(np, "audio-ports", &size); + if (!port_data) + return 0; + + size /= sizeof(u32); + if (size > 2 * ARRAY_SIZE(priv->audio_port) || size % 2 != 0) { + dev_err(&priv->hdmi->dev, + "Bad number of elements in audio-ports dt-property\n"); + return -EINVAL; + } + + size /= 2; + + for (i = 0; i < size; i++) { + u8 afmt = be32_to_cpup(&port_data[2*i]); + u8 ena_ap = be32_to_cpup(&port_data[2*i+1]); + + if (afmt != AFMT_SPDIF && afmt != AFMT_I2S) { + dev_err(&priv->hdmi->dev, + "Bad audio format %u\n", afmt); + return -EINVAL; + } + + priv->audio_port[i].format = afmt; + priv->audio_port[i].config = ena_ap; + } + + if (priv->audio_port[0].format == priv->audio_port[1].format) { + dev_err(&priv->hdmi->dev, + "There can only be on I2S port and one SPDIF port\n"); + return -EINVAL; + } + return 0; +} + static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) { struct device_node *np = client->dev.of_node; @@ -1305,7 +1492,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) if (!np) return 0; /* non-DT */ - /* get the optional video properties */ + /* get the device tree parameters */ ret = of_property_read_u32(np, "video-ports", &video); if (ret == 0) { priv->vip_cntrl_0 = video >> 16; @@ -1313,8 +1500,14 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) priv->vip_cntrl_2 = video; } - return 0; + ret = tda998x_get_audio_ports(priv, np); + if (ret) + goto fail; + if (priv->audio_port[0].format != AFMT_UNUSED) + tda998x_audio_codec_init(priv, &client->dev); + + return 0; fail: /* if encoder_init fails, the encoder slave is never registered, * so cleanup here: diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h index 24be7aa..b575332 100644 --- a/include/drm/i2c/tda998x.h +++ b/include/drm/i2c/tda998x.h @@ -1,9 +1,9 @@ #ifndef __DRM_I2C_TDA998X_H__ #define __DRM_I2C_TDA998X_H__ +#include <dt-bindings/display/tda998x.h> + #define AFMT_UNUSED 0 -#define AFMT_SPDIF 1 -#define AFMT_I2S 2 struct tda998x_audio_params { u8 config; diff --git a/include/dt-bindings/display/tda998x.h b/include/dt-bindings/display/tda998x.h new file mode 100644 index 0000000..38ef741 --- /dev/null +++ b/include/dt-bindings/display/tda998x.h @@ -0,0 +1,7 @@ +#ifndef _DT_BINDINGS_TDA998X_H +#define _DT_BINDINGS_TDA998X_H + +#define AFMT_SPDIF 1 +#define AFMT_I2S 2 + +#endif /*_DT_BINDINGS_TDA998X_H */
Register ASoC HDMI codec for audio functionality and adds device tree binding for audio configuration. With the registered HDMI codec the tda998x node can be used like a regular codec node in ASoC card configurations. HDMI audio info-frame and audio stream header is generated by the ASoC HDMI codec. The codec also applies constraints for available sample-rates based on Edid Like Data from the display. The device tree binding document has been updated [1]. Part of this patch has been inspired by Jean Francoise's "drm/i2c: tda998x: Add support of a DT graph of ports"-patch [2]. There may still be some identical lines left from the original patch and some of the ideas have come from there. [1] Documentation/devicetree/bindings/display/bridge/tda998x.txt [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/095255.html Signed-off-by: Jyri Sarha <jsarha@ti.com> --- .../devicetree/bindings/display/bridge/tda998x.txt | 18 ++ drivers/gpu/drm/i2c/Kconfig | 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 199 ++++++++++++++++++++- include/drm/i2c/tda998x.h | 4 +- include/dt-bindings/display/tda998x.h | 7 + 5 files changed, 224 insertions(+), 5 deletions(-) create mode 100644 include/dt-bindings/display/tda998x.h