According to a description from TRM, add all the power domains.
Change-Id: Id21e1b51825f7cc94e194e164583ed2584743104
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
This patch supported the cpu voltage by changed with different
frequency, otherwise we will hit the following error on bootup.
..
[ 5.031516] cpu cpu0: Failed to get cpu_reg
[ 5.047725] cpu cpu0: clk or regulater is unavailable
..
Also, remove the 408M and 600M for rk3036 board, as the pclk_hdmi's parent
on apll, the low frequency will make the pclk be bad for hdmi display.
Change-Id: Ia4aac76a08cad3a59c33cd81065f943201a23a35
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
HDR source metadata set and get property implemented in this
patch. The blob data is received from userspace and saved in
connector state, the same is returned as blob in get property
call to userspace.
Change-Id: Iafde7d4d4a9567d54b283d8387d841e42d7b5b24
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from list https://patchwork.kernel.org/patch/9756449/)
The hdr_panel_metadata indicate sink HDR capability，moving
it to drm_hdmi_info is more reasonable.
Change-Id: I0ccd404cfb0ec1e74130b0692de4261ae9a24c8f
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Change-Id: I8025c3dba43dc5bb614115ede7841fe89d9f4d0b
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9756447/)
This patch fixes the BT power reported the failure message.
As following:
root@linaro-alip:~# echo 1 > /sys/class/rfkill/rfkill0/state
[ 892.558269] rockchip-pinctrl pinctrl: pin gpio0-19 already requested
by 20060000.serial; cannot claim for wireless-bluetooth
[ 892.571052] rockchip-pinctrl pinctrl: pin-19 (wireless-bluetooth) status -22
...
And for now, the BT can work with this patch.
root@linaro-alip:~# echo 1 > /sys/class/rfkill/rfkill0/state
[ 69.328768] [BT_RFKILL]: ENABLE UART_RTS
[ 69.438540] [BT_RFKILL]: DISABLE UART_RTS
[ 69.443117] [BT_RFKILL]: bt turn on power
...
root@linaro-alip:~# hcitool dev
Devices:
hci0 94:A1:A2:E9:2D:18
And
root@linaro-alip:~# bluetoothctl
[NEW] Controller 94:A1:A2:E9:2D:18 linaro-alip [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 94:A1:A2:E9:2D:18 Discovering: yes
..
Change-Id: I2148f4203300ab4265fd3ba718f0d3ec0c57e7ca
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
select CFG80211 and MAC80211 when CONFIG_WIFI_BUILD_MODULE is set
Change-Id: I42acf5d554223b13c0c689b8edae15b4a7a57a70
Signed-off-by: Alex Zhao <zzc@rock-chips.com>
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>
