Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Even though this is not a problem currently, it is better to clear the freed
pointer and nullify the length of the freed memory.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Add support for specifying video modes on the kernel command line. Mode
selection priorities are also changed such, that only exact matches of
specified modes with monitor modes from EDID are accepted, at least in width
and height. If none found - fall back to framebuffer default setting, if
available.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Add a default 720p mode to the sh_mobile_lcdc driver to be used, when no
videomode is specified in the platform data. This can be used, e.g., with HDMI.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

With this patch hot-plugging of an HDMI or a DVI monitor can select a different
video mode and reconfigure the LCDC and HDMI controllers accordingly. Due to a
lack of a standard API to inform framebuffer users of a changed video mode, the
framebuffer configuration is preserved regardless of a specific mode, selected
for the monitor. As described in a previous patch, this leads to smaller
framebuffers being displayed on larger monitors or a part of a larger
framebuffer being displayed on a smaller resolution monitor.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

High monitor resolutions also require higher clock frequencies, current HDMI
PHY parameters do not work well for resolutions higher than 720p.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Improve comments, unify function names, replace pr_debug with dev_dbg.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This is a preparation for a patch, that shall allow displaying of a smaller
framebuffer on a bigger display and of a part of a bigger framebuffer on a
smaller display.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The SH-Mobile HDMI driver runs in several contexts: ISR, delayed work-queue,
task context, when called from the sh_mobile_lcdc framebuffer driver. This
creates ample race possibilities. Even though most these races are purely
theoretical, it is better to close them. To trace fb_info validity we install a
notification callback in the HDMI driver, and the only way for it to get to
driver internal data is by using struct sh_mobile_lcdc_chan, therefore it had
to be extracted into a separate common header.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The SH-Mobile HDMI controller supports two configuration modes: using
pre-programmed VICs and the "external" mode - specifying video parameters
explicitly. The driver already contains code, necessary to configure HDMI
manually, this patch actually enables it.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

To support standard video modes, other than 720p, the HDMI PHY configuration
has to be adjusted and the VIC has to be sent to the display.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This is a preparation for HDMI hotplug support. This patch just moves all
platform defined video modes for the sh_mobile_lcdcfb driver to separate
arrays and switches all users to use element 0 of that array, so, this patch
doesn't introduce any functional changes and as such should not cause any
regressions.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The present SH-Mobile HDMI driver reads and parses the EDID block into a
variable screeninfo object, but since it is still unable to dynamically
reconfigure the framebuffer, it overwrites the EDID information with preset
values again. This patch just uses a temporary variable to store the EDID
timing information instead.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Current gamut, acp, isrc1, isrc2 settings are wrong,
and not necessary for now.
Tested-by: NTakanari Hayama <taki@igel.co.jp>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This patch solve below report from Guennadi

>  /* External video parameter settings */
>  static void hdmi_external_video_param(struct sh_hdmi *hdmi)
>  {
> @@ -804,6 +862,11 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  	}
>
> +	ret =  snd_soc_register_codec(&pdev->dev,
> +			&soc_codec_dev_sh_hdmi, &sh_hdmi_dai, 1);
> +	if (ret < 0)
> +		goto egetclk;
> +
>  	hdmi->dev = &pdev->dev;
>
>  	hdmi->hdmi_clk = clk_get(&pdev->dev, "ick");

NAK. This breaks the error path and has to be fixed. Firstly, please, use
a new label like "esndreg," secondly, you have to add

 	clk_disable(hdmi->hdmi_clk);
 erate:
 	clk_put(hdmi->hdmi_clk);
 egetclk:
+	snd_soc_unregister_codec(&pdev->dev);
+esndreg:
 	mutex_destroy(&hdmi->mutex);
 	kfree(hdmi);
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch solve below report from Guennadi

> +static struct snd_soc_dai_driver sh_hdmi_dai = {
> +	.name = "sh_mobile_hdmi-hifi",
> +	.playback = {
> +		.stream_name = "Playback",
> +		.channels_min = 1,

Can it actually do mono? Maybe at probe time you could look at audio flags
from your previous patch and, e.g., for SPDIF set channels_min to 2?

> +		.channels_max = 2,

That's the "smallest max," yes. With some other interfaces (I2S, DSD) it
can support up to 8 channels...

> +		.rates = SNDRV_PCM_RATE_8000_48000,

Hm, in the datasheet I see supported frequencies 32kHz to 192kHz. And if
you promise support for multiple frequencies, don't you want to implement
.hw_params? Besides, not all of these frequencies will be available,
depending on your supplied clock and your willingness to implement
downsampling.
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch solve below report from Guennadi

1)

> +/* Audio source select */
> +#define HDMI_SRC_MASK		(0xF << 0)
> +#define HDMI_SRC_I2S		(0 << 0) /* default */
> +#define HDMI_SRC_SPDIF		(1 << 0)
> +#define HDMI_SRC_DSD		(2 << 0)
> +#define HDMI_SRC_HBR		(3 << 0)

I would be more specific with these macro names, i.e., include "AUDIO" or
"SND" or something similar in them, e.g., HDMI_AUDIO_SRC_I2S.

2)

> +	case HDMI_SRC_I2S:
> +		data = (0x0 << 3);
> +		break;
> +	case HDMI_SRC_SPDIF:
> +		data = (0x1 << 3);
> +		break;
> +	case HDMI_SRC_DSD:
> +		data = (0x2 << 3);
> +		break;
> +	case HDMI_SRC_HBR:
> +		data = (0x3 << 3);

In all above cases parenthesis are superfluous.
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch solve below report from Guennadi

1)

> -	hdmi_write(hdmi, 0x00, HDMI_AUDIO_SETTING_1);
> +	switch (pdata->flags & HDMI_SRC_MASK) {
> +	default:
> +		/* FALL THROUGH */

I'm not sure I like the capitalisation here - no reason to shout;)

2)

> +/************************************************************************
> +
> +
> +			HDMI sound
> +
> +
> +************************************************************************/

I don't think this comment deserves 7 lines of text, besides breaking the
multiline comment style. If you think, one line like

/*			HDMI sound			*/

is not enough how about just

/*
 *			HDMI sound
 */

3)

> +/************************************************************************
> +
> +
> +			HDMI video
> +
> +
> +************************************************************************/

See above - 7 lines seem to be an overkill to me.
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Some SH-Mobile SoCs have an HDMI controller and a PHY, attached to one of their
LCDC interfaces. This patch adds a preliminary static support for such
controllers, this means, that only the 720p mode is handled ATM. Support for
more modes and a dynamic switching between them will be added by a follow up
patch.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>