Add an explicit config option to select whether the CEC remote control
messages are to be passed on to the RC subsystem or not.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 5f2c467c54)
Change-Id: I4cb7e4618b4ee1504a6bdcb18821e3d5fe1358b3
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Drop the separate cec-edid.h header and merge it into cec.h.
There was really no need to have a separate header for this.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit ee7e987133)
Change-Id: Idf14df419f4663f24bcbb2de3603498651a469d4
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
The Kconfig options for the CEC subsystem were a bit messy. In
addition there were two cec sources (cec-edid.c and cec-notifier.c)
that were outside of the media/cec directory, which was weird.
Move those sources to media/cec as well.
The cec-edid and cec-notifier functionality is now part of the cec
module and these are no longer separate modules.
Also remove the MEDIA_CEC_EDID config option and include it with the
main CEC config option (which defined CEC_EDID anyway).
Added static inlines to cec-edid.h for dummy functions when CEC_CORE
isn't defined.
CEC drivers should now depend on CEC_CORE.
CEC drivers that need the cec-notifier functionality must explicitly
select CEC_NOTIFIER.
The s5p-cec and stih-cec drivers depended on VIDEO_DEV instead of
CEC_CORE, fix that as well.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 56a263aaa0)
Change-Id: I3c83c4d1aea534c2e8163422c73c8bc276f20f8f
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Add support for CEC notifiers, which is used to convey CEC physical address
information from video drivers to their CEC counterpart driver(s).
Based on an earlier version from Russell King:
https://patchwork.kernel.org/patch/9277043/
The cec_notifier is a reference counted object containing the CEC physical address
state of a video device.
When a new notifier is registered the current state will be reported to
that notifier at registration time.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 6917a7b774)
Change-Id: I048f69ccbf5c1de2f856a6820653d8bfc8455e11
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
IS_REACHABLE(CONFIG_RC_CORE) code
It is a bit confusing how CEC_CAP_RC and IS_REACHABLE(CONFIG_RC_CORE)
interact. By stripping CEC_CAP_RC at the beginning rather than after #else
it should be a bit clearer what is going on.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit ee044f5be1)
Change-Id: I3d8e0a6bff707608c74464f770dc883aaeaea081
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Currently when the RC Core is enabled (reachable) core code located
in cec_register_adapter() attempts to populate the RC structure with
a pointer to the 'parent' passed in by the caller.
Unfortunately if the caller did not specify RC capability when calling
cec_allocate_adapter(), then there will be no RC structure to populate.
This causes a "NULL pointer dereference" error.
Fixes: f51e80804f ("[media] cec: pass parent device in register(), not allocate()")
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: <stable@vger.kernel.org> # for v4.10 and up
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 43c0c03961)
Change-Id: I8c8b267a8868e248cf673e168a9cdc4391f5b172
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Feature Abort shouldn't be sent in reply to messages from Unregistered,
since that would make it a broadcast message.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit a8e97e531a)
Change-Id: Id02046545b95d6e08745aa1093cadac4212745b9
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
When validating the struct cec_s_log_addrs input a debug message is printed
for all except two of the 'return -EINVAL' paths.
Also log the reason for the missing two paths.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Change-Id: I0f8017675671b20005b2a4a723e4e80b428aa39e
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Several error paths didn't log why an error was returned. Add this.
Also handle the corner case of "adapter is unconfigured AND the message
is from Unregistered to TV AND reply is non-zero" separately and return
EINVAL in that case, since it really is an invalid value and not an
unconfigured CEC device.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 25c2107896)
Change-Id: Ief000a37ccab5cc2936abd9d10dd14871737fc47
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
The hardcoded function name is actually wrong. Use __func__ inste
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 5a137df1d6)
Change-Id: Ic214ebc4f821e409df327c4d7f611404ab9861a0
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
The CEC_TRANSMIT ioctl now returns -EPERM if an attempt is made to
transmit a message for an unconfigured adapter (i.e. userspace
never called CEC_ADAP_S_LOG_ADDRS).
This differentiates this case from when LAs are configured, but no
physical address is set. In that case -ENONET is returned.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 059d1460ca)
Change-Id: I84a80862ee751da109d617cc264aed6e92911432
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
The CEC specifications explicitly allows you to send poll messages and
Image/Text View On messages to a TV, even when unconfigured (i.e. there is
no hotplug signal detected). Some TVs will pull the HPD low when switching
to another input, or when going into standby, but CEC should still be
allowed to wake up such a display.
Add support for sending messages with initiator 0xf (Unregistered) and
destination 0 (TV) when no physical address is present.
This also required another change: the CEC adapter has to stay enabled as
long as 1) the CEC device is configured or 2) at least one filehandle is open
for the CEC device.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 533a3f7bc7)
Change-Id: Icf95c1aa5f48ea7989792b88cd1e47373fda2b08
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
When the adapter is unloaded or unconfigured, then all transmits and
pending waits should be flushed.
Move this code into its own function and improve the code that cancels
delayed work to avoid having to unlock adap->lock.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit b39f93efc6)
Change-Id: Idc609583c55cba910b215ac3fe127583510ee08c
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
If HDMI output corlor mode is YCbCr422, the tmds clock is same
to YCbCr444 8bit, phy bus width should be set to 8.
Change-Id: I6e844e676a6315ae0cb88b0bd8456f0e27fa5e0c
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
when vpu reset, sometimes will failed when set power domain
idle
Change-Id: I38185cce616adb41e698b0c95793934abbd51f62
Signed-off-by: Jung Zhao <jung.zhao@rock-chips.com>
Add ftl code for kernel which compiled with thumb instruction set.
Change-Id: I1213b7332612978d836b7ac34d019a586d087ec6
Signed-off-by: Zhaoyifeng <zyf@rock-chips.com>
add rockchip_dmc as a cooling device in thermal control
Change-Id: Iefb046a104eb2205f2ef17dd80bb31fd75b42c90
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
We enable the Wired Ethernet, analog audio output, HDMI
output, USB ports, SDMMC and video devices.
Change-Id: I184ebc8bd8f2317b1e435939e18bdc014ea487a9
Signed-off-by: Hans Yang <yhx@rock-chips.com>
Signed-off-by: ayaka <ayaka@soulik.info>
Interrupts with the IRQF_FORCE_RESUME flag set have also the
IRQF_NO_SUSPEND flag set. They are not disabled in the suspend path, but
must be forcefully resumed. That's used by XEN to keep IPIs enabled beyond
the suspension of device irqs. Force resume works by pretending that the
interrupt was disabled and then calling __irq_enable().
Incrementing the disabled depth counter was enough to do that, but with the
recent changes which use state flags to avoid unnecessary hardware access,
this is not longer sufficient. If the state flags are not set, then the
hardware callbacks are not invoked and the interrupt line stays disabled in
"hardware".
Set the disabled and masked state when pretending that an interrupt got
disabled by suspend.
Fixes: bf22ff45be ("genirq: Avoid unnecessary low level irq function calls")
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrovsky@oracle.com
Link: http://lkml.kernel.org/r/20170717174703.4603-2-jgross@suse.com
(cherry picked from commit a696712c3d)
Conflicts:
kernel/irq/internals.h
[due to missing upstream patch: b354286eff irq: Privatize irq_common_data::state_use_accessors]
Change-Id: I94d230ff1a7ccac1234432384685b5ef9d116b0a
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Shared interrupts do not go well with disabling auto enable:
1) The sharing interrupt might request it while it's still disabled and
then wait for interrupts forever.
2) The interrupt might have been requested by the driver sharing the line
before IRQ_NOAUTOEN has been set. So the driver which expects that
disabled state after calling request_irq() will not get what it wants.
Even worse, when it calls enable_irq() later, it will trigger the
unbalanced enable_irq() warning.
Reported-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: dianders@chromium.org
Cc: jeffy <jeffy.chen@rock-chips.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: tfiga@chromium.org
Link: http://lkml.kernel.org/r/20170531100212.210682135@linutronix.de
(cherry picked from commit 04c848d398)
Change-Id: I89711656f22e15697c76a4dcb9c60c8b0c8052d2
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
If an interrupt is marked NOAUTOEN then request_irq() installs the action,
but does not enable the interrupt via startup_irq(). The interrupt is
enabled via enable_irq() later from the driver. enable_irq() calls
irq_enable().
That means that for interrupts which have a irq_startup() callback this
callback is never invoked. Neither is irq_domain_activate_irq() invoked for
such interrupts.
If an interrupt depends on irq_startup() or irq_domain_activate_irq() then
the enable via irq_enable() is not enough.
Add a status flag IRQD_IRQ_STARTED_UP and use this to select the proper
mechanism in enable_irq(). Use the flag also to avoid pointless calls into
the low level functions.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: dianders@chromium.org
Cc: jeffy <jeffy.chen@rock-chips.com>
Cc: Brian Norris <briannorris@chromium.org>
Cc: tfiga@chromium.org
Link: http://lkml.kernel.org/r/20170531100212.130986205@linutronix.de
(cherry picked from commit 201d7f47f3)
Conflicts:
include/linux/irq.h
[due to missing upstream patches:
08d85f3 irqdomain: Avoid activating interrupts more than once
1a3d28a UPSTREAM: genirq: Introduce IRQD_AFFINITY_MANAGED flag
6297714 UPSTREAM: irq: Privatize irq_common_data::state_use_accessors]
Change-Id: Ie8d492c694171fa81e3df61e8561bec160ad37bb
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
enable CONFIG_ROCKCHIP_MPP_SERVICE and CONFIG_ROCKCHIP_MPP_DEVICE
of rockchip_defconfig for encoder.
Change-Id: I30069af7af82f6731f322c4b93e3a7c6009e8434
Signed-off-by: Rimon Xu <rimon.xu@rock-chips.com>
1.when release buffer should call vpu_iommu_clear function.
2.before call vpu_iommu_clear that we should call
vpu_drm_unmap_iommu&vpu_drm_free if there is through
vpu_drm_alloc to allocate buffer.
Change-Id: I01e7fac88c6da40e8cb4ee2199dd38283323783b
Signed-off-by: Xinhuang Li <buluess.li@rock-chips.com>
The test results indicate that larger transfers improve
mtp read/write speeds. The Tx/Rx request transfer length
is now 16K bytes. Increase the Tx/Rx transfer length from
16K to 64K to get good throughputs.
For USB DWC3 controller, you can try to increase the
Tx/Rx transfer length from 16K to 1MB to get better
throughputs.
Change-Id: If5ac41685acdc9b9d2db7f7f79e183e3dff7b558
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch backport from https://android.googlesource.com/kernel/msm
android-msm-wahoo-4.4-oreo-mr1
commit 79dc83a8cb933b8f0d746169961347a54c530ef1
This change captures time taken by each vfs_read() and vfs_write() call
made from USB MTP gadget driver where data size is equal to USB request
buffer size. It provides debugfs entry to get this information for 100
such call and resetting the same.
How-To use:
To get stats:
cat /sys/kernel/debug/usb_mtp/status
To reset stats:
echo 0 > /sys/kernel/debug/usb_mtp/status
Change-Id: Iade04950d1dce936fc1f88387da5e4fa74cd30df
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
This patch backport from https://android.googlesource.com/kernel/msm
android-msm-wahoo-4.4-oreo-mr1
commit 1f6b38f5293cfd619adcfac152e6d32ba6b40023
The Tx request transfer length is 16K bytes by default. The test
results indicate that larger transfers improve read speeds. Add
provision for specifying Tx transfer length at runtime.
echo 1048576 > /sys/module/usb_f_mtp/parameters/mtp_tx_req_len
The above command can be used to set Tx transfer length to 1MB. If
the memory allocation is failed, fallback to the default length.
Also add provision for specifying no. of Tx requests at runtime.
echo 8 > /sys/module/usb_f_mtp/parameters/mtp_tx_reqs
Change-Id: I9aa2210e145310ba79e79d353688a46c877ecb6b
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch backport from https://android.googlesource.com/kernel/msm
android-msm-wahoo-4.4-oreo-mr1
commit 1bb8887af8b525e68d9c9e7c828836a3d17ab0b3
The Rx request transfer length is 16K bytes by default. The test
results indicate that larger transfers improve write speeds. Add
provision for specifying Rx transfer length at runtime.
echo 1048576 > /sys/module/usb_f_mtp/parameters/mtp_rx_req_len
The above command can be used to set Rx transfer length to 1MB. If
the memory allocation is failed, fallback to the default length.
Change-Id: If5a7d4a167ec4a9e080fcd10caa95884d765a3b6
Signed-off-by: William Wu <william.wu@rock-chips.com>
It looks like should add gpio base in the gpiolib instead of
each gpio or pinctrl driver, and base defined in the gpio.h.
If the definition of base is 0, then it is the same as the
original, now the definition of base is 1000.
The dynamic assignment of a range of valid GPIOs should be
also from the defined base.
Change-Id: I636bc71a5ba078fd5e1bc9a476cdcf942aa8010a
Signed-off-by: David Wu <david.wu@rock-chips.com>
if not add HDMI_SWITCH node, h_5V will be disabled when resume
Change-Id: I06349a4e1f8c6caabaaa93f95db92ae514957d48
Signed-off-by: Shunqing Chen <csq@rock-chips.com>
Some nodes are always used for android, so we move them to android.dtsi.
Change-Id: Ifc5ef68dd00f14a0faec4a24998feef6dc592d5e
Signed-off-by: Liang Chen <cl@rock-chips.com>
