HDMI use the I2S0 as the audio input source, and DW-HDMI audio function
is based on generic hdmi-codec driver.
Change-Id: I6c85ffe7c214b17a3b5b319e4cd20e95a1b46398
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.
Change-Id: I32e95f66838883ac44a45f95c55583184a0a1b46
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am form https://patchwork.kernel.org/patch/9196453/)
Commit b360d3748e ("ASoC: hdmi-codec: callback function will be called
with private data") have introduced an external parameter in struct
hdmi_codec_ops, so need to fix the old interfaces.
Change-Id: Iaebd49ba7eb7fc0d857ff8aa8f9af39ea4678143
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Current hdmi-codec driver is assuming that it will be registered
from HDMI driver. Because of this assumption, each callback function
has struct device pointer which is parent device (= HDMI).
Then, it can use dev_get_drvdata() to get private data.
OTOH, on some SoC/HDMI case, SoC has VIDEO/SOUND and HDMI IPs.
This case, it needs SoC VIDEO, SoC SOUND and HDMI video, HDMI codec
driver. In DesignWare HDMI IP case, SoC VIDEO (= DRM/KMS) driver tries
to bind DesignWare HDMI video driver, and HDMI codec driver
(= hdmi-codec). This case, above "parent device" of HDMI codec driver
is DRM/KMS driver and its "device" already has private data.
And, from DT and ASoC CPU/Codec/Card binding point of view, HDMI codec
(= hdmi-codec) needs to have "parent device" (= DRM/KMS), otherwise,
it never detect sound card.
Because of these reasons, some driver can't use dev_get_drvdata() to
get private data on hdmi-codec driver. This patch add new void pointer
on hdmi_codec_pdata for private data, and callback function will be
called with it.
Change-Id: Ic7f4bb6cc06b5f7ce9a5a60f54566a780ddf1f65
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am form https://patchwork.kernel.org/patch/9196459/)
Due to the voltage ripple, the sensing data of the tsadc is not accurate.
And in this patch, the bandgap feature is enhanced to remove the voltage
ripple, and then the tsadc can sense the temperature more precisely.
Obsolete codes are removed as well.
Change-Id: Ifdd98def63212bc13306e7d5befee5eb32dbbc2f
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
There are some rates that would be ranged for better clock jitter at
Chrome OS tree, like 25.175Mhz would range to 25.170732Mhz.
But due to the clock is aglined to KHz in struct drm_display_mode,
this would bring some inaccurate error if we still run the compute_n
math, so let's just code an const table for it until we can actually
get the right clock rate.
Change-Id: Ief14b7c9bffa95ff3b173925f3e1bd795625320d
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/316280
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
The original math would bring some inaccurate to N/CTS that would
caused those magic number won't fit the HDMI 1.4 Spec request:
128 * SampleRate = Tmds * N / CTS;
So this time we try to improved to math of N that would find the
minimal inaccurate with the HDMI 1.4 Spec.
Change-Id: Ied3cde3c352d955ae6f15d5e7fb172e92316c2a5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/315424
Reviewed-by: Douglas Anderson <dianders@chromium.org>
We allow some amount of slop in dw_hdmi_rockchip_mode_valid(). That's
a good thing since allowing a little bit of slop lets us support a
bunch of extra resolutions.
Originally, we also made a change to the VOP code to add the concept
of slop in there. That was reasonable, but there was a problem: it
would tend to request clock rates that weren't _exactly_ clock rates
that we thought about. It's possible that the common clock framework
would map these to PLL rates that we haven't thought about and we
haven't tested for jitter.
Instead of changing VOP, we should probably adjust the clock ourselves
in the mode_fixup function. That way we'll request the exact clock we
tested and we'll know how the common clock framework will map it.
Change-Id: I56c2b046f76d554aab5eaed7a6b171ea074d6a62
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/284376
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Add a check just to make sure that someone doesn't try to give us a
pixel clock that is > 2GHz. If they did that, some of our math might
overflow, so it's good to make sure we don't do it.
Change-Id: I451602f0d771bb16b399b43e376e1054b7ee060f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/284642
Reviewed-by: Alexandru Stan <amstan@chromium.org>
This cleanup will allow the following patch to implement slop easier.
25175000-40000000 and a few other ranges use the same settings.
And the rest of the driver already snaps to the next highest
frequency when it gets the settings. So this patch removes
a lot of the duplicates. It should be a noop change.
And frequencies within 0.1% should be close enough, let's redo
rockchip hdmi to allow slop.
Change-Id: Ic4865b2825de9b6c3b3e8d029066a8964e8ede6b
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
rockchip_vpu_hw.c:251:5: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
Change-Id: Ia5564c2da345c5922341b818961b18d2b1419013
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
We enable it by default as we could see the usage of PCB layout
will not stuff this registor. For currently boards which soldered
it already, there should be no harmful.
Change-Id: Idc05c244dbaeebb1028e4828aa7a7d655899beb8
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Add missing kcontrol for HPVOL mute control.
Signed-off-by: John Lin <john.lin@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
(cherry picked from git.kernel.org broonie/sound.git for-next
commit d7fcd13663)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: I75951c4b67474951e6c033e0dece5134c51dc233
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Reference the TRM, the ALC5616 support one 24bit/8KHz ~ 192KHz
I2S/PCM Interface for stereo DAC and stereo ADC.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 27307957
Patchset: fetch the upstream ASoC for rk3036 kylin board.
(cherry picked from git.kernel.org broonie/sound.git for-next
commit 4e26ad80cb)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: I1751e2c663689d4a45cd94d609c0b61d1ac9237b
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
This patch adds the code to enable the clock to the CODEC driver
if it needs the clock enabled.
In some case, We need to claim the clock which is driving the codec
so that when we enable clock gating, we continue to clock the codec
when needed.
if mclk provided, to enable and disable the clock source.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 27307957
Patchset: fetch the upstream ASoC for rk3036 kylin board.
(cherry picked from git.kernel.org broonie/sound.git for-next
commit 76d3204eaa)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: Iaa1b07a1ff729f3b84c1e32cd0fdd0f36d9a8889
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
This patch try to fix the trivial typo.
Run "scripts/checkpatch.pl -f --subjective xxx"
The enable more subjective tests.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 27307957
Patchset: fetch the upstream ASoC for rk3036 kylin board.
(Note: match the Kconfig for rt5616)
(cherry picked friom git.kernel.org broonie/sound.git for-next
commit 99081589c5)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: Ied09a6f69a7364daa68309fa9a0a4cd2e4a368e6
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Rename some alsa control name as what they should be.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
Patchset: rt5616 audio
(cherry picked from broonie/sound.git#for-next e2133b6482)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I1d81031ddbe7ce5c38602c38ab643f893f436ef0
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Add a device tree match table. This serves to make the driver's support
of device tree more explicit.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
Patchset: rt5616 audio
(cherry picked from broonie/sound.git#for-next e17ff2de82)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I7ee1967a3cdf9583942c0d75b5e4d0125d31cd0c
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
This is the initial codec driver for rt5616.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
Patchset: rt5616 audio
(cherry picked from broonie/sound.git#for-next b1d1505995)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I17f99e549cb59a3788b257f63e51a84b3e9d4162
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Reference the power domain incase dw-mipi power down when
in use.
Change-Id: I54a0f418f20299a744f87c1337f06ff3341dfac5
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
We want to display a buffer allocated by other driver, need import
the buffer to gem.
Change-Id: Ifd5fef3fbf2b4daea6d624ed2a250c2fe626309d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
This adds a power supply type for special USB charger,
this kind of USB charger is similar to Dedicated Charging
Port, but not a standard DCP because of D+/D- not short.
Change-Id: I7c478da642b43465a9de65c8b5d7b8250c0da037
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
RK3399 SoC usb2 PHY comprises with one host-port and
one otg-port, we support otg-port for the time being.
Change-Id: I7d6a464372603e54c3a06d994e18d80eb84fa5a5
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.
Change-Id: I8f43e5c46c8559d6b6fe96a12cd026319b1d84e5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223317/)
For RK3399 HDMI, there is an external clock need for HDMI PHY,
and it should keep the same clock rate with VOP DCLK.
VPLL have supported the clock for HDMI PHY, but there is no
clock divider bewteen VPLL and HDMI PHY. So we need to set the
VPLL rate manually in HDMI driver.
Change-Id: I73abc382ff43bfa93d150c3449693f207029549f
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223327/)
RK3399 and RK3288 shared the same HDMI IP controller, only some light
difference with GRF configure.
Change-Id: Ic404ff3df6004a87b709f00552d91eb546c78450
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223315/)
The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor. Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway). It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.
In <http://crosreview.com/285855> I've gone through the work to figure
out how to generate this table automatically. Let's now use the
automatically generated table and then we'll never need to look at it
again.
We only support 8-bit mode right now and only support a small number
of clock rates and and I've verified that the only 8-bit rate that was
affected was 148.5. That mode appears to have been wrong in the old
table.
Change-Id: I42b260300880f2bab6732c5ee3b11bc78e87500c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
(am from https://patchwork.kernel.org/patch/9223325)
