Add the ability to parse panel-desc data from the devicetree if it's
not hard-coded data.
Change-Id: I474940282657c9aa03568b9f98916125784d9fcf
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The video BIST function of the DP_TX generates arbitrary video formats
internally according to the specified format configuration and selection.
These BIST video formats simplify DP_TX debugging.
Change-Id: Ia019c8f40fdd4ebea3e5250be8e2c15540481a6c
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Sometimes, we would abort suspend work before it finished.
In this case, suspend work would try to resume the part suspended
by correspond resume functions.
But the suspend/resume functions are not matched in rockchip.
When the suspend work is aborted, it would ignored resuming this
part due to can't find correspond resume functions.
So, let's use suspend_late instead of suspend.
Change-Id: I7304f7963704de7e870fbd4e76ebe1e0066f18c1
Signed-off-by: zain wang <wzz@rock-chips.com>
VOP output mode and bus_format must be ROCKCHIP_OUT_MODE_YUV420
and MEDIA_BUS_FMT_YUV8_1X24 when display mode has a YCbCr420
flag.
Change-Id: Ib2d51c119f5a8f1b8a9285c47ab228b22a293d56
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
If sink max TMDS clock < 340MHz, we think the mode pixel clock
greater than 340MHz should support YCbCr420, or it is a bad mode.
Change-Id: I3930e943f5bdf7ca86b3e719c55e6aa57e8eff53
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
The current EDID might not support advanced HDMI 2.0 features.
Leaving old hdmi info in the drm_display_info will make display
work not okay, when switching display from HDMI 2.0 device to
HDMI 1.4 device.
Change-Id: Ifaf11a115580a93ec00160d54f0d453842d7b484
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
close pd when suspend, no when plug out because hotplug detect need it.
make hdmi probe before dp otherwise the shared power domain will be
close after dp probe and cause splash screen when starting kernel if
hdmi uboot logo display
Change-Id: I82ba1abdaf7567173df9ad900d57eca0e6be3932
Signed-off-by: xuhuicong <xhc@rock-chips.com>
HDMI PD is power off when system suspend, so ih_mute register
bit0 mute_all_interrupt will be reset to 1 when system resume.
HPD interrupt will be mask, that would cause hdmi plugin could
not be detected.
Change-Id: I3bf2e6116e902cd516a7ac69fbe8569ca943e853
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
adjusted_mode.crtc_clock is the real pixel clock rate.
Change-Id: Iac242b89e3144bc53c40170c2cec0c0913ef6ee0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Clock slop is a solution for rk3288, not suitable for rk3399,
after use crtc mode_valid, we can remove the clock slop.
Change-Id: I68121505dfb7e65bf09c26d51c23edc909bdb517
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The pixel clock of 4K@60Hz is 594MHz, let's enable it for HDMI.
Change-Id: I6097c8a452ba8259c1d8d01fb793cd7cc55cafb3
Signed-off-by: Yakir Yang <ykk@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>
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)
Dut to the high HDMI signal voltage driver, Mickey have meet
a serious RF/EMI problem, so we decided to reduce HDMI signal
voltage to a proper value.
The default params for phy is cklvl = 20 & txlvl = 13 (RF/EMI failed)
ck: lvl = 13, term=100, vlo = 2.71, vhi=3.14, vswing = 0.43
tx: lvl = 20, term=100, vlo = 2.81, vhi=3.16, vswing = 0.35
1. We decided to reduce voltage value to lower, but VSwing still
keep high, RF/EMI have been improved but still failed.
ck: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
tx: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
2. We try to keep voltage value and vswing both lower, then RF/EMI
test all passed ;)
ck: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
tx: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
When we back to run HDMI different test and single-end test, we see
different test passed, but signle-end test failed. The oscilloscope
show that simgle-end clock's VL value is 1.78v (which remind LowLimit
should not lower then 2.6v).
3. That's to say there are some different between PHY document and
measure value. And according to experiment 2 results, we need to
higher clock voltage and lower data voltage, then we can keep RF/EMI
satisfied and single-end & differen test passed.
ck: lvl = 9, term=100, vlo = 2.65, vhi=3.12, vswing = 0.47
tx: lvl = 16, term=100, vlo = 2.75, vhi=3.15, vswing = 0.39
Change-Id: I766df9ad519ddddb9be76f95fbbdb36c5a2d6e51
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
(am from https://patchwork.kernel.org/patch/9223303/)
Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin. We believe that
lowering the bandwidth like this is safe given sufficient testing.
Change-Id: Ife266747f0e6ed46f914f4868362fefc481440f9
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223301/)
Iommu framework introduce default_domain for automatic
attach which we were not interesting before, now rockchip
iommu driver following this way that make things different:
iommu_detach_device function is not able to disable iommu anymore.
It just do following things either:
1. Just return
Like Vcodec/ISP who does not allocate new domain
2. Attach default_domain
Like vop who allocate new domain by vop driver
We have no way to temporary disable iommu,to fix this issue, master
driver need to attach a NULL domain,also master driver need more step:
1. iommu_attach_device(NULL, dev) -> disable iommu
2. iommu_detach_device(NULL, dev) -> attach default_domain
Above two steps must comes in pairs.
Following order called by driver is not permitted:
1. iommu_attach_device(domain, dev)
2. iommu_attach_device(NULL, dev)
3. iommu_detach_device(NULL, dev)
4. iommu_detach_device(domain, dev)
Correct is:
1. iommu_attach_device(domain, dev)
2. iommu_detach_device(domain, dev)
3. iommu_attach_device(NULL, dev)
4. iommu_detach_device(NULL, dev)
Change-Id: I12b1e27e5119fb1abd05ccce57c9e941f03e9498
Signed-off-by: Simon Xue <xxm@rock-chips.com>
When jumping from uboot to kernel, vop may page fault, this due
to vop working parallel to kernel probe dts node by cpu.
Defer vop iommu attach function when iommu_ops->add_device called,
and hand the attach function to vop driver is a solution.
Change-Id: I84822ac7a3d0884f96df774a2363c22cbf0f074a
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Since the refcount_t 'atomic' type is used to implement 'struct kref',
refcount_read() is used to replace atomic_read().
Change-Id: I9fc7876cfd7ed8107551bc1909fa0305ab41d9fd
Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
Fix the compilation error below:
error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
Change-Id: Ib7cbc813c6eeeded220171ef5e4434ad798d06d9
Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
This driver uses Rockchip timer to simulate RTC functions.
Only contains Kconfig/Makefile modifies, the driver itself is already
added in other commit.
Change-Id: I49eed6ecbb4c55527696c63b0d479afe837502d5
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
To convert saradc value to voltage, we have the following formula:
voltage = (raw saradc value * saradc voltage ref voltage) / 1024
Take RK3399 excavator as an example, the saradc voltage reg voltage is 1800000uv,
the formula can simplify to :
voltage = raw saradc value * 1750 uv
Change-Id: I8703bcdc2e2b0305118dd9f5777533e8fac7c5a1
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Some relative codes,
such as 'zone_page_state_add(1, zone, NR_SLAB_RECLAIMABLE);',
caused compile errors, when compiled with clang.
The corresponding interface(NR_SLAB_RECLAIMABLE, et.) was changed
between kernel v4.4 and v4.19.
These codes were used to updates the cachelines with the statistics,
and are removed in Midgard DDK r22.
Here, I remove them too, in current Midgard DDK r18.
Change-Id: I3a7e789c0456f28eba623b20564ea8a97109051f
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Use the CPUFREQ_IS_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit e248d8d35c)
Conflicts:
drivers/cpufreq/cpufreq-dt.c
Change-Id: I140c2d0f625faa685643206a3a7556fc54868f71
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
All cpufreq drivers do similar things to register as a cooling device.
Provide a cpufreq driver flag so drivers can just ask the cpufreq core
to register the cooling device on their behalf. This allows us to get
rid of duplicated code in the drivers.
In order to allow this, we add a struct thermal_cooling_device pointer
to struct cpufreq_policy so that drivers don't need to store it in a
private data structure.
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 5c238a8b59)
Conflicts:
drivers/cpufreq/cpufreq.c
Change-Id: I18aad43fce69f5a20388078dd5d18877f09839ee
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Client applications are forbidden to run before supplicant
application is ready. Detection of supplicant application
status is added at the entry of open operation.
Change-Id: Ief4106bcd75251790b82d76e4d69092900af29e3
Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
Some logs may appear before tee-supplicant start,
so uart port config should be done as early as possible.
Change-Id: I51bdb6a9d0f5160a6dc66ad015577a77df6897b4
Signed-off-by: Zhang Zhijie <zhangzj@rock-chips.com>
Kernel is running in secure mode on some platforms(e.g. rk3128/rv1108),
which has no secure OS to support TEE service.
Change-Id: I275413230b2a8ec3864fc5a5ba043a155d724ced
Signed-off-by: Zhang Zhijie <zhangzj@rock-chips.com>
Enable KEYBOARD_GPIO and disable KEYBOARD_ROCKCHIP
which is not supported anymore.
Change-Id: I2a1a63d4acc96e04ce39373b810c92b07ed9ee92
Signed-off-by: Simon Xue <xxm@rock-chips.com>
The "OTG wakelock" should be destroyed if otg port was initialized
failed, in case of its memory allocate for other module and the
"wakeup_sources" list would be broken.
Change-Id: Ic478e7297e36def8e105a0736beb86c99ca6261d
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
For the 'otg-mux' irq in SoC should include 'otg-bvalid', 'linestate',
and 'otg-id'. This change fix the previous error condition.
Change-Id: I8fe46c8c9efd6ce04eead89c276227d4cc70902e
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
