Due to the bug in current code, only first IOMMU has the TLB lines
flushed in rk_iommu_zap_lines. This patch fixes the inner loop to
execute for all IOMMUs and properly flush the TLB.
BUG=chrome-os-partner:55135
TEST=compile
Change-Id: Ica2d4b0cc3d3cbc88c70ad541dc00883f1b4e90c
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/371098
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Add a new dtsi file - rk3399-opp.dtsi, to configure opp-tables
for cpu, gpu and dmc.
Add rk3399-early-opp.dtsi for board with ES1, which need limit
frequency for cpu, gpu and dmc.
Change-Id: Ib57761fd5f405b0e79039d7a01e6e023d6f5dc2c
Reviewed-by: Finley Xiao <finley.xiao@rock-chips.com>
Reviewed-by: Huang, Tao <huangtao@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
It is not harm to keep both vpu service and vpu v4l2 at the same time,
that the board file choose a driver implementation and interace to
be used.
Change-Id: If79deac5bf19395cfdca821f20486985e3034389
Signed-off-by: Randy Li <randy.li@rock-chips.com>
There is a bug in GMAC IP, it supports RGMII clock but not a speed
mode for it.
Change-Id: I8e5cca355c30920db37400901d3411eebca711ae
Signed-off-by: Randy Li <randy.li@rock-chips.com>
If the regulator is shared between several devices then the lowest
request voltage that meets the system constraints will be used.
Change-Id: I9645f3f81004c7203769a92367513d9d177504b2
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
If the regulator is shared between several devices then the lowest
request voltage that meets the system constraints will be used.
Change-Id: I7dda43b24c7e19098db65b51ae0c4386b46ee0b7
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
If there is only one opp whose frequency is equal to the initial value
in opp table list, the DDR voltage domain will keep the initial voltage,
it may be too large.
Change-Id: I9e75d54bdc7d909baa72667821ff30beb4d62e27
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
If there is only one opp whose frequency is equal to the initial value
in opp table list, the GPU voltage domain will keep the initial voltage,
it may be too large.
Change-Id: I87a5fb82eaac8466123b61e39a5d7587da3066da
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
As there are still some limitations, we prefer to implement it ourselves.
Change-Id: Ic801ed0a137b025296144cb3d8e47bcb0f8c0567
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Bootloader or kernel sets CPU frequency to an initial value before cpufreq
starts on rockchip platform, if cpu's opp table is modified to a specified
value, it will cause an issue.
For example, the initial frequency is 816MHz and voltage set by hardware
is 900mV:
1. there is only one opp whose frequency is 816MHz and voltage is 850mV
in opp table list, as they frequency is equal, the voltage will not be
changed, it is still 900mV and a little too large relative to 850mV.
2. there is only one opp whose frequency is 1200MHz and voltage is 1100mV
in opp table list, as it doesn't set voltage to 1100mV before set frequency
to 1200MHz in the dev_pm_opp_set_rate function, the initial voltage 900mV
cann't supply for 1200MHz, the system crash.
Change-Id: Id8c5efc34d9c94ff37921b33f5a76e059240d368
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Set geometry for allocated domains and fix .domain_alloc() callback to
work with IOMMU_DOMAIN_DMA domain type, which is used for implicit
domains on ARM64.
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit a93db2f22b)
Change-Id: Ib04827afadbfb32ca52c6842cd056952269cbe93
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Use DMA API instead of architecture internal functions like
__cpuc_flush_dcache_area() etc.
The biggest difficulty here is that dma_map and _sync calls require some
struct device, while there is no real 1:1 relation between an IOMMU
domain and some device. To overcome this, a simple platform device is
registered for each allocated IOMMU domain.
With this patch, this driver can be used on both ARM and ARM64
platforms, such as RK3288 and RK3399 respectively.
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 4f0aba6767)
Conflicts:
drivers/iommu/rockchip-iommu.c
Change-Id: I0424318ed0cea947e7c8f8d3b52f716f6cc98ce0
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
In .probe(), devm_kzalloc() is called with size == 0 and works only
by luck, due to internal behavior of the allocator and the fact
that the proper allocation size is small. Let's use proper value for
calculating the size.
Fixes: cd6438c5f8 ("iommu/rockchip: Reconstruct to support multi slaves")
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 3d08f434bd)
Change-Id: I78db8fbf3cb781745a05f8bee492dd7e8ac784c5
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
rk_iommu_command() takes a struct rk_iommu and iterates over the slave
MMUs, so this is doubly wrong in that we're passing in the wrong pointer
and talking to MMUs that we shouldn't be.
Fixes: cd6438c5f8 ("iommu/rockchip: Reconstruct to support multi slaves")
Cc: stable@vger.kernel.org
Signed-off-by: John Keeping <john@metanate.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit ae8a7910fb)
Change-Id: I5d6f5dd49ad0f79facee8d345c5058af80226f83
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Since commit cd6438c5f8 ("iommu/rockchip: Reconstruct to support multi
slaves") rk_iommu_is_stall_active() always returns false because the
bitwise AND operates on the boolean flag promoted to an integer and a
value that is either zero or BIT(2).
Explicitly convert the right-hand value to a boolean so that both sides
are guaranteed to be either zero or one.
rk_iommu_is_paging_enabled() does not suffer from the same problem since
RK_MMU_STATUS_PAGING_ENABLED is BIT(0), but let's apply the same change
for consistency and to make it clear that it's correct without needing
to lookup the value.
Fixes: cd6438c5f8 ("iommu/rockchip: Reconstruct to support multi slaves")
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit fbedd9b990)
Conflicts:
drivers/iommu/rockchip-iommu.c
Change-Id: I5a43eb19d515eba7daf1dc4b1592ac692c115df0
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
This patch fixes that sometimes hang at start-up time of the system.
As the below log:
...
[ 11.136543] calling pm_genpd_debug_init+0x0/0x60 @ 1
[ 11.141602] initcall pm_genpd_debug_init+0x0/0x60 returned 0 after 11 usecs
[ 11.148558] calling genpd_poweroff_unused+0x0/0x84 @ 1
<hang>
In some cases, the rk3399 should turn off the gmac power domain to save
power if some boards didn't register the gmac device node for rk3399.
Then, rk3399 need to make sure the gmac's pclk enabled if we need
operate the gmac power domain. (Due to the NOC had enabled always)
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(am from git/mmind/linux-rockchip.git branch for-next
commit 2afc1db0c5)
Change-Id: I8425b83e617de9eafaa093c3342b8e6082eb4112
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Do iommu mapping with looping vop vblank register have a problem, when
iommu attach take too long time or vblank time is too short, the display
would flash.
This patch use another method to fix this problem:
Use standby and dsp_hold interrupt to enter vblank time, when iommu
mapping is finish, exit vop standby, then vop would start scanout
immediately,
vop enter standby -> |
dsp_hold irq -> |--------- vblank start
do iommu mapping -> | vblank time
exit standby -> |--------- vblank end
We try add 20ms delay to iommu attach, display also looks good, that
means this method have higher compatibility.
Change-Id: I59d57c9085631d0c42174ea18890c80e26b42d22
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
We may miss clock-latency-ns when disable some opps, then cpufreq
will fallback to performance governor, so add clock-latency-ns for
each opp to make disable opp easy.
code as below:
drivers/cpufreq/cpufreq.c:2010
if (policy->governor->max_transition_latency &&
policy->cpuinfo.transition_latency >
policy->governor->max_transition_latency) {
if (!gov)
return -EINVAL;
else {
pr_warn("%s governor failed, too long transition latency of HW,
fallback to %s governor\n",
policy->governor->name, gov->name);
policy->governor = gov;
}
}
Change-Id: I93cff667deb487baa0115b7af0206f0803010d37
Signed-off-by: Chen Liang <cl@rock-chips.com>
drm_format_plane_cpp use byte size, not works for 10bit
format, use drm_format_plane_bpp instead.
Change-Id: If1a6ca1c286747fdc868184cebe75eb0af0a746d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
We're trying to mask out bits[23:8] while retaining [32:24, 7:0], but
we're doing the inverse. That doesn't have too much effect, since we're
setting all the [23:8] bits to 1, and the other bits are only relevant
for modes we're currently not using. But we should get this right.
Change-Id: I98ec66f1fdc5f99cc2432d7a1cddb63f4b9f3c30
Fixes: ca19890840 ("PCI: rockchip: Fix wrong transmitted FTS count")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit fd7c054e782d57509b2355ab71b786d83ab44194)
Rockchip's RC outputs 100MHz reference clock but there are
two methods for PHY to generate it.
(1)One of them is to use system PLL to generate 100MHz clock and
the PHY will relock it and filter signal noise then outputs the
reference clock.
(2)Another way is to share Soc's 24MHZ crystal oscillator with
PHY and force PHY's DLL to generate 100MHz internally.
When using case(2), the exit from L0s doesn't work fine occasionally
due to the broken design of RC receiver's logical circuit. So even if
we use extended-synch, it still fails for PHY to relock the bits from
FTS sometimes. This will hang the system.
Maybe we could argue that why not use case(1) to avoid it? The reason
is that as we could see the reference clock is derived from system PLL
and the path from it to PHY isn't so clean which means there are some
noise introduced by power-domain and other buses can't be filterd out
by PHY and we could see noise from the frequency spectrum by oscilloscope.
This makes the TX compatibility test a little difficult to pass the spec.
So case(1) and case(2) are both used indeed now. If using case(2), we
should disable RC's L0s support, and that is why we need this property to
indicate this quirk.
Also after checking quirk.c, I noticed there is already a quirk for
disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
shouldn't do that as mentioned above that case(1) could still works fine
with L0s.
Change-Id: Ia9506d55f34a24001c19d398a8ecb088558c0f7e
Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit c2af19ee1b5e0f0ef942d27b18f7e22e2ab43cba)
PCIE_RC_CONFIG_LCS contains control and status bits specific
to the PCIe link. The layout for this register looks the same
as the existed PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's
reuse them.
Change-Id: I3e2b88d9c12f2bf924a3d6b8f2254904f9b594b2
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 144ded1828f015f1a53d50bce730ed15f17ff38f)
pm_rst, aclk_rst and pclk_rst should be controlled by driver, so we
need to add these three resets for PCIe controller.
Change-Id: I364d8d0cb57d9d349153d76189f1e20e40e32704
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 4d3222f707)
pm_rst, aclk_rst, pclk_rst was controlled by rom code so the
software wasn't needed to control it again in theory. But it
didn't work properly, so we do need to do it again and add a
enough delay between the assert of pm_rst and the deassert of
pm_rst. The Soc intergrated with this controller, rk3399 is still
under MP test internally, so the backward compatibility won't be
a big deal.
Change-Id: I07e02c5dcd6985ce7d16dde18bf0390674a0adbf
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 31a3a7b5b2)
Per the errata of TRM, the RC can't support L1 substate, so we
need to remove the L1 substate cap as well as operation for
PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2.
Change-Id: If3e1e7ac46720c9487724f15b22905a02bebb7ca
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 9d7598543b5fa2dacd7ccdffe9e03b578a9a03d1)
rk3399 supports PCIe 2.x link speeds marginally at best, and on some
boards, the link won't train at 5 GT/s at all. Rather than sacrifice
500ms waiting for training that will never happen, let's use the helper
function, of_pci_get_max_link_speed, to get the max link speed from DT
and specify link capability.
Change-Id: I899df707f0555eea8ae4a370b171a4786162bb90
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 9d4052126b0deeb67552580ffe7f6383e0123c62)
This new helper function could be used by host drivers to
get the limitaion of max link speed provided by dt. If the
property isn't assigned or is invalid, it will return -EINVAL
to the caller.
Change-Id: I430b05fa5fd25fe17cf1bd8b1226e460eb7dd14b
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 9a1dc38912)
Some of the host drivers have the requirement of knowing whether the
EP would never train at some link speed at all. For instance, on some
boards, the link won't train at 5 GT/s but the host driver still sacrifice
some cycle to wait for the resule of training at 5 GT/s as the host could
actually support 5 GT/s. So we could parse this new property and make the
host drivers be aware of these cases.
Change-Id: I7f557282462a7146d8d15af560001c81ccc7e1a7
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(am from git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
commit 2fa39159b6)
