cpufreq_times_record_transition() is not called when fast switch is
enabled, leading /proc/[pid]/time_in_state to attribute all time on a
cluster to a single frequency. To fix this, add a call to
cpufreq_times_record_transition() in the fast switch path.
Test: /proc/[pid]/time_in_state shows times for more than one freq per
cluster
Bug: 204726690
Signed-off-by: zhengding chen <chenzhengding@oppo.com>
Change-Id: Ief47ffb49fcc7fbf5408eea3056930e8791d2820
We should avoid rolling the phases if 270 and 0 is both
fine in tuning. Otherwise it would chose a middle phase
laid later than 270 which isn't a good.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Fixes: 8d0e882790 ("mmc: dw_mmc-rockchip: Skip all phases bigger than 270 degrees")
Change-Id: I87bd3e957623d6a5fdf38226be65564e353b01b6
slot's clock is cached before calling ->set_ios for sub-driver.
If the clock is updated by sub-driver, it's better to restore
the cached slot's clock. Or we can see a unexpected clock as the
driver didn't know the slot's clock is updated and still use the
old clock to calculate divider. So we may see a lower clock. It
theory, it's won't be a problem because any rate lower than 400k
should be fine, and we even didn't start issuing any command during
the lower clock. But still it's right to update slot's clock to reflect
the correct clock and may fix some potential unknown problems.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: I06581320547bb06c306da57e141d06f9206ea585
This is a 8K(vp0+vp1) + 4K(vp2) + 2K(vp3) plane-mask.
This will be used before u-boot logo is ready.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Change-Id: Ibbac678ec0e1023073e8d44854990bf6027118b3
Add hooks to gather data of unusual aborts and summarize it with
other information.
Bug: 203187389
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: I37b3047e72f64dc210d3d3bffe5ee207daeba8d6
During the suspend is in process, thermal_zone_device_update bails out
thermal zone re-evaluation for any sensor trip violation without
setting next valid trip to that sensor. It assumes during resume
it will re-evaluate same thermal zone and update trip. But when it is
in suspend temperature goes down and on resume path while updating
thermal zone if temperature is less than previously violated trip,
thermal zone set trip function evaluates the same previous high and
previous low trip as new high and low trip. Since there is no change
in high/low trip, it bails out from thermal zone set trip API without
setting any trip. It leads to a case where sensor high trip or low
trip is disabled forever even though thermal zone has a valid high
or low trip.
During thermal zone device init, reset thermal zone previous high
and low trip. It resolves above mentioned scenario.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org>
Bug: 205496325
Link: https://lore.kernel.org/linux-pm/51de966a-9c9e-88a8-5c2c-96773a64d527@linaro.org/T/#u
Change-Id: Ib57ac6164811a566b497964701f23a3c209915e3
Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
A potential use after free can occur in _vm_unmap_aliases where an already
freed vmap_area could be accessed, Consider the following scenario:
Process 1 Process 2
__vm_unmap_aliases __vm_unmap_aliases
purge_fragmented_blocks_allcpus rcu_read_lock()
rcu_read_lock()
list_del_rcu(&vb->free_list)
list_for_each_entry_rcu(vb .. )
__purge_vmap_area_lazy
kmem_cache_free(va)
va_start = vb->va->va_start
Here Process 1 is in purge path and it does list_del_rcu on vmap_block and
later frees the vmap_area, since Process 2 was holding the rcu lock at
this time vmap_block will still be present in and Process 2 accesse it and
thereby it tries to access vmap_area of that vmap_block which was already
freed by Process 1 and this results in use after free.
Fix this by adding a check for vb->dirty before accessing vmap_area
structure since vb->dirty will be set to VMAP_BBMAP_BITS in purge path
checking for this will prevent the use after free.
Link: https://lkml.kernel.org/r/1616062105-23263-1-git-send-email-vjitta@codeaurora.org
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 205658047
(cherry picked from commit ad216c0316https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
Change-Id: I450781b5734570d1b9e8c63ac29ad3635c8e49bb
Signed-off-by: Vijayanand Jitta <vjitta@codeaurora.org>
It isn't sticky when link goes down for whatever reason.
If devices want to reset the modules by puting link into D3
state or whatever, we should restore it the. Otherwise devices
cannot access RC's resource even if the link is recovered.
Change-Id: Ie5b5a0b7f6ab03961658b4217c9db2cada0edb93
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Simon Xue <xxm@rock-chips.com>
It's found a new r8169 ethernet card with a device ID of
0x0000 read from its config header which wasn't in the
ID tables of r8169. Add it in order to probe this card.
Change-Id: I27c542a10cc571a6e1a4e7a8af62ce560b8b1fc4
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
Add property to transfer next hdr sink data to userspace.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: I926ec6553bdb0b1730a7ca578f46f36926860ebd
To be compatible with GKI, we parse the edid next hdr information
in rockchup-drm driver.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: Id6fd8f2d8429b07472c6562c223ae84262952e8d
To support the rk3588 dsc function, add get edid dsc
info interface.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: I33cc4b60183484e7cd15b519cec4c32d7be53deb
To be compatible with GKI, we parse the edid dsc information
in rockchup-drm driver.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: I2f2cc9e9fe8578865975e1631450dbbc723ce08e
VOP has a limitation of act_width on rk3568:
(1) The act_width should align as 4 pixel at afbc mode
(2) can't handle a act_width % 16 = 1
VOP on rk3588 has no such limitation.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Change-Id: I56f2ff32ac384bff81b6b911cd10ef599e5f44c3
We should set both VP->DUAL_CHANNEL_CTRL.dual_channel_en
and DSP_INTERFACE_EN.mipi_dual_channel_en when drive
a dual channel mipi dsi on rk3588, this is different
from rk356x.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Change-Id: I784f9556903126bae52b3063eb23fbf0a0193739
