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>
userspace can use drmGetVersion() to identify linux 4.4 or 4.19 drm
driver.
Change-Id: I5a21f9bce198cb18a107496cb924a82a44ac6cb4
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
When the clients are 32 bits while the kernel is 64 bits,
we need to translate the memory address before accessing.
The previous commit was refreshed by ddk update.
Change-Id: I7f47ab94da258e9d170613252aae9b396623cf48
Signed-off-by: Randy Li <randy.li@rock-chips.com>
user_atom.atom_number can be indirectly controlled by user-space,
hence leading to a potential exploitation
of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/arm/midgard/mali_kbase_jd.c:1397 kbase_jd_submit() warn:
potential spectre issue 'jctx->atoms' [r]
katom = &jctx->atoms[user_atom.atom_number];
Fix this by sanitizing user_atom.atom_number
before 'katom = &jctx->atoms[user_atom.atom_number];'.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Fixes: 5cf27d0b60 ("Mali: midgard: changes to enlarge BASE_JD_ATOM_COUNT to 512, for defect 184210")
Change-Id: If52f30d29a80a06c6693ddadd5947ab9fe8fbc25
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
The source code of mali_so must be modified correspondingly.
Change-Id: I3f4bd03fa2d369d912e6bc05c53d2d3abefb92d3
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
4.4 kernel inno hdmi phy name is "hdmi_phy".
4.19 kernel inno hdmi phy name is "hdmi".
Change-Id: Ie87aa205c89154b417887a84703ce7bd9ffb2c7f
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Parts of the modifications are borrowed from Mali Bifrost DDK r13.
Change-Id: I82c68041a3185063ae2d8a40a7a7c17feaab0733
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
