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 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>
add power and qos node to support power domain on/off.
Change-Id: I35088bfa7be407d7c627e32a84f2aafd1853e2df
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
This driver is modified to support RK3128 SoC.
Change-Id: Ica063ae432fe5bdc1d4eb10d0749fcf039f43d35
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip RK3128 SoCs.
Change-Id: I8ca00fdf19bfcf354355eafd814f049b46533fd6
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
According to a description from TRM, add all the power domains.
Change-Id: Id21e1b51825f7cc94e194e164583ed2584743104
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
This patch supported the cpu voltage by changed with different
frequency, otherwise we will hit the following error on bootup.
..
[ 5.031516] cpu cpu0: Failed to get cpu_reg
[ 5.047725] cpu cpu0: clk or regulater is unavailable
..
Also, remove the 408M and 600M for rk3036 board, as the pclk_hdmi's parent
on apll, the low frequency will make the pclk be bad for hdmi display.
Change-Id: Ia4aac76a08cad3a59c33cd81065f943201a23a35
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
HDR source metadata set and get property implemented in this
patch. The blob data is received from userspace and saved in
connector state, the same is returned as blob in get property
call to userspace.
Change-Id: Iafde7d4d4a9567d54b283d8387d841e42d7b5b24
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from list https://patchwork.kernel.org/patch/9756449/)
The hdr_panel_metadata indicate sink HDR capability，moving
it to drm_hdmi_info is more reasonable.
Change-Id: I0ccd404cfb0ec1e74130b0692de4261ae9a24c8f
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Change-Id: I8025c3dba43dc5bb614115ede7841fe89d9f4d0b
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9756447/)
This patch fixes the BT power reported the failure message.
As following:
root@linaro-alip:~# echo 1 > /sys/class/rfkill/rfkill0/state
[ 892.558269] rockchip-pinctrl pinctrl: pin gpio0-19 already requested
by 20060000.serial; cannot claim for wireless-bluetooth
[ 892.571052] rockchip-pinctrl pinctrl: pin-19 (wireless-bluetooth) status -22
...
And for now, the BT can work with this patch.
root@linaro-alip:~# echo 1 > /sys/class/rfkill/rfkill0/state
[ 69.328768] [BT_RFKILL]: ENABLE UART_RTS
[ 69.438540] [BT_RFKILL]: DISABLE UART_RTS
[ 69.443117] [BT_RFKILL]: bt turn on power
...
root@linaro-alip:~# hcitool dev
Devices:
hci0 94:A1:A2:E9:2D:18
And
root@linaro-alip:~# bluetoothctl
[NEW] Controller 94:A1:A2:E9:2D:18 linaro-alip [default]
[bluetooth]# scan on
Discovery started
[CHG] Controller 94:A1:A2:E9:2D:18 Discovering: yes
..
Change-Id: I2148f4203300ab4265fd3ba718f0d3ec0c57e7ca
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
select CFG80211 and MAC80211 when CONFIG_WIFI_BUILD_MODULE is set
Change-Id: I42acf5d554223b13c0c689b8edae15b4a7a57a70
Signed-off-by: Alex Zhao <zzc@rock-chips.com>
The recent CTO timer introduced in commit 03de19212e ("mmc: dw_mmc:
introduce timer for broken command transfer over scheme") was causing
observable problems due to race conditions. Previous patches have
fixed those race conditions.
It can be observed that these same race conditions ought to be
theoretically possible with the DTO timer too though they are
massively less likely to happen because the data timeout is always set
to 0xffffff right now. That means even at a 200 MHz card clock we
were arming the DTO timer for 94 ms:
>>> (0xffffff * 1000. / 200000000) + 10
93.886075
We always also were setting the DTO timer _after_ starting the
transfer, unlike how the old code was seting the CTO timer.
In any case, even though the DTO timer is much less likely to have
races, it still makes sense to add code to handle it _just in case_.
Change-Id: I87a1707399b64d43278239ddd830c3270402239a
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002771/)
Just like the CTO timeout calculation introduced recently, the DTO
timeout calculation was incorrect. It used "bus_hz" but, as far as I
can tell, it's supposed to use the card clock. Let's account for the
div value, which is documented as 2x the value stored in the register,
or 1 if the register is 0.
NOTE: This was likely not terribly important until commit 16a34574c6
("mmc: dw_mmc: remove the quirks flags") landed because "DIV" is
documented on Rockchip SoCs (the ones that used to define the quirk)
to always be 0 or 1. ...and, in fact, it's documented to only be 1
with EMMC in 8-bit DDR52 mode. Thus before the quirk was applied to
everyone it was mostly OK to ignore the DIV value.
I haven't personally observed any problems that are fixed by this
patch but I also haven't tested this anywhere with a DIV other an 0.
AKA: this problem was found simply by code inspection and I have no
failing test cases that are fixed by it. Presumably this could fix
real bugs for someone out there, though.
Change-Id: I0d81f991e10e60b8d03ee330b34d08af34a33fcb
Fixes: 16a34574c6 ("mmc: dw_mmc: remove the quirks flags")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002751/)
This attempts to instill a bit of paranoia to the code dealing with
the CTO timer. It's believed that this will make the CTO timer more
robust in the case that we're having very long interrupt latencies.
Note that I originally thought that perhaps this patch was being
overly paranoid and wasn't really needed, but then while I was running
mmc_test on an rk3399 board I saw one instance of the message:
dwmmc_rockchip fe320000.dwmmc: Unexpected interrupt latency
I had debug prints in the CTO timer code and I found that it was
running CMD 13 at the time.
...so even though this patch seems like it might be overly paranoid,
maybe it really isn't?
Presumably the bad interrupt latency experienced was due to the fact
that I had serial console enabled as serial console is typically where
I place blame when I see absurdly large interrupt latencies. In this
particular case there was an (unrelated) printout to the serial
console just before I saw the "Unexpected interrupt latency" printout.
...and actually, I managed to even reproduce the problems by running
"iw mlan0 scan > /dev/null" while mmc_test was running. That not only
does a bunch of PCIe traffic but it also (on my system) outputs some
SELinux log spam.
Change-Id: I56373c6740d38b5c45a078e835f594261bad78d2
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002767/)
In the commit 03de19212e ("mmc: dw_mmc: introduce timer for broken
command transfer over scheme") we tried to calculate the expected
hardware command timeout value. Unfortunately that calculation isn't
quite correct in all cases. It used "bus_hz" but, as far as I can
tell, it's supposed to use the card clock. Let's account for the div
value, which is documented as 2x the value stored in the register, or
1 if the register is 0.
NOTE: It's not expected that this will actually fix anything important
since the 10 ms margin added by the function will pretty much dwarf
any calculations. The card clock should be 100 kHz at minimum and:
1000 ms/s * (255 * 2) / 100000 Hz.
Gives us 5.1 ms.
...so really the point of this patch is just to make the code more
"correct" in case anyone ever tries to remove the 10 ms buffer.
Change-Id: Ie5d902edb3a5bdfb9dc9233eb46edbbee334994c
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002775/)
When running with the commit 03de19212e ("mmc: dw_mmc: introduce
timer for broken command transfer over scheme") I found this message
in the log:
Unexpected command timeout, state 7
It turns out that we weren't properly cancelling the new CTO timer in
the case that a voltage switch was done. Let's promote the cancel
into the dw_mci_cmd_interrupt() function to fix this.
Change-Id: I2ee3537eb7a756d64964cc49114011ad329409b8
Fixes: 03de19212e ("mmc: dw_mmc: introduce timer for broken command transfer over scheme")
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from https://patchwork.kernel.org/patch/10002779/)
Also:
- correct the default quantization for RGB input, it should be full range.
Change-Id: I786799a3532b5c3a18e67c9195ec24ea811d1144
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Introduce mtmdsclock to record tmds clock, which is different
to mpixelclock in deep color mode. Use this variable to select
synopsys phy curr_ctrl/phy_config, and audio N/CTS.
Change-Id: Ia78dee9c4901d2f1ca7f339dfb030d65bbf6861d
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch is based on https://patchwork.kernel.org/patch/9801533,
add the drm property "hdmi_output_format", the possible value
could be:
- RGB
- YCBCR 444
- YCBCR 422
To handle various subsampling of YCBCR output types, this property
allows two special automatic cases:
- DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output,
with highest subsampling rate by the source/sink, which
can be typically:
- ycbcr444
- ycbcr422
- ycbcr420
- DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with
lowest subsampling rate supported by source/sink, which can be:
- ycbcr420
- ycbcr422
- ycbcr444
Default value of the property is set to 0 = RGB, so no changes if you
don't set the property.
Change-Id: Ie4a98ba91c8285a2e8f1ec7832d73183ad57665e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch introduce a drm property hdmi_output_depth to
get/set HDMI color depth, the possible value could be
- Automatic
This indicates prefer highest color depth, it is
30bit on rockcip platform.
- 24bit
- 30bit
The default value of property is 24bit.
The max_tmds_clock is 0 on some display device, we think it's
max_tmds_clock is 340MHz.
If tmdsclock > max_tmds_clock, real output color depth fallback
to 24bit.
Change-Id: I666ac85d1ce5e73af31251eae324d1a6ae00b31e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
