Poll messages that are used to allocate a logical address should
use the same initiator as the destination. Instead, it expected that
the initiator was 0xf which is not according to the standard.
This also had consequences for the message checks in cec_transmit_msg_fh
that incorrectly rejected poll messages with the same initiator and
destination.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 42980da2eb)
Change-Id: Ib00532f887be8758f5bbaf284f63656770e7f3f2
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.
Suggested-by: Sean Young <sean@mess.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 0f7499fddb)
Change-Id: Ic145f8c2ce310dacaa53d18f3f5dcb846ac1a967
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Due to an incorrect condition the last_la used for the initial attempt at
claiming a logical address could be wrong.
The last_la wasn't converted to a mask when ANDing with type2mask, so that
test was broken.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit f9f96fc10c)
Change-Id: I7de00bb0346c8bf78ca4910bf1b22bf63d3674c2
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
This race was discovered by running cec-compliance -A with the cec module debug
parameter set to 2: suddenly the test would fail.
It turns out that this happens when the test configures the adapter in
non-blocking mode, then it waits for the CEC_EVENT_STATE_CHANGE event and once
the event is received it unconfigures the adapter.
What happened was that the unconfigure was executed while the configure was
still transmitting the Report Features and Report Physical Address messages.
This messed up the internal state of the cec_adapter.
The fix is to transmit those messages with the adap->lock mutex held (this will
just queue them up in the internal transmit queue, and not actually transmit
anything yet). Only unlock the mutex once everything is done. The main thread
will dequeue the messages from the internal transmit queue and transmit them
one by one, unless an unconfigure was done, and in that case any messages are
just dropped.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit f60f35609f)
Change-Id: I210f2d09f2ca7ce7733580bbefa6474b38a354cd
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
It's only a small function and this makes it easier to switch to
transmitting the message with adap->lock held in the next patch.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit d3d64bc740)
Change-Id: I936ba05b9b70681d57d52e10645f8865a27f5689
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The fill function just fills in the cec_msg struct, it doesn't transmit
the message. This is now done explicitly.
This makes it possible to switch to transmitting this message with adap->lock
held.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 52bc30fda9)
Change-Id: Ie6c7a1f88b5691b8e4240af697646387db2e11a9
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The loop that sets the unused logical addresses to INVALID should be
done before 'configured' is set to true. This ensures that cec_log_addrs
is consistent before it will be used.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 7af26f889e)
Change-Id: I431f4df06482c20c1a33d7b32afc742e61947425
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
This is a 2.0 only message, so it should return Feature Abort if the
adapter is configured for CEC version 1.4.
Right now it does nothing, which means that the sender will time out.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit a24f56d479)
Change-Id: Ibd812b99013bf83a080c0c89219b8fef4396cd88
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
When a pending message was canceled (e.g. due to a timeout), then the
old tx_status info was overwritten instead of ORed. The same happened
with the tx_error_cnt field. So just modify them instead of overwriting
them.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 1204761236)
Change-Id: Ibec7ccb5c1adaff39eb90f1ed4e0a962d9581746
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
In the (very) small print of the REPORT_CURRENT_LATENCY message there is a
line that says that the last byte of the message (audio out delay) is only
present if the 'audio out compensated' value is 3.
I missed this, and so if this message was sent with a total length of 6 (i.e.
without the audio out delay byte), then it was rejected by the framework
since a minimum length of 7 was expected.
Fix this minimum length check and update the wrappers in cec-funcs.h to do
the right thing based on the message length.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit f3854973f1)
Change-Id: Iec4d9db94bb66194ec68c014a06f8b2d33f1dbdb
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The cec_allocate_adapter function doesn't need the parent device, only the
cec_register_adapter function needs it.
Drop the cec_devnode parent field, since devnode.dev.parent can be used
instead.
This change makes the framework consistent with other frameworks where the
parent device is not used until the device is registered.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit f51e80804f)
Change-Id: Ib9a26eedf0e07f5964482d8cbb2c4698031d7bd9
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Some CEC adapters will receive messages that they initiated. Add a
check that will ignore such messages.
Most hardware behaves correctly in this respect, but I have seen
adapters that don't, so just filter this out in the framework.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 3f98da9636)
Change-Id: I3940308265d3e6f9370a3004fdd24945409f7a4b
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Make sure the TX counters are zeroed in the cec_msg struct.
Non-zero TX counters make no sense when a message is received,
and applications should not see non-zero values here.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 8991a63d1a)
Change-Id: Ia592fe3992b4897ad5589c6bbb0976d48d630b78
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
An inner for-loop reused the outer loop variable. This was
only noticeable with CEC adapters supporting more than one
logical address.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit a161bef042)
Change-Id: I332d480bb6e73d55724634ade1bc038f9719cb09
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Replace bool by int or __u8 (when used in a struct).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 3145c754ac)
Change-Id: I690eccd438339cf490e746ba6ef780f705b1046a
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The CEC_MSG_FL_REPLY_TO_FOLLOWERS message flag only makes sense for transmitted
messages where you want to wait for the reply.
Clear the flag in all other cases.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 7ae2a888ee)
Change-Id: I38c78404e023616c4b79ecb08d9d01b7fc8684e6
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The last open issues have been addressed, so it is time to move
this out of staging and into the mainline and to move the public
cec headers to include/uapi/linux.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 0dbacebede)
Change-Id: I7bf14806f5043a2565328fa715cf44fe2b4ad713
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The cec_get_edid_spa_location() function did not verify that the IEEE
identifier in the Vendor Specific Data Block matched the HDMI-LLC
identifier. This could result in the wrong VSDB block being returned.
For example, for HDMI 2.0 EDIDs there is also a HDMI Forum VSDB.
So check the IEEE identifier as well.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 8ac6a1a53e)
Change-Id: I982189124b438906e34f57a3fdd9b6da4c202f19
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
This lock will be used to protect more than just the fhs list.
So rename it to just 'lock'.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 62148f0930)
Change-Id: Ib8f66aec21134ffe333afc3d7d926d1c0844798d
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The size of the transmit queue was unlimited, which meant that
in non-blocking mode you could flood the CEC adapter with messages
to be transmitted.
Limit this to 18 messages.
Also print the number of pending transmits and the timeout value
in the status debugfs file.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 11065f8531)
Change-Id: I1d143e076ed8a4708a3e6240faf41c6434367d11
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
- Use IS_REACHABLE(RC_CORE) instead of IS_ENABLED: if cec is built-in and
RC_CORE is a module, then CEC can't reach the RC symbols.
- Both cec and cec-edid should be bool and use the same build 'mode' as
MEDIA_SUPPORT (just as is done for the media controller code).
- Add a note to staging that this should be changed once the cec framework
is moved out of staging.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 5bb2399a4f)
Change-Id: I7a5812f3784b0a52f0e3545582a35032e9b7ba3f
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.
Note that the CEC framework is added to staging/media and that the
cec.h and cec-funcs.h headers are not exported yet. While the kABI
is mature, I would prefer to allow the uABI some more time before
it is mainlined in case it needs more tweaks.
This adds the cec-core.c, media/cec.h and cec-priv.h sources.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
[k.debski@samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.debski@samsung.com: Merged Update author commit by Hans Verkuil]
[k.debski@samsung.com: code cleanup and fixes]
[k.debski@samsung.com: add missing CEC commands to match spec]
[k.debski@samsung.com: add RC framework support]
[k.debski@samsung.com: move and edit documentation]
[k.debski@samsung.com: add vendor id reporting]
[k.debski@samsung.com: reorder of API structs and add reserved fields]
[k.debski@samsung.com: fix handling of events and fix 32/64bit timespec problem]
[k.debski@samsung.com: add sequence number handling]
[k.debski@samsung.com: add passthrough mode]
[k.debski@samsung.com: fix CEC defines, add missing CEC 2.0 commands]
Signed-off-by: Kamil Debski <kamil@wypas.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit a56960e8b4)
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Change-Id: I3063b08b8b818501a683f701d014533bc533d163
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
The cec-edid module contains helper functions to find and manipulate
the CEC physical address inside an EDID. Even if the CEC support itself
is disabled, drivers will still need these functions. Which is the
reason this is module is separate from the upcoming CEC framework.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 29fb44a58a)
Change-Id: Id59a72db27d140abee0e0bb98b062a7131de7263
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Calculate the calibration code as per the docs. The docs talk about
reading and averaging the pullup and pulldown calibration codes. They
also talk about adding in some adjustment codes. Let's do what the
docs say.
In practice this doesn't seem to matter a whole lot. On a device I
tested the pullup and pulldown codes were nearly the same (0x23 and
0x24) and the adjustment codes were 0.
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from commit e023b1fb52)
Change-Id: I7c8304db69f8c6aacdd889a58d4bb7f185507f9d
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
NOTE: nothing is known to be fixed by this change, but it does enforce
some delays that are documented to be necessary. Possibly this could
fix some corner cases.
The function tcphy_dp_aux_calibration(), like most of the functions in
the type C PHY, is mostly undocumented and filled with mysterious,
hardcoded numbers.
Let's attempt to try to document some of these numbers and clean the
function up a little bit. Here's the actual cleanup that happened
here:
1. All magic numbers were replaced with bit definitions.
2. For registers that we modify multiple times I now keep track of the
value of the register rather than randomly doing a
read/modify/write or just hardcoding a new number based on knowing
what the old number was.
3. Delay 10 ms (vs 1 ms) after writing the calibration code. No idea
if this is important but it matches the example in the docs.
4. Whenever setting a "delayed" version of a signal always put an
explicit delay in the code. No known problems were seen without
this delay but it seems wise to have it. Whenever a delay of "at
least 100 ns" was specified I used a delay of 1 us.
5. Added comments to some of the bits of code.
6. Removed duplicate setting of TX_ANA_CTRL_REG_5 (to 0)
7. Moved setting of TX_ANA_CTRL_REG_3 to the same place it was in the
sample code. Note that TX_ANA_CTRL_REG_3 ought to be initted to 0
(and elsewhere we assume that we just got a reset), but it seems
fine to be explicit.
8. Treats the calibration code as a 7-bit two's complement number.
This isn't strictly required, but seems slightly cleaner. The docs
say "treat this as a two's complement number, but it should never
be negative". If we ever read the "adjustment" codes as documented
then perhaps the two's complement bit will matter more.
There are still a few weird / mysterious things around aux init and
this doesn't attempt to fix all of them. Mostly it's aimed at doing
changes that should be _very_ safe and add a lot of clarity. Things
specifically not done:
A) Resolve the fact that some registers are read/modify/write and
others are explicitly initted to a value. We always call
tcphy_dp_aux_calibration() right after resetting the PHY so it's
probably not critical, but it's a little weird that the code is
inconsistent.
B) Fully resolve the documented init sequence with the current one.
We still have a few mystery steps and we also leave out turning on
TXDA_DRV_LDO_BG_FB_EN and TXDA_DRV_LDO_BG_REF_EN, which is in the
sample code.
C) Clean things up to read all the bits of the calibration code. This
will hopefully come in a followup change.
This also doesn't attempt to document any of the other parts of the
PHY--just the aux init which is all I got docs for.
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from commit f85fd4c909)
Change-Id: I8581976b31978d7a3fa39d9679c40537572d5342
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
The function tcphy_phy_init() could return an error but the callers
weren't checking the return value. They should. In at least one case
while testing I saw the message "wait pma ready timeout" which
indicates that tcphy_phy_init() really could return an error and we
should account for it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from commit 2fb850092f)
Change-Id: Ic95e962f67845fb5fda0495f9ea20036b7069b3c
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.
In the case of cpuidle, CPUs exit the kernel a number of levels deep in
C code. Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.
If CPUs lose context and return to the kernel via a cold path, we
restore a prior context saved in __cpu_suspend_enter are forgotten, and
we never remove the poison they placed in the stack shadow area by
functions calls between this and the actual exit of the kernel.
Thus, (depending on stackframe layout) subsequent calls to instrumented
functions may hit this stale poison, resulting in (spurious) KASAN
splats to the console.
To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.
Change-Id: Iac090ed3bc54cc4180f18d7e5f1540c6c755dcab
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 0d97e6d802)
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poision prior to returning.
In the case of CPU hotplug, CPUs exit the kernel a number of levels deep
in C code. Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.
When a CPU is subsequently brought back into the kernel via a different
path, depending on stackframe, layout calls to instrumented functions
may hit this stale poison, resulting in (spurious) KASAN splats to the
console.
To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.
Change-Id: Idd24e933ce0a93b500d17de8262afe6e43d565c8
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit e1b77c9298)
Functions which the compiler has instrumented for ASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.
In some cases (e.g. hotplug and idle), CPUs may exit the kernel a
number of levels deep in C code. If there are any instrumented
functions on this critical path, these will leave portions of the idle
thread stack shadow poisoned.
If a CPU returns to the kernel via a different path (e.g. a cold
entry), then depending on stack frame layout subsequent calls to
instrumented functions may use regions of the stack with stale poison,
resulting in (spurious) KASAN splats to the console.
Contemporary GCCs always add stack shadow poisoning when ASAN is
enabled, even when asked to not instrument a function [1], so we can't
simply annotate functions on the critical path to avoid poisoning.
Instead, this series explicitly removes any stale poison before it can
be hit. In the common hotplug case we clear the entire stack shadow in
common code, before a CPU is brought online.
On architectures which perform a cold return as part of cpu idle may
retain an architecture-specific amount of stack contents. To retain the
poison for this retained context, the arch code must call the core KASAN
code, passing a "watermark" stack pointer value beyond which shadow will
be cleared. Architectures which don't perform a cold return as part of
idle do not need any additional code.
This patch (of 3):
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poision prior to returning.
In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
of levels deep in C code. If there are any instrumented functions on this
critical path, these will leave portions of the stack shadow poisoned.
If a CPU returns to the kernel via a different path (e.g. a cold entry),
then depending on stack frame layout subsequent calls to instrumented
functions may use regions of the stack with stale poison, resulting in
(spurious) KASAN splats to the console.
To avoid this, we must clear stale poison from the stack prior to
instrumented functions being called. This patch adds functions to the
KASAN core for removing poison from (portions of) a task's stack. These
will be used by subsequent patches to avoid problems with hotplug and
idle.
Change-Id: I0cfdd3ece4cb59876292f5ba1cadcdbda19de758
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit e3ae116339)
In the case u2phy control vbus, the driver of usb controller
must control the vbus through the interface of u2phy, this
patch change the mode of u2phy when change dr_mode.
Change-Id: I8447bffc55e3502bf53a2e8af841a74914571781
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
This patch supported the gpu opp table for rk3036.
The gpu clock's parent is DPLL, the default frequency is 400MHz, we need
assign 400MHz for gpu to be better working.
There is a quickly way for testing the gpu scaling frequency.
As following:
"
unset FREQS
read -a FREQS < /sys/class/devfreq/10091000.gpu/available_frequencies
RANDOM=$$$(date +%s)
while true; do
echo userspace > /sys/class/devfreq/10091000.gpu/governor
FREQ=${FREQS[$RANDOM % ${#FREQS[@]} ]}
echo GPU:Now ${FREQ}
echo ${FREQ} > /sys/class/devfreq/10091000.gpu/userspace/set_freq
sleep 1
done
"
Change-Id: Ia8eb3074e457014c497338a0a129551c51450104
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
As the gpu driver used the devfreq thermal, The mali will be failure to
load the driver since the rk platform hadn't the driver requested
deferred probing.
as the following is failure log:
[ 7.126149] Mali: ERR: drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c
[ 7.126157] mali_probe() 550
mali_probe(): Failed to initialize platform device.
[ 7.126191] mali-utgard: probe of 10091000.gpu failed with error -14
..
Add the SoCs judge if we will use the devfreq-thermal for mali driver.
If the other SoCs has the similar issue, we can do this way.
Change-Id: I9faf6530119adb99efeac491e665641ee8b1143d
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
This commit adds a compatible string for everest,es8388. This is
an audio codec that is compatible with es8328.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 5f166156db)
Change-Id: I526239c3f4062849f2c96a610cf261f0f0de7aa4
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Instead of letting drivers fill in device_caps at querycap time,
let them fill it in when the video device is registered.
This has the advantage that in the future the v4l2 core can access
the video device's capabilities and take decisions based on that.
(am from 7bbe781329)
Change-Id: I2cc64fc2e562f7def0bea07c9b53a39ba4d772c3
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This driver is modified from an old soc_camera driver.
It's kind of rough.
Change-Id: Ifb2656c5398277ace6902771128637f5dfd68061
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The V4L2_BUF_TYPE_META_OUTPUT mirrors the V4L2_BUF_TYPE_META_CAPTURE with
the exception that it is an OUTPUT type. The use case for this is to pass
buffers to the device that are not image data but metadata. The formats,
just as the metadata capture formats, are typically device specific and
highly structured.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
(am from https://patchwork.linuxtv.org/patch/43308/)
Conflicts:
drivers/media/v4l2-core/v4l2-ioctl.c
include/media/v4l2-ioctl.h
BUG=b:66317170
TEST=compile
Change-Id: I86495fe82bf8dbddbc40f0ee1eb8e21145f427d3
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676768
Reviewed-by: Ricky Liang <jcliang@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The metadata buffer type is used to transfer metadata between userspace
and kernelspace through a V4L2 buffers queue. It comes with a new
metadata capture capability and format description.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
[hans.verkuil@cisco.com: removed left-over 'experimental' note]
[hans.verkuil@cisco.com: add newline after _v4l2-meta-format label]
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit fb9ffa6a7f)
Conflicts:
Documentation/media/uapi/v4l/buffer.rst
Documentation/media/uapi/v4l/devices.rst
Documentation/media/uapi/v4l/vidioc-querycap.rst
Documentation/media/videodev2.h.rst.exceptions
drivers/media/v4l2-core/v4l2-dev.c
drivers/media/v4l2-core/videobuf2-v4l2.c
include/media/v4l2-ioctl.h
Deleted the documentation, as 4.4 is before the conversion to rst.
BUG=b:66317170
TEST=compile
Change-Id: Id43757c0a0b1f34e10d17e5345f89ded25503d13
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676767
Reviewed-by: Ricky Liang <jcliang@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The formats use three planes through the multiplanar API, allowing for
non-contiguous planes in memory.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
(cherry picked from commit d65fae92f9)
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chrome-os-partner:60805
TEST=build chromeos-4.4 for elm and boot
TEST=build chromeos-4.4 for kevin and boot
BUG=chrome-os-partner:43703
TEST=Compiled and tested on Elm.
Signed-off-by: Ricky Liang <jcliang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420108
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Change-Id: I12fd0f0dc41325867777ae3723331926d5150d20
Reviewed-on: https://chromium-review.googlesource.com/424021
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The vbus may need control by u2phy when force. This patch
control vbus when set phy mode.
Change-Id: I237e9e3688b257689c79040f19642cea5365d409
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
1.Change rga1 driver to use dma API.
2.Fixup problem: version error.
Change-Id: Ibe8ac78927ec3b00e857c9c1e3c7321e418ede31
Signed-off-by: Putin Lee <putin.li@rock-chips.com>
Most of rockchip SoCs USB 2.0 DP/DM can be bypassed to UART,
it's useful for those platforms without UART interface to
print log via USB interface.
For the time being, we just support for rk312x and rk3399 in
this driver. And we will support for more SoCs in the feature.
With this patch, the user still can't use this bypass function.
It needs to add the property "rockchip,bypass-uart" in the DT
as following:
u2phy0_otg: otg-port {
...
rockchip,bypass-uart;
...
};
And it also needs a special USB cable integrated with an USB
to UART chip.
Note: this function can only be used in debug stage.
Change-Id: Icdab516ff7b327f4a98c3b24bbaf953a605f5278
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
