This adds the necessary data for handling dfi on the rk3328.
Change-Id: Id870f78dad3ddd6cb5771674a4e8905322f9e8ef
Signed-off-by: CanYang He <hcy@rock-chips.com>
after modify, rockchip_dfi_ops can apply to other platform use such
version ddr monitor. regardless of channel count, only one channel
of rk3288,rk3399,rk3328 can work. and regardless of monitor clk,
some platform like rk3328 monitor clk is always on.
Change-Id: Ia1c02a89116546ded385c5a6a3e36d020d66b7f3
Signed-off-by: CanYang He <hcy@rock-chips.com>
This adds the necessary data for handling dfi on the rk3128.
Access the dfi via registers provided by GRF (general register
files) module.
Change-Id: Ife9e9987224088434e878102b7d1c3b132e761ad
Signed-off-by: Liang Chen <cl@rock-chips.com>
This adds the necessary data for handling dfi on the rk3288.
Access the dfi via registers provided by GRF (general register
files) module.
Change-Id: Ic7241af3c20a269ab362055dea04d260e01c50de
Signed-off-by: Tang Yun ping <typ@rock-chips.com>
This adds the necessary data for handling dfi on the rk3368.
Access the dfi via registers provided by GRF (general register
files) module.
Change-Id: I96c2b4dcd34d90731b749ebdbe6922f01559d8e6
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Rockchip Socs have GPU, we need allocate GPU accelerated buffers.
So add special ioctls GEM_CREATE/GEM_MAP_OFFSET to support
accelerated buffers.
Change-Id: Ia4b13798aac97d16214da7a75a2479e6e334313a
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Also add unpack_bootimg and update mkbootimg
AOSP 96fd8874ef8e ("Check DTB image size for boot image header version 2 and above")
Change-Id: I4582913b21f711c84d62bed0ffd024b583a094f7
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Add support for fb_dmabuf_export call, which is executed when ioctl
FBIOGET_DMABUF is called.
Change-Id: I13b753ae25d043835b1f4ffc20b5e233171d1096
Signed-off-by: Guillaume Tucker <guillaume.tucker@arm.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
(am from 61062681c9)
Commit ab8f58ad72 ("PM / devfreq: Set min/max_freq when adding the
devfreq device") initializes df->min/max_freq with the min/max OPP when
the device is added. Later commit f1d981eaec ("PM / devfreq: Use the
available min/max frequency") adds df->scaling_min/max_freq and the
following to the frequency adjustment code:
max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
With the current handling of min/max_freq this is incorrect:
Even though df->max_freq is now initialized to a value != 0 user space
can still set it to 0, in this case max_freq would be 0 instead of
df->scaling_max_freq as intended. In consequence the frequency adjustment
is not performed:
if (max_freq && freq > max_freq) {
freq = max_freq;
To fix this set df->min/max freq to the min/max OPP in max/max_freq_store,
when the user passes a value of 0. This also prevents df->max_freq from
being set below the min OPP when df->min_freq is 0, and similar for
min_freq. Since it is now guaranteed that df->min/max_freq can't be 0 the
checks for this case can be removed.
Fixes: f1d981eaec ("PM / devfreq: Use the available min/max frequency")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
(cherry picked from commit df5cf4a361)
Change-Id: Ib8e2def7d3bf605dba81cf75bab89a23a39ca6f3
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Since devfreq_add_device() and update_devfreq() already takes care of this.
Change-Id: Ie90c1d28f681cfbc946362e303a61bdf3578ccd6
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
This is required by android hwc.
Change-Id: Ia0159b877f7d8b2bb5cecf3b352b67d9c76c7c97
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
add rk3288/rk3368/rk3399 vop area plane
Change-Id: Ia6f77353363e25423ac29129372bc510565682f8
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
The series vop of VOP_FULL framework support area plane, such as
RK3288 and RK3399, one group of area planes share same hardware,
reuse the hardware on different scanout time, this design is
useful to support mulit planes with low hardware consume.
Change-Id: Ie53211ce9ed22d03f7668637efbb7c95d9a8eb5b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
The plane hardware is used when the display scanout run into plane active
scanout, that means we can reuse the plane hardware resources on plane
non-active scanout.
Because resource share, There are some limit on share plane: one group
of share planes need use same zpos, can't not overlap, etc.
We assume share plane is a universal plane with some limit flags.
people who use the share plane need know the limit, should call the ioctl
DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it.
Change-Id: Iecc3d8e7f1ce29d567cdbad689ba4dbad3d594e1
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
