There are still quite a few cases where a device might want
to get to a different node of the device-tree, obtain the
resources and map them.
We have of_iomap() and of_io_request_and_map() but they both
have shortcomings, such as not returning the size of the
resource found (which can be useful) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
(cherry picked from commit d5e838275c)
Change-Id: I5d68c3e23637c5e83e5f2bed3a1aa2c654d7d6a1
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
RK3308B is a enhanced variant of RK3308 with more flexible
iomux and peripherals(for example, RK3308B has 12 pwms, but
RK3308 has 4).
The CHIP_ID is stored in GRF_CHIP_ID:
RK3308: 0xcea (3306 in decimal)
RK3308B: 0x3308
Change-Id: I8f675656c012bdedb43043f5dbeea8bd11ea4ded
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
rk1808 have vop lite and vop raw:
1. vop lite: support win1 for display, vop->dsi tx->dphy->lcd.
2. vop raw: transfer data from ddr to csi tx.
Change-Id: I11229b5e61e66e72e4228e7e0ac966f1f85cb49f
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.
The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value
The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.
If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.
Changes in v2:
- Pimp kerneldoc for content_protection_property (Daniel)
- Drop sysfs attribute
Changes in v3:
- None
Changes in v4:
- Changed kerneldoc to recommend userspace polling (Daniel)
- Changed kerneldoc to briefly describe how to attach the property (Daniel)
Changes in v5:
- checkpatch whitespace noise
- Change DRM_MODE_CONTENT_PROTECTION_OFF to DRM_MODE_CONTENT_PROTECTION_UNDESIRED
Changes in v6:
- None
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-4-seanpaul@chromium.org
(cherry picked from commit 24557865c8)
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[downstream changes]
- Fixed some conflicts in comments
- Remove duplicate definition for drm_get_content_protection_name
Change-Id: I825b4863bea715434cb8f76f99fdf6e3fca74a60
Reviewed-on: https://chromium-review.googlesource.com/849079
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Sean Paul <seanpaul@google.com>
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The Content Protection properties in 4.4 used v2 of the upstream
patches, but chrome (and upstream) prefer v1. This patch removes the ksv
property and reinstates the ENABLED enum value to the content protection
property.
BUG=b:63816472
TEST=Watch protected content on external display, ensure CP is
enabled/disabled properly by chrome
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/687800
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Change-Id: I38cecce2d15b4d4b1ce95ef0e572a08f1bc97131
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Although this property value have been deleted from the latest
FROMLIST version (CL:266854), but the chromeos would want driver
to report the property to "Enabled" when hardware HDCP have been
enabled successfully, so let's add this back.
BUG=chrome-os-partner:56883
TEST=None
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/403974
Reviewed-by: Sean Paul <seanpaul@google.com>
Change-Id: Icc52d4a83ac434e898be1190cf934ed8333e78bf
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Add new standard connector properties to track whether content protection
(ex: hdcp) is desired by userspace. There are two properties involved,
"Content Protection" and "Content Protection KSV".
The "Content Protection" property allows userspace to request protection
on a connector. Set "Desired" to enable, "Undesired" to disable.
The "Content Protection KSV" property reflects the current state of
protection. If the KSV is 0, the connection is not protected. Once the
driver has enabled protection, it will update the the value with the KSV
(or similarly unique identifier, if not using HDCP) of the first-hop
device (sink or repeater).
(am from https://patchwork.kernel.org/patch/5439871/)
BUG=chrome-os-partner:56883
TEST=Tested on kevin, ensured the sysfs file showed up, and
reflected the correct
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/403973
Reviewed-by: Sean Paul <seanpaul@google.com>
Change-Id: I6bef13729f77de6e37d2da5e12fc69f810a2e286
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Add the clock tree definition for the new rk1808 SoC.
Change-Id: I86e502b27e0695c77e9937dfd7cffa14b5711954
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Add the dt-bindings header for the rk1808, that gets shared between
the clock controller and the clock references in the dts.
Add softreset ID for rk1808.
Change-Id: I0eef08655037daeab92560f36e06fde4032ddd0c
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
LSK 18.07 v4.4-android
* tag 'lsk-v4.4-18.07-android': (254 commits)
Linux 4.4.143
net/nfc: Avoid stalls when nfc_alloc_send_skb() returned NULL.
rds: avoid unenecessary cong_update in loop transport
KEYS: DNS: fix parsing multiple options
netfilter: ebtables: reject non-bridge targets
MIPS: Use async IPIs for arch_trigger_cpumask_backtrace()
MIPS: Call dump_stack() from show_regs()
rtlwifi: rtl8821ae: fix firmware is not ready to run
net: cxgb3_main: fix potential Spectre v1
net/mlx5: Fix command interface race in polling mode
net_sched: blackhole: tell upper qdisc about dropped packets
vhost_net: validate sock before trying to put its fd
tcp: prevent bogus FRTO undos with non-SACK flows
tcp: fix Fast Open key endianness
r8152: napi hangup fix after disconnect
qed: Limit msix vectors in kdump kernel to the minimum required count.
net: sungem: fix rx checksum support
net/mlx5: Fix incorrect raw command length parsing
net: dccp: switch rx_tstamp_last_feedback to monotonic clock
net: dccp: avoid crash in ccid3_hc_rx_send_feedback()
...
Fix wrong merge of include/linux/compiler-gcc.h
Change-Id: I1daae1251069d2791d2e29b65942d086fb8ad0ac
camera: rockchip: add sensor ioctl and max gain.
1. add RK_VIDIOC_SENSOR_CONFIGINFO;
2. add RK_VIDIOC_SENSOR_REG_ACCESS;
3. add max_exp_gain_h/max_exp_gain_l;
camera: rockchip: merge isp11: rockchip: v0.1.7
isp11: rockchip: v0.1.7
1. Direct config isp lsc table size in cifisp_lsc_config.
Because active_lsc_width is not same with isp register
after isp reset.
2. Support separate config sensor gain and shutter time
for some sensor which gain and shutter isn't valid at
the same time. for example ov2710.
ov4689:v0.1.0;
ov2710:v0.1.1;
imx323:v0.1.0;
camera: rockchip: Support v4l2 subdev api
ov2710: v0.1.2
ov4689: v0.1.1
imx323: v0.1.2
camera: rockchip: add lock for stream/aec
hold reg in AEC will affect stream reg, if asynchronous.
camera: rockchip: fix sensor timing
if fps changed, vts changed, update to timing.
camera: rockchip: support set flip api
camera: rockchip: support get flip api
camera: rockchip: fix release bug
should be free pdata at the end
camera: rockchip: imx323
fix s_fmt failed for imx323 v0.1.2;
camera: rockchip: fix s_frame_interval failed
fix s_frame_interval failed when frame interval is match
active config frame interval.
camera: rockchip: imx,aptina,ov
Check xxx_camera_module_init return value in PLTFRM_CIFCAM_ATTACH
camera: rockchip: release sensor if init fail
camera: rockchip: imx,aptina,ov
support mirror/flip conifg in dts for imx323/ov4689
camera: rockchip: add s_frame_interval/g_frame_interval
camera: rockchip: ov, aptina, imx
add s_frame_interval/g_frame_interval
camera: rockchip: imx,ov,aptina
1.imx,ov: fix g_timing error if s_frame_interval before stream_on,
because vts_cur is update in stream_on;
2.aptina: fix compile error;
camera: rockchip: imx,ov,aptina
1. fix calc vts wrong in xxx_camera_module_s_stream
Change-Id: I5a6e75f2ce3c50d69c51af9792232c60b6982128
Signed-off-by: Hu Kejun <william.hu@rock-chips.com>
we use SCLK_TESTCLKOUT1 and SCLK_TESTCLKOUT2 for camera, so add those ids.
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit f22e4359cd)
Change-Id: Ibbdb8e9dabd8c955ef3745c0f49c20f4c763e870
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Export the dclk_vop_frac out, so we can set the dclk_vop as the
child of dclk_vop_frac, and then we can start to take use of
the fractional dividers.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit e33075db73)
Change-Id: I3d47c6aecc338de45b48414f0d0327c17e6d2b15
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
commit 6d53cefb18 upstream.
Commit abb2ea7dfd ("compiler, clang: suppress warning for unused
static inline functions") just caused more warnings due to re-defining
the 'inline' macro.
So undef it before re-defining it, and also add the 'notrace' attribute
like the gcc version that this is overriding does.
Maybe this makes clang happier.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit abb2ea7dfd upstream.
GCC explicitly does not warn for unused static inline functions for
-Wunused-function. The manual states:
Warn whenever a static function is declared but not defined or
a non-inline static function is unused.
Clang does warn for static inline functions that are unused.
It turns out that suppressing the warnings avoids potentially complex
#ifdef directives, which also reduces LOC.
Suppress the warning for clang.
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Every time _cpu_up() is called for a CPU, idle_thread_get() is called
which then re-initializes a CPU's idle thread that was already
previously created and cached in a global variable in
smpboot.c. idle_thread_get() calls init_idle() which then calls
__sched_fork(). __sched_fork() is where cpufreq_task_times_init() is,
and cpufreq_task_times_init() allocates memory for the task struct's
time_in_state array.
Since idle_thread_get() reuses a task struct instance that was already
previously created, this means that every time it calls init_idle(),
cpufreq_task_times_init() allocates this array again and overwrites
the existing allocation that the idle thread already had.
This causes memory to be leaked every time a CPU is onlined. In order
to fix this, move allocation of time_in_state into _do_fork to avoid
allocating it at all for idle threads. The cpufreq times interface is
intended to be used for tracking userspace tasks, so we can safely
remove it from the kernel's idle threads without killing any
functionality.
But that's not all!
Task structs can be freed outside of release_task(), which creates
another memory leak because a task struct can be freed without having
its cpufreq times allocation freed. To fix this, free the cpufreq
times allocation at the same time that task struct allocations are
freed, in free_task().
Since free_task() can also be called in error paths of copy_process()
after dup_task_struct(), set time_in_state to NULL immediately after
calling dup_task_struct() to avoid possible double free.
Bug description and fix adapted from patch submitted by
Sultan Alsawaf <sultanxda@gmail.com> at
https://android-review.googlesource.com/c/kernel/msm/+/700134
Bug: 110044919
Test: Hikey960 builds, boots & reports /proc/<pid>/time_in_state
correctly
Change-Id: I12fe7611fc88eb7f6c39f8f7629ad27b6ec4722c
Signed-off-by: Connor O'Brien <connoro@google.com>
Add empty versions of functions to cpufreq_times.h to cut down on use
of #ifdef in .c files.
Test: kernel builds with and without CONFIG_CPU_FREQ_TIMES=y
Change-Id: I49ac364fac3d42bba0ca1801e23b15081094fb12
Signed-off-by: Connor O'Brien <connoro@google.com>
commit 240630e618 upstream.
There have been several reports of LPM related hard freezes about once
a day on multiple Lenovo 50 series models. Strange enough these reports
where not disk model specific as LPM issues usually are and some users
with the exact same disk + laptop where seeing them while other users
where not seeing these issues.
It turns out that enabling LPM triggers a firmware bug somewhere, which
has been fixed in later BIOS versions.
This commit adds a new ahci_broken_lpm() function and a new ATA_FLAG_NO_LPM
for dealing with this.
The ahci_broken_lpm() function contains DMI match info for the 4 models
which are known to be affected by this and the DMI BIOS date field for
known good BIOS versions. If the BIOS date is older then the one in the
table LPM will be disabled and a warning will be printed.
Note the BIOS dates are for known good versions, some older versions may
work too, but we don't know for sure, the table is using dates from BIOS
versions for which users have confirmed that upgrading to that version
makes the problem go away.
Unfortunately I've been unable to get hold of the reporter who reported
that BIOS version 2.35 fixed the problems on the W541 for him. I've been
able to verify the DMI_SYS_VENDOR and DMI_PRODUCT_VERSION from an older
dmidecode, but I don't know the exact BIOS date as reported in the DMI.
Lenovo keeps a changelog with dates in their release notes, but the
dates there are the release dates not the build dates which are in DMI.
So I've chosen to set the date to which we compare to one day past the
release date of the 2.34 BIOS. I plan to fix this with a follow up
commit once I've the necessary info.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty->disc_data
may be NULL.
CPU0 CPU1
---- ----
000|n_tty_receive_buf_common() n_tty_open()
-001|n_tty_receive_buf2() tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline) tty_ldisc_setup()
Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.
Reviewed-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Change-Id: I3ba3cbd7dcb867a110878c8d0c47e6b920edd0b9
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
(cherry-picked from commit b027e2298b)
Add a basic wide-temperature control model for device to adjust opp
table and max frequency.
Change-Id: I23f29ac1892093c527e730164eba086f02667de3
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
the mcu init cmd should be sent from crtc mcu interface,
so we add the rockchip_drm_crtc_send_mcu_cmd to do this.
Change-Id: I7fedfb90c6074e8837a825d10e0dcd9c16bfc1d0
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Some UVC video cameras contain metadata in their payload headers. This
patch extracts that data, adding more clock synchronisation information,
on both bulk and isochronous endpoints and makes it available to the user
space on a separate video node, using the V4L2_CAP_META_CAPTURE capability
and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. By default, only the
V4L2_META_FMT_UVC pixel format is available from those nodes. However,
cameras can be added to the device ID table to additionally specify their
own metadata format, in which case that format will also become available
from the metadata node.
[Use put_unaligned instead of __put_unaligned_cpu64]
[Use put_unaligned for the sof field as well]
Conflicts:
drivers/media/usb/uvc/uvc_queue.c
drivers/media/usb/uvc/uvc_video.c
Change-Id: I2696d2c781376e363e0a77d8d895f416aaff09cb
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 088ead2552)
Add a pixel format, used by the UVC driver to stream metadata.
Conflicts:
Documentation/media/uapi/v4l/meta-formats.rst
drivers/media/v4l2-core/v4l2-ioctl.c
include/uapi/linux/videodev2.h
Change-Id: I979fd6b4d5d24510e47a1cfe525e8ae0a1a573ee
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 563a01e101)
