The recent CTO timer introduced in commit 03de19212e ("mmc: dw_mmc:
introduce timer for broken command transfer over scheme") was causing
observable problems due to race conditions. Previous patches have
fixed those race conditions.
It can be observed that these same race conditions ought to be
theoretically possible with the DTO timer too though they are
massively less likely to happen because the data timeout is always set
to 0xffffff right now. That means even at a 200 MHz card clock we
were arming the DTO timer for 94 ms:
>>> (0xffffff * 1000. / 200000000) + 10
93.886075
We always also were setting the DTO timer _after_ starting the
transfer, unlike how the old code was seting the CTO timer.
In any case, even though the DTO timer is much less likely to have
races, it still makes sense to add code to handle it _just in case_.
Change-Id: I87a1707399b64d43278239ddd830c3270402239a
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002771/)
Just like the CTO timeout calculation introduced recently, the DTO
timeout calculation was incorrect. It used "bus_hz" but, as far as I
can tell, it's supposed to use the card clock. Let's account for the
div value, which is documented as 2x the value stored in the register,
or 1 if the register is 0.
NOTE: This was likely not terribly important until commit 16a34574c6
("mmc: dw_mmc: remove the quirks flags") landed because "DIV" is
documented on Rockchip SoCs (the ones that used to define the quirk)
to always be 0 or 1. ...and, in fact, it's documented to only be 1
with EMMC in 8-bit DDR52 mode. Thus before the quirk was applied to
everyone it was mostly OK to ignore the DIV value.
I haven't personally observed any problems that are fixed by this
patch but I also haven't tested this anywhere with a DIV other an 0.
AKA: this problem was found simply by code inspection and I have no
failing test cases that are fixed by it. Presumably this could fix
real bugs for someone out there, though.
Change-Id: I0d81f991e10e60b8d03ee330b34d08af34a33fcb
Fixes: 16a34574c6 ("mmc: dw_mmc: remove the quirks flags")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002751/)
This attempts to instill a bit of paranoia to the code dealing with
the CTO timer. It's believed that this will make the CTO timer more
robust in the case that we're having very long interrupt latencies.
Note that I originally thought that perhaps this patch was being
overly paranoid and wasn't really needed, but then while I was running
mmc_test on an rk3399 board I saw one instance of the message:
dwmmc_rockchip fe320000.dwmmc: Unexpected interrupt latency
I had debug prints in the CTO timer code and I found that it was
running CMD 13 at the time.
...so even though this patch seems like it might be overly paranoid,
maybe it really isn't?
Presumably the bad interrupt latency experienced was due to the fact
that I had serial console enabled as serial console is typically where
I place blame when I see absurdly large interrupt latencies. In this
particular case there was an (unrelated) printout to the serial
console just before I saw the "Unexpected interrupt latency" printout.
...and actually, I managed to even reproduce the problems by running
"iw mlan0 scan > /dev/null" while mmc_test was running. That not only
does a bunch of PCIe traffic but it also (on my system) outputs some
SELinux log spam.
Change-Id: I56373c6740d38b5c45a078e835f594261bad78d2
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002767/)
In the commit 03de19212e ("mmc: dw_mmc: introduce timer for broken
command transfer over scheme") we tried to calculate the expected
hardware command timeout value. Unfortunately that calculation isn't
quite correct in all cases. It used "bus_hz" but, as far as I can
tell, it's supposed to use the card clock. Let's account for the div
value, which is documented as 2x the value stored in the register, or
1 if the register is 0.
NOTE: It's not expected that this will actually fix anything important
since the 10 ms margin added by the function will pretty much dwarf
any calculations. The card clock should be 100 kHz at minimum and:
1000 ms/s * (255 * 2) / 100000 Hz.
Gives us 5.1 ms.
...so really the point of this patch is just to make the code more
"correct" in case anyone ever tries to remove the 10 ms buffer.
Change-Id: Ie5d902edb3a5bdfb9dc9233eb46edbbee334994c
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002775/)
When running with the commit 03de19212e ("mmc: dw_mmc: introduce
timer for broken command transfer over scheme") I found this message
in the log:
Unexpected command timeout, state 7
It turns out that we weren't properly cancelling the new CTO timer in
the case that a voltage switch was done. Let's promote the cancel
into the dw_mci_cmd_interrupt() function to fix this.
Change-Id: I2ee3537eb7a756d64964cc49114011ad329409b8
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002779/)
Also:
- correct the default quantization for RGB input, it should be full range.
Change-Id: I786799a3532b5c3a18e67c9195ec24ea811d1144
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Introduce mtmdsclock to record tmds clock, which is different
to mpixelclock in deep color mode. Use this variable to select
synopsys phy curr_ctrl/phy_config, and audio N/CTS.
Change-Id: Ia78dee9c4901d2f1ca7f339dfb030d65bbf6861d
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch is based on https://patchwork.kernel.org/patch/9801533,
add the drm property "hdmi_output_format", the possible value
could be:
- RGB
- YCBCR 444
- YCBCR 422
To handle various subsampling of YCBCR output types, this property
allows two special automatic cases:
- DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output,
with highest subsampling rate by the source/sink, which
can be typically:
- ycbcr444
- ycbcr422
- ycbcr420
- DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with
lowest subsampling rate supported by source/sink, which can be:
- ycbcr420
- ycbcr422
- ycbcr444
Default value of the property is set to 0 = RGB, so no changes if you
don't set the property.
Change-Id: Ie4a98ba91c8285a2e8f1ec7832d73183ad57665e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch introduce a drm property hdmi_output_depth to
get/set HDMI color depth, the possible value could be
- Automatic
This indicates prefer highest color depth, it is
30bit on rockcip platform.
- 24bit
- 30bit
The default value of property is 24bit.
The max_tmds_clock is 0 on some display device, we think it's
max_tmds_clock is 340MHz.
If tmdsclock > max_tmds_clock, real output color depth fallback
to 24bit.
Change-Id: I666ac85d1ce5e73af31251eae324d1a6ae00b31e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Add supports-emmc for emmc; supports-sd for sdcard; supports-sdio for
wifi.
Change-Id: I13d3918f41f63ed9b27e9969e6f89d1006c9d45c
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
HDMI can't display afer resume, because HDMI 5v was turn off.
This patch fix up this problem.
Change-Id: Id48ca0616b81ea27416dc733662f388d51b2643c
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
HDMI can't display afer resume, because HDMI 5v was turn off.
This patch fix up this problem.
Change-Id: Ia3994c756324043d1c71c7840ed3ff2a303af523
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
HDMI can't display afer resume, because HDMI 5v was turn off.
This patch fix up this problem.
Change-Id: Ib43893cdbdafec2cf264c724d5c56e9e0f63d8b5
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
According to HDMI2.0 spec table 10-6, DC_48bit_420/DC_36bit_420/
DC_30bit_420 is at bit2~bit0 of HDMI Fortum Vendor Specific Data
Block byte7.
Change-Id: Iab2748695c68b950617955132579a3c12476cc5b
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
There is no media type for YUV444 output. so when bus format is yuv,
and out_mode is AAAA or P888, assume output is YUV444.
From H/W testing, YUV444 mode need a rb swap.
Change-Id: I1191df702ebe4afc107cf321fe5381be4f07eb7b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
porting from kernel 3.10, it includes fuel gauge and charger.
Change-Id: Ib1dbc6a2c869a44459570f5368900e9dbfe93ed0
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Application need to listen HDMI connector state when connector is
forced on/off, so we add switch_set_stat in dw_hdmi_connector_force.
Change-Id: I2b76a0a647eb6a4cfde7584e085f53540d0fa27f
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
According to HDMI spec 1.4, YCbCr422 is also 36-bit mode, so
we remove the override of color format when parsing hdmi deep
color info. And record hdmi YCbCr444 deep color info in
edid_hdmi_dc_modes.
The edid_hdmi_dc_modes should be clean up when parsing EDID.
Change-Id: Ic5bd3ff5e50b37f04ed4a0688be68bd8259e5af0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
It allows me to set the mac address in the bootloader.
Change-Id: Iad988205c6953e843e62aec67daad52128086324
Signed-off-by: Randy Li <randy.li@rock-chips.com>
There is a combo of a HEVC decoder and a VPU1 decoder at rk3036.
Change-Id: Ia7174cc9e2f2d640a74271077bd62cc68f3482b4
Signed-off-by: Randy Li <randy.li@rock-chips.com>
From rk3288 vop version register, rk3288 vop version is 3.0
Change-Id: Ib7e40ec93792290a8ea6e350bb7fdcfeeb697ec6
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The version of RK3288 HDMI is 0x200a, it doesn't support ycbcr420 mode.
Change-Id: I65ee16ae79f42fd13514db8e5819db6d07db9d3d
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Comparing to the latest the ion driver, the vmap() or
vunmap() are not supported yet, but at least it would
be more easy to implement the sync function.
I didn't remove those legacy iommu code this time, I just
add this patch to make the functions I want work.
Change-Id: Id7731fd44b729338c0a0059a1517bfe1333391e8
Signed-off-by: Randy Li <randy.li@rock-chips.com>
RK3128 and RK3126 failed to read vop iommu register, it is SoC bug.
Add this patch as a workaround for this bug, make SoC work as normal
Change-Id: I44d4ef7f6e15f85a466563b0b3e8e091db23fba0
Signed-off-by: Simon Xue <xxm@rock-chips.com>
set 1 if the regulator is enabled in system suspend, 0 if not.
Change-Id: I8d51ac685bbd2417f440842d010fe47946c9f567
Signed-off-by: shengfei Xu <xsf@rock-chips.com>
