Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
On 10/08/2018 01:53 PM, Hans Verkuil wrote: > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace support > for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to prepare > for that in advance, esp. since I myself do not have any experience writing > userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to work > for most of us (because the topics in the program appear to be boring for us > media types!): > > Tuesday from 10:50-15:50 Let's do this Tuesday. Let's meet at the Linux Foundation Registration Desk at 11:00. I'll try to figure out where we can sit the day before. Please check your email Tuesday morning for any last minute changes. Tomasz, it would be nice indeed if we can get you and Paul in as well using Hangouts on my laptop. I would very much appreciate it if those who have experience with the userspace support think about this beforehand and make some requirements list of what you would like to see. Regards, Hans > > or: > > Monday from 15:45 onward > > My guess is that we need 2-3 hours or so. Hard to predict. > > The basic question that I would like to have answered is what the userspace > component should look like? libv4l-like plugin or a library that userspace can > link with? Do we want more general support for stateful codecs as well that > deals > with resolution changes and the more complex parts of the codec API? > > I've mailed this directly to those that I expect are most interested in this, > but if someone want to join in let me know. > > I want to keep the group small though, so you need to bring relevant > experience > to the table. > > Regards, > > Hans >
enquiry 09-10-2018
Hi,friend, This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia. We are glad to know about your company from the web and we are interested in your products. Could you kindly send us your Latest catalog and price list for our trial order. Best Regards, Daniel Murray Purchasing Manager
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
Hi Hans, On Mon, Oct 8, 2018 at 8:53 PM Hans Verkuil wrote: > > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace support > for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to prepare > for that in advance, esp. since I myself do not have any experience writing > userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to work > for most of us (because the topics in the program appear to be boring for us > media types!): > > Tuesday from 10:50-15:50 If we end up with this or similar time slot (compatible with APAC time zones), do you think it would be possible to set up a video conference for me and/or Alex to join remotely? I can help figuring out any necessary infrastructure. Best regards, Tomasz
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Oct 10 05:00:09 CEST 2018 media-tree git hash:8caec72e8cbff65afa38928197bea5a393b67975 media_build git hash: 9f419c414672676f63e85a61ea99df0ddcd6e9a7 v4l-utils git hash: 06ad469e966aafaf39c1cc76e6e0953ec7d4f9c9 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.11-marune linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19-rc6-i686: OK linux-4.19-rc6-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
Le lundi 08 octobre 2018 à 13:53 +0200, Hans Verkuil a écrit : > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace support > for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to prepare > for that in advance, esp. since I myself do not have any experience writing > userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to work > for most of us (because the topics in the program appear to be boring for us > media types!): > > Tuesday from 10:50-15:50 > > or: > > Monday from 15:45 onward Both works for me. > > My guess is that we need 2-3 hours or so. Hard to predict. > > The basic question that I would like to have answered is what the userspace > component should look like? libv4l-like plugin or a library that userspace can > link with? Do we want more general support for stateful codecs as well that > deals > with resolution changes and the more complex parts of the codec API? > > I've mailed this directly to those that I expect are most interested in this, > but if someone want to join in let me know. > > I want to keep the group small though, so you need to bring relevant > experience > to the table. > > Regards, > > Hans
Re: [PATCH] media: vivid: Improve timestamping
Hi Gabriel,
Thanks for your patch.
On 10/9/18 9:49 PM, Gabriel Francisco Mandaji wrote:
> Simulate a more precise timestamp by calculating it based on the
> current framerate.
>
> Signed-off-by: Gabriel Francisco Mandaji
> ---
> drivers/media/platform/vivid/vivid-core.h| 1 +
> drivers/media/platform/vivid/vivid-kthread-cap.c | 24
>
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/vivid/vivid-core.h
> b/drivers/media/platform/vivid/vivid-core.h
> index cd4c823..cbdadd8 100644
> --- a/drivers/media/platform/vivid/vivid-core.h
> +++ b/drivers/media/platform/vivid/vivid-core.h
> @@ -384,6 +384,7 @@ struct vivid_dev {
> /* thread for generating video capture stream */
> struct task_struct *kthread_vid_cap;
> unsigned long jiffies_vid_cap;
> + u64 cap_stream_start;
> u32 cap_seq_offset;
> u32 cap_seq_count;
> boolcap_seq_resync;
> diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c
> b/drivers/media/platform/vivid/vivid-kthread-cap.c
> index f06003b..0793b15 100644
> --- a/drivers/media/platform/vivid/vivid-kthread-cap.c
> +++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
> @@ -416,6 +416,7 @@ static void vivid_fillbuff(struct vivid_dev *dev, struct
> vivid_buffer *buf)
> char str[100];
> s32 gain;
> bool is_loop = false;
> + u64 soe_time = 0;
>
> if (dev->loop_video && dev->can_loop_video &&
> ((vivid_is_svid_cap(dev) &&
> @@ -426,11 +427,11 @@ static void vivid_fillbuff(struct vivid_dev *dev,
> struct vivid_buffer *buf)
>
> buf->vb.sequence = dev->vid_cap_seq_count;
> /*
> - * Take the timestamp now if the timestamp source is set to
> - * "Start of Exposure".
> + * Store the current time to calculate the delta if source is set to
> + * "End of Frame".
>*/
> - if (dev->tstamp_src_is_soe)
> - buf->vb.vb2_buf.timestamp = ktime_get_ns();
> + if (!dev->tstamp_src_is_soe)
> + soe_time = ktime_get_ns();
> if (dev->field_cap == V4L2_FIELD_ALTERNATE) {
> /*
>* 60 Hz standards start with the bottom field, 50 Hz standards
> @@ -556,12 +557,18 @@ static void vivid_fillbuff(struct vivid_dev *dev,
> struct vivid_buffer *buf)
> }
>
> /*
> - * If "End of Frame" is specified at the timestamp source, then take
> - * the timestamp now.
> + * If "End of Frame", then calculate the "exposition time" and add
> + * it to the timestamp.
>*/
> if (!dev->tstamp_src_is_soe)
> - buf->vb.vb2_buf.timestamp = ktime_get_ns();
> - buf->vb.vb2_buf.timestamp += dev->time_wrap_offset;
> + soe_time = ktime_get_ns() - soe_time;
If I understand correctly, soe_time here is the elapsed time (the delta
between the beginning of the frame and the end of it), so I thing naming
it etime or frame_time or delta_time would be clearer, because soe
stands for "start of exposure" and doesn't seem to be the right meaning.
> + buf->vb.vb2_buf.timestamp = dev->timeperframe_vid_cap.numerator *
> + 10 /
> + dev->timeperframe_vid_cap.denominator *
> + dev->vid_cap_seq_count +
> + dev->cap_stream_start +
> + soe_time +
> + dev->time_wrap_offset;
Could you move the dev->vid_cap_seq_count to the top? I got confused if
it was multiplying only the denominator, I think moving to the top makes
it clearer (or add parenthesis).
> }
>
> /*
> @@ -759,6 +766,7 @@ static int vivid_thread_vid_cap(void *data)
> dev->cap_seq_count = 0;
> dev->cap_seq_resync = false;
> dev->jiffies_vid_cap = jiffies;
> + dev->cap_stream_start = ktime_get_ns();
>
> for (;;) {
> try_to_freeze();
>
Thanks
Helen
[PATCH] media: vivid: Improve timestamping
Simulate a more precise timestamp by calculating it based on the
current framerate.
Signed-off-by: Gabriel Francisco Mandaji
---
drivers/media/platform/vivid/vivid-core.h| 1 +
drivers/media/platform/vivid/vivid-kthread-cap.c | 24
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-core.h
b/drivers/media/platform/vivid/vivid-core.h
index cd4c823..cbdadd8 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -384,6 +384,7 @@ struct vivid_dev {
/* thread for generating video capture stream */
struct task_struct *kthread_vid_cap;
unsigned long jiffies_vid_cap;
+ u64 cap_stream_start;
u32 cap_seq_offset;
u32 cap_seq_count;
boolcap_seq_resync;
diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c
b/drivers/media/platform/vivid/vivid-kthread-cap.c
index f06003b..0793b15 100644
--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -416,6 +416,7 @@ static void vivid_fillbuff(struct vivid_dev *dev, struct
vivid_buffer *buf)
char str[100];
s32 gain;
bool is_loop = false;
+ u64 soe_time = 0;
if (dev->loop_video && dev->can_loop_video &&
((vivid_is_svid_cap(dev) &&
@@ -426,11 +427,11 @@ static void vivid_fillbuff(struct vivid_dev *dev, struct
vivid_buffer *buf)
buf->vb.sequence = dev->vid_cap_seq_count;
/*
-* Take the timestamp now if the timestamp source is set to
-* "Start of Exposure".
+* Store the current time to calculate the delta if source is set to
+* "End of Frame".
*/
- if (dev->tstamp_src_is_soe)
- buf->vb.vb2_buf.timestamp = ktime_get_ns();
+ if (!dev->tstamp_src_is_soe)
+ soe_time = ktime_get_ns();
if (dev->field_cap == V4L2_FIELD_ALTERNATE) {
/*
* 60 Hz standards start with the bottom field, 50 Hz standards
@@ -556,12 +557,18 @@ static void vivid_fillbuff(struct vivid_dev *dev, struct
vivid_buffer *buf)
}
/*
-* If "End of Frame" is specified at the timestamp source, then take
-* the timestamp now.
+* If "End of Frame", then calculate the "exposition time" and add
+* it to the timestamp.
*/
if (!dev->tstamp_src_is_soe)
- buf->vb.vb2_buf.timestamp = ktime_get_ns();
- buf->vb.vb2_buf.timestamp += dev->time_wrap_offset;
+ soe_time = ktime_get_ns() - soe_time;
+ buf->vb.vb2_buf.timestamp = dev->timeperframe_vid_cap.numerator *
+ 10 /
+ dev->timeperframe_vid_cap.denominator *
+ dev->vid_cap_seq_count +
+ dev->cap_stream_start +
+ soe_time +
+ dev->time_wrap_offset;
}
/*
@@ -759,6 +766,7 @@ static int vivid_thread_vid_cap(void *data)
dev->cap_seq_count = 0;
dev->cap_seq_resync = false;
dev->jiffies_vid_cap = jiffies;
+ dev->cap_stream_start = ktime_get_ns();
for (;;) {
try_to_freeze();
--
1.9.1
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
Hi Hans, On Monday, 8 October 2018 14:53:29 EEST Hans Verkuil wrote: > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace > support for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to > prepare for that in advance, esp. since I myself do not have any experience > writing userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to > work for most of us (because the topics in the program appear to be boring > for us media types!): > > Tuesday from 10:50-15:50 > > or: > > Monday from 15:45 onward On Tuesday I would prefer 12:20 onward. Monday works for me. > My guess is that we need 2-3 hours or so. Hard to predict. > > The basic question that I would like to have answered is what the userspace > component should look like? libv4l-like plugin or a library that userspace > can link with? Do we want more general support for stateful codecs as well > that deals with resolution changes and the more complex parts of the codec > API? > > I've mailed this directly to those that I expect are most interested in > this, but if someone want to join in let me know. > > I want to keep the group small though, so you need to bring relevant > experience to the table. -- Regards, Laurent Pinchart
[PATCH] media: intel-ipu3: cio2: Remove redundant definitions
Removed redundant CIO2_IMAGE_MAX_* definitions
Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Signed-off-by: Rajmohan Mani
---
drivers/media/pci/intel/ipu3/ipu3-cio2.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.h
b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
index 240635be7a31..7caab9b8c2b9 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.h
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
@@ -10,8 +10,6 @@
#define CIO2_PCI_ID0x9d32
#define CIO2_PCI_BAR 0
#define CIO2_DMA_MASK DMA_BIT_MASK(39)
-#define CIO2_IMAGE_MAX_WIDTH 4224
-#define CIO2_IMAGE_MAX_LENGTH 3136
#define CIO2_IMAGE_MAX_WIDTH 4224
#define CIO2_IMAGE_MAX_LENGTH 3136
--
2.19.1
Re: [PATCH] media: tc358743: Remove unnecessary self assignment
Hi Nathan,
Thank you for the patch,
On 08/10/18 23:11, Nathan Chancellor wrote:
> Clang warns when a variable is assigned to itself.
>
> drivers/media/i2c/tc358743.c:1921:7: warning: explicitly assigning value
> of variable of type 'int' to itself [-Wself-assign]
> ret = ret;
> ~~~ ^ ~~~
> 1 warning generated.
>
> Signed-off-by: Nathan Chancellor
Certainly somewhat redundant.
Reviewed-by: Kieran Bingham
> ---
> drivers/media/i2c/tc358743.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index ca5d92942820..41d470d9ca94 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -1918,7 +1918,6 @@ static int tc358743_probe_of(struct tc358743_state
> *state)
> ret = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(ep), &endpoint);
> if (ret) {
> dev_err(dev, "failed to parse endpoint\n");
> - ret = ret;
> goto put_node;
> }
>
>
Re: [PATCH 1/7] dt-bindings: mfd: ds90ux9xx: add description of TI DS90Ux9xx ICs
On 10/09/2018 10:55 PM, Vladimir Zapolskiy wrote: > On 10/09/2018 02:11 PM, Vladimir Zapolskiy wrote: >> Hi Marek, >> >> On 10/09/2018 03:13 AM, Marek Vasut wrote: >>> On 10/08/2018 11:11 PM, Vladimir Zapolskiy wrote: From: Sandeep Jain The change adds device tree binding description of TI DS90Ux9xx series of serializer and deserializer controllers which support video, audio and control data transmission over FPD-III Link connection. > > [snip] > +Optional properties: +- reg : Specifies the I2C slave address of a local de-/serializer. +- power-gpios : GPIO line to control supplied power to the device. >>> >>> Shouldn't this be regulator phandle ? >> >> It could be, right. I'll ponder upon it. >> > > No, it can not. > > The property describes PDB "Power-down Mode Input Pin", it is a control > pin with the predefined voltage, so regulator phandle is not applicable > here. Then the DT binding document needs updating, because this is completely unclear and confusing. -- Best regards, Marek Vasut
[PATCH v3 1/4] dt-bindings: media: i2c: Add bindings for Maxim Integrated MAX9286
From: Laurent Pinchart
The MAX9286 deserializes video data received on up to 4 Gigabit
Multimedia Serial Links (GMSL) and outputs them on a CSI-2 port using up
to 4 data lanes.
Signed-off-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
Signed-off-by: Kieran Bingham
---
v3:
- Update binding descriptions
---
.../bindings/media/i2c/maxim,max9286.txt | 182 ++
1 file changed, 182 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt
b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt
new file mode 100644
index ..a73e3c0dc31b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt
@@ -0,0 +1,182 @@
+Maxim Integrated Quad GMSL Deserializer
+---
+
+The MAX9286 deserializer receives video data on up to 4 Gigabit Multimedia
+Serial Links (GMSL) and outputs them on a CSI-2 port using up to 4 data lanes.
+
+In addition to video data, the GMSL links carry a bidirectional control
+channel that encapsulates I2C messages. The MAX9286 forwards all I2C traffic
+not addressed to itself to the other side of the links, where a GMSL
+serializer will output it on a local I2C bus. In the other direction all I2C
+traffic received over GMSL by the MAX9286 is output on the local I2C bus.
+
+Required Properties:
+
+- compatible: Shall be "maxim,max9286"
+- reg: I2C device address
+
+Optional Properties:
+
+- poc-supply: Regulator providing Power over Coax to the cameras
+- pwdn-gpios: GPIO connected to the #PWDN pin
+
+Required endpoint nodes:
+---
+
+The connections to the MAX9286 GMSL and its endpoint nodes are modeled using
+the OF graph bindings in accordance with the video interface bindings defined
+in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+The following table lists the port number corresponding to each device port.
+
+PortDescription
+
+Port 0 GMSL Input 0
+Port 1 GMSL Input 1
+Port 2 GMSL Input 2
+Port 3 GMSL Input 3
+Port 4 CSI-2 Output
+
+Optional Endpoint Properties for GSML Input Ports (Port [0-3]):
+
+- remote-endpoint: phandle to the remote GMSL source endpoint subnode in the
+ remote node port.
+
+Required Endpoint Properties for CSI-2 Output Port (Port 4):
+
+- data-lanes: array of physical CSI-2 data lane indexes.
+- clock-lanes: index of CSI-2 clock lane.
+
+Required i2c-mux nodes:
+--
+
+Each GMSL link is modeled as a child bus of an i2c bus multiplexer/switch, in
+accordance with bindings described in
+Documentation/devicetree/bindings/i2c/i2c-mux.txt. The serializer device on
+the remote end of the GMSL link shall be modelled as a child node of the
+corresponding I2C bus.
+
+Required i2c child bus properties:
+- all properties described as required i2c child bus nodes properties in
+ Documentation/devicetree/bindings/i2c/i2c-mux.txt.
+
+Example:
+---
+
+ gmsl-deserializer@2c {
+ compatible = "maxim,max9286";
+ reg = <0x2c>;
+ poc-supply = <&camera_poc_12v>;
+ pwdn-gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ max9286_in0: endpoint {
+ remote-endpoint = <&rdacm20_out0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ max9286_in1: endpoint {
+ remote-endpoint = <&rdacm20_out1>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ max9286_in2: endpoint {
+ remote-endpoint = <&rdacm20_out2>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ max9286_in3: endpoint {
+ remote-endpoint = <&rdacm20_out3>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+ max9286_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csi40_in>;
+
[PATCH v3 2/4] dt-bindings: media: i2c: Add bindings for IMI RDACM20
From: Jacopo Mondi
The IMI RDACM20 is a Gigabit Multimedia Serial Link (GMSL) camera
capable of transmitting video and I2C control messages on a coax cable
physical link for automotive applications.
Document its device tree binding interface.
Signed-off-by: Jacopo Mondi
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- Provide imi vendor prefix
- Fix minor spelling
v3:
- update binding descriptions
---
.../bindings/media/i2c/imi,rdacm20.txt| 65 +++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imi,rdacm20.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/imi,rdacm20.txt
b/Documentation/devicetree/bindings/media/i2c/imi,rdacm20.txt
new file mode 100644
index ..23915da4c3bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imi,rdacm20.txt
@@ -0,0 +1,65 @@
+IMI D&D RDACM20 Automotive Camera Platform
+--
+
+The IMI D&D RDACM20 is a GMSL-compatible camera designed for automotive
+applications. It encloses a Maxim Integrated MAX9271 GMSL serializer, an
+Omnivision OV10635 camera sensor and an embedded MCU, and connects to a remote
+GMSL endpoint through a coaxial cable.
+
+ IMI RDACM20
+ ---
+| GMSL | <--- Video Stream| <- Video\
|
+| |< == GMSL Link >|MAX9271<- I2C bus-> <-->OV10635
|
+| de-serializer | <--- I2C messages ---> | \<-->MCU
|
+ ---
+
+The RDACM20 transmits video data generated by the embedded camera sensor on the
+GMSL serial channel to a remote GMSL de-serializer, as well as it receives and
+transmits I2C messages encapsulated in the GMSL bidirectional control channel.
+
+All I2C traffic received on the GMSL link not directed to the serializer is
+propagated on the local I2C bus to the embedded camera sensor and MCU. All
+I2C traffic generated on the local I2C bus not directed to the serializer is
+propagated to the remote de-serializer encapsulated in the GMSL control
channel.
+
+The RDACM20 DT node should be a direct child of the GMSL Deserializer's I2C bus
+corresponding to the GMSL link that the camera is attached to.
+
+Required Properties:
+
+- compatible: Shall be "imi,rdacm20".
+- reg: Pair of I2C device addresses, the first to be assigned to the serializer
+ the second to be assigned to the camera sensor.
+
+Connection to the remote GMSL endpoint are modelled using the OF graph bindings
+in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+The device node contains a single "port" child node with a single "endpoint"
+sub-device.
+
+Required endpoint properties:
+
+- remote-endpoint: phandle to the remote GMSL endpoint sub-node in the remote
+ node port.
+
+Example:
+---
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ camera@51 {
+ compatible = "imi,rdacm20";
+ reg = <0x51 0x61>;
+
+ port {
+ rdacm20_out0: endpoint {
+ remote-endpoint = <&max9286_in0>;
+ };
+ };
+
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 2c3fc512e746..34b0ed876850 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -171,6 +171,7 @@ idt Integrated Device Technologies, Inc.
ifiIngenieurburo Fur Ic-Technologie (I/F/I)
ilitek ILI Technology Corporation (ILITEK)
imgImagination Technologies Ltd.
+imiIntegrated Micro-Electronics Inc.
infineon Infineon Technologies
inforceInforce Computing
ingenicIngenic Semiconductor
--
2.17.1
[PATCH v3 3/4] media: i2c: Add MAX9286 driver
From: Kieran Bingham
The MAX9286 is a 4-channel GMSL deserializer with coax or STP input and
CSI-2 output. The device supports multicamera streaming applications,
and features the ability to synchronise the attached cameras.
CSI-2 output can be configured with 1 to 4 lanes, and a control channel
is supported over I2C, which implements an I2C mux to facilitate
communications with connected cameras across the reverse control
channel.
Signed-off-by: Jacopo Mondi
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Signed-off-by: Niklas Söderlund
--
v2:
- Fix MAINTAINERS entry
This posting is released with the following modifications to work
without Sakari's VC developments:
- max9286_g_mbus_config() re-instated
- max9286_get_frame_desc() is not bus/csi aware
- max9286_{get,set}_routing() removed
v3:
- Initialise notifier with v4l2_async_notifier_init
- Update for new mbus csi2 format V4L2_MBUS_CSI2_DPHY
---
MAINTAINERS | 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/max9286.c | 1136 +++
4 files changed, 1158 insertions(+)
create mode 100644 drivers/media/i2c/max9286.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 23021e0df5d7..745f0fd1fff1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8864,6 +8864,16 @@ F:
Documentation/devicetree/bindings/hwmon/max6697.txt
F: drivers/hwmon/max6697.c
F: include/linux/platform_data/max6697.h
+MAX9286 QUAD GMSL DESERIALIZER DRIVER
+M: Jacopo Mondi
+M: Kieran Bingham
+M: Laurent Pinchart
+M: Niklas Söderlund
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/max9286.txt
+F: drivers/media/i2c/max9286.c
+
MAX9860 MONO AUDIO VOICE CODEC DRIVER
M: Peter Rosin
L: alsa-de...@alsa-project.org (moderated for non-subscribers)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 704af210e270..eadc00bdd3bf 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -472,6 +472,17 @@ config VIDEO_VPX3220
To compile this driver as a module, choose M here: the
module will be called vpx3220.
+config VIDEO_MAX9286
+ tristate "Maxim MAX9286 GMSL deserializer support"
+ depends on I2C && I2C_MUX
+ depends on VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+ select V4L2_FWNODE
+ help
+ This driver supports the Maxim MAX9286 GMSL deserializer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called max9286.
+
comment "Video and audio decoders"
config VIDEO_SAA717X
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 260d4d9ec2a1..4de7fe62b179 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -110,5 +110,6 @@ obj-$(CONFIG_VIDEO_IMX258) += imx258.o
obj-$(CONFIG_VIDEO_IMX274) += imx274.o
obj-$(CONFIG_VIDEO_IMX319) += imx319.o
obj-$(CONFIG_VIDEO_IMX355) += imx355.o
+obj-$(CONFIG_VIDEO_MAX9286)+= max9286.o
obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c
new file mode 100644
index ..7ac694cd47f8
--- /dev/null
+++ b/drivers/media/i2c/max9286.c
@@ -0,0 +1,1136 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Maxim MAX9286 GMSL Deserializer Driver
+ *
+ * Copyright (C) 2017-2018 Jacopo Mondi
+ * Copyright (C) 2017-2018 Kieran Bingham
+ * Copyright (C) 2017-2018 Laurent Pinchart
+ * Copyright (C) 2017-2018 Niklas Söderlund
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/* Register 0x00 */
+#define MAX9286_MSTLINKSEL_AUTO(7 << 5)
+#define MAX9286_MSTLINKSEL(n) ((n) << 5)
+#define MAX9286_EN_VS_GEN BIT(4)
+#define MAX9286_LINKEN(n) (1 << (n))
+/* Register 0x01 */
+#define MAX9286_FSYNCMODE_ECU (3 << 6)
+#define MAX9286_FSYNCMODE_EXT (2 << 6)
+#define MAX9286_FSYNCMODE_INT_OUT (1 << 6)
+#define MAX9286_FSYNCMODE_INT_HIZ (0 << 6)
+#define MAX9286_GPIEN BIT(5)
+#define MAX9286_ENLMO_RSTFSYNC BIT(2)
+#define MAX9286_FSYNCMETH_AUTO (2 << 0)
+#define MAX9286_FSYNCMETH_SEMI_AUTO(1 << 0)
+#define MAX9286_FSYNCMETH_MANUAL (0 << 0)
+#define MAX9286_REG_FSYNC_PERIOD_L 0x06
+#define MAX9286_REG_FSYNC_PERIOD_M 0x07
+#define MAX9286_REG_FSYNC_PERIOD_H 0x08
+/* Register 0x0a */
+#define MAX9286_FWDCCEN(n) (1 << ((n) + 4))
+#define MAX9286_REVCCEN(n) (1 << (n))
+/* Register 0x0c */
+#define MAX9286_HVEN BIT(7)
+#define MAX9286_EDC_6BIT_HAMMING (2 << 5)
+#define MAX9286_EDC_6BIT_CRC (1 << 5)
+#define MAX9286_
[PATCH v3 4/4] media: i2c: Add RDACM20 driver
From: Kieran Bingham
The RDACM20 is a GMSL camera supporting 1280x800 resolution images
developed by IMI based on an Omnivision 10635 sensor and a Maxim MAX9271
GMSL serializer.
The GMSL link carries power, control (I2C) and video data over a
single coax cable.
Signed-off-by: Jacopo Mondi
Signed-off-by: Laurent Pinchart
Signed-off-by: Niklas Söderlund
Signed-off-by: Kieran Bingham
---
v2:
- Fix MAINTAINERS entry
v3:
- Use new V4L2_MBUS_CSI2_DPHY bus type
- Remove 'always zero' error print
- Fix module description
---
MAINTAINERS | 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/rdacm20-ov10635.h | 953
drivers/media/i2c/rdacm20.c | 635 ++
5 files changed, 1610 insertions(+)
create mode 100644 drivers/media/i2c/rdacm20-ov10635.h
create mode 100644 drivers/media/i2c/rdacm20.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 745f0fd1fff1..26ef20087a43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12230,6 +12230,16 @@ S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: tools/testing/selftests/rcutorture
+RDACM20 Camera Sensor
+M: Jacopo Mondi
+M: Kieran Bingham
+M: Laurent Pinchart
+M: Niklas Söderlund
+L: linux-media@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/rdacm20.txt
+F: drivers/media/i2c/rdacm20*
+
RDC R-321X SoC
M: Florian Fainelli
S: Maintained
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index eadc00bdd3bf..5eded5e337ec 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -989,6 +989,17 @@ config VIDEO_S5C73M3
This is a V4L2 sensor driver for Samsung S5C73M3
8 Mpixel camera.
+config VIDEO_RDACM20
+ tristate "IMI RDACM20 camera support"
+ depends on I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+ select V4L2_FWNODE
+ help
+ This driver supports the IMI RDACM20 GMSL camera, used in
+ ADAS systems.
+
+ This camera should be used in conjunction with a GMSL
+ deserialiser such as the MAX9286.
+
comment "Flash devices"
config VIDEO_ADP1653
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 4de7fe62b179..121d28283d45 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -111,5 +111,6 @@ obj-$(CONFIG_VIDEO_IMX274) += imx274.o
obj-$(CONFIG_VIDEO_IMX319) += imx319.o
obj-$(CONFIG_VIDEO_IMX355) += imx355.o
obj-$(CONFIG_VIDEO_MAX9286)+= max9286.o
+obj-$(CONFIG_VIDEO_RDACM20)+= rdacm20.o
obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/rdacm20-ov10635.h
b/drivers/media/i2c/rdacm20-ov10635.h
new file mode 100644
index ..3c53a3262ee2
--- /dev/null
+++ b/drivers/media/i2c/rdacm20-ov10635.h
@@ -0,0 +1,953 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * IMI RDACM20 camera OV10635 sensor register initialization values
+ *
+ * Copyright (C) 2017-2018 Jacopo Mondi
+ * Copyright (C) 2017-2018 Kieran Bingham
+ * Copyright (C) 2017-2018 Laurent Pinchart
+ * Copyright (C) 2017-2018 Niklas Söderlund
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ */
+
+/*
+ * Generated by the OmniVision ov10635 sensor camera wizard for
+ * 1280x800@30/UYVY/BT601/8bit.
+ */
+
+#ifndef __RDACM20_OV10635_H__
+#define __RDACM20_OV10635_H__
+
+#define OV10635_SENSOR_WIDTH 1312
+#define OV10635_SENSOR_HEIGHT 814
+
+#define OV10635_MAX_WIDTH 1280
+#define OV10635_MAX_HEIGHT 800
+
+/* VTS = PCLK / FPS / HTS / 2 (= 88MHz / 1572 / 30 / 2) */
+#define OV10635_HTS1572
+/* FPS = 29,9998 */
+#define OV10635_VTS933
+
+struct ov10635_reg {
+ u16 reg;
+ u8 val;
+};
+
+static const struct ov10635_reg ov10635_regs_wizard[] = {
+ { 0x301b, 0xff },
+ { 0x301c, 0xff },
+ { 0x301a, 0xff },
+ { 0x3011, 0x42 },
+ { 0x6900, 0x0c },
+ { 0x6901, 0x19 },
+ { 0x3503, 0x10 },
+ { 0x3025, 0x03 },
+ { 0x3003, 0x16 },
+ { 0x3004, 0x30 },
+ { 0x3005, 0x40 },
+ { 0x3006, 0x91 },
+ { 0x3600, 0x74 },
+ { 0x3601, 0x2b },
+ { 0x3612, 0x00 },
+ { 0x3611, 0x67 },
+ { 0x3633, 0xca },
+ { 0x3602, 0xaf },
+ { 0x3603, 0x04 },
+ { 0x3630, 0x28 },
+ { 0x3631, 0x16 },
+ { 0x3714, 0x10 },
+ { 0x371d, 0x01 },
+ { 0x4300, 0x3a },
+ { 0x3007, 0x01 },
+ { 0x3024, 0x03 },
+ { 0x3020, 0x0a },
+ { 0x3702, 0x0d },
+ { 0x3703, 0x20 },
+ { 0x3704, 0x15 },
+ { 0x3709, 0xa8 },
+ { 0x370c, 0xc7 },
+ { 0x370d, 0x80 },
+ { 0x3712, 0x00 },
+ { 0x3713, 0x20 },
+ { 0x3715, 0x04 },
+ { 0x381d, 0x40 },
+ {
[PATCH v3 0/4] MAX9286 GMSL Support
This series provides a pair of drivers for GMSL cameras on the R-Car ADAS platforms. These drivers originate from Cogent Embedded, and have been refactored to split the MAX9286 away from the RDACM20 drivers which were once very tightly coupled. This posting is the culmination of ~100 changesets spread across Jacopo, Niklas, Laurent and myself - thus they contain all of our SoB tags. Although this device is capable of handling up to 4 streams, this is not possible until the VC work comes through from Sakari and as such - this driver is only functional on a *single* stream. This driver along with the associated platform support for the Renesas R-Car Salvator-X, and the Eagle-V3M can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git gmsl/v3 --- v2: - Add Jacopo's dt-binding patches - Fix MAINTAINERS entries - Add imi vendor prefix to Jacopo's patches - Remove VC support v3: MAX9286: - Initialise notifier with v4l2_async_notifier_init - Update for new mbus csi2 format V4L2_MBUS_CSI2_DPHY RDACM20: - Use new V4L2_MBUS_CSI2_DPHY bus type - Remove 'always zero' error print - Fix module description Bindings: - Fixes from Laurent's review comments on V2 Jacopo Mondi (1): dt-bindings: media: i2c: Add bindings for IMI RDACM20 Kieran Bingham (2): media: i2c: Add MAX9286 driver media: i2c: Add RDACM20 driver Laurent Pinchart (1): dt-bindings: media: i2c: Add bindings for Maxim Integrated MAX9286 .../bindings/media/i2c/imi,rdacm20.txt| 65 + .../bindings/media/i2c/maxim,max9286.txt | 182 +++ .../devicetree/bindings/vendor-prefixes.txt |1 + MAINTAINERS | 20 + drivers/media/i2c/Kconfig | 22 + drivers/media/i2c/Makefile|2 + drivers/media/i2c/max9286.c | 1136 + drivers/media/i2c/rdacm20-ov10635.h | 953 ++ drivers/media/i2c/rdacm20.c | 635 + 9 files changed, 3016 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/imi,rdacm20.txt create mode 100644 Documentation/devicetree/bindings/media/i2c/maxim,max9286.txt create mode 100644 drivers/media/i2c/max9286.c create mode 100644 drivers/media/i2c/rdacm20-ov10635.h create mode 100644 drivers/media/i2c/rdacm20.c -- 2.17.1
Re: [PATCH 1/7] dt-bindings: mfd: ds90ux9xx: add description of TI DS90Ux9xx ICs
On 10/09/2018 02:11 PM, Vladimir Zapolskiy wrote: > Hi Marek, > > On 10/09/2018 03:13 AM, Marek Vasut wrote: >> On 10/08/2018 11:11 PM, Vladimir Zapolskiy wrote: >>> From: Sandeep Jain >>> >>> The change adds device tree binding description of TI DS90Ux9xx >>> series of serializer and deserializer controllers which support video, >>> audio and control data transmission over FPD-III Link connection. >>> [snip] >>> +Optional properties: >>> +- reg : Specifies the I2C slave address of a local de-/serializer. >>> +- power-gpios : GPIO line to control supplied power to the device. >> >> Shouldn't this be regulator phandle ? > > It could be, right. I'll ponder upon it. > No, it can not. The property describes PDB "Power-down Mode Input Pin", it is a control pin with the predefined voltage, so regulator phandle is not applicable here. -- Best wishes, Vladimir
You must not Ignore
Foremost, we introduce this commission, The INTERPOL. We fight global crime including internet fraud and money laundering. Our commission has rounded-up well over 27,000 fraudsters and we are still battling these nefarious individuals. We are aware that quite a lot of people have been conned into parting with huge amounts. The United Nation has vowed to combat these crimes. As such due to their efforts and contributions, we have been able to recovered over USD$1.3 Million Dollars (One Million Three Hundred Thousand United States Dollars) till date. Amongst the details yours was found to include your email. Our aim is to return all lost assets including funds to legitimate individuals identified. After a mandated investigation of the apprehended persons, the United Nations has approved the total sum of USD$1,000,000 (One Million United States Dollars only), as compensation to the funds you lost. This amount will be paid to you in the oncoming days with your co-operation as we commence to conclude the investigation on your case. There will be a series of questions we will ask to aid us in rounding-up your case file. Please respond with your full names and address, country of origin, company's name and position (if any), current occupation, daytime mobile (phone) number for easy communication for ratification and to redeem your fund. We await your swift response to this notification. Regards Deputy Director W. Salzgaber Investigations Department
Re: [PATCH] media: venus: queue initial buffers
Hi Malathi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Malathi-Gottam/media-venus-queue-initial-buffers/20181009-221017
base: git://linuxtv.org/media_tree.git master
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=m68k
All error/warnings (new ones prefixed by >>):
drivers/media//platform/qcom/venus/venc.c: In function
'venc_start_streaming':
>> drivers/media//platform/qcom/venus/venc.c:994:3: error: label 'deinit_sess'
>> used but not defined
goto deinit_sess;
^~~~
>> drivers/media//platform/qcom/venus/venc.c:973:3: error: label 'bufs_done'
>> used but not defined
goto bufs_done;
^~~~
drivers/media//platform/qcom/venus/venc.c: At top level:
>> drivers/media//platform/qcom/venus/venc.c:997:15: error: expected
>> declaration specifiers or '...' before '&' token
mutex_unlock(&inst->lock);
^
>> drivers/media//platform/qcom/venus/venc.c:999:2: error: expected identifier
>> or '(' before 'return'
return 0;
^~
>> drivers/media//platform/qcom/venus/venc.c:1001:12: error: expected '=', ',',
>> ';', 'asm' or '__attribute__' before ':' token
deinit_sess:
^
drivers/media//platform/qcom/venus/venc.c:1003:10: error: expected '=', ',',
';', 'asm' or '__attribute__' before ':' token
bufs_done:
^
>> drivers/media//platform/qcom/venus/venc.c:1005:2: error: expected identifier
>> or '(' before 'if'
if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
^~
>> drivers/media//platform/qcom/venus/venc.c:1007:2: error: expected identifier
>> or '(' before 'else'
else
^~~~
drivers/media//platform/qcom/venus/venc.c:1009:15: error: expected
declaration specifiers or '...' before '&' token
mutex_unlock(&inst->lock);
^
drivers/media//platform/qcom/venus/venc.c:1010:2: error: expected identifier
or '(' before 'return'
return ret;
^~
>> drivers/media//platform/qcom/venus/venc.c:1011:1: error: expected identifier
>> or '(' before '}' token
}
^
drivers/media//platform/qcom/venus/venc.c: In function
'venc_start_streaming':
>> drivers/media//platform/qcom/venus/venc.c:995:2: warning: control reaches
>> end of non-void function [-Wreturn-type]
}
^
vim +/deinit_sess +994 drivers/media//platform/qcom/venus/venc.c
948
949 static int venc_start_streaming(struct vb2_queue *q, unsigned int count)
950 {
951 struct venus_inst *inst = vb2_get_drv_priv(q);
952 int ret;
953
954 mutex_lock(&inst->lock);
955
956 if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
957 inst->streamon_out = 1;
958 else
959 inst->streamon_cap = 1;
960
961 if (!(inst->streamon_out & inst->streamon_cap)) {
962 mutex_unlock(&inst->lock);
963 return 0;
964 }
965
966 venus_helper_init_instance(inst);
967
968 inst->sequence_cap = 0;
969 inst->sequence_out = 0;
970
971 ret = venc_init_session(inst);
972 if (ret)
> 973 goto bufs_done;
974
975 ret = venc_set_properties(inst);
976 if (ret)
977 goto deinit_sess;
978
979 ret = venc_verify_conf(inst);
980 if (ret)
981 goto deinit_sess;
982
983 ret = venus_helper_set_num_bufs(inst, inst->num_input_bufs,
984 inst->num_output_bufs, 0);
985 if (ret)
986 goto deinit_sess;
987
988 ret = venus_helper_vb2_start_streaming(inst);
989 if (ret)
990 goto deinit_sess;
991
992 ret = venus_helper_queue_initial_bufs(inst);
993 if (ret)
> 994 goto deinit_
Re: [RFC PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
Hi, Le mardi 09 octobre 2018 à 16:30 +0900, Tomasz Figa a écrit : > On Thu, Oct 4, 2018 at 9:46 PM Paul Kocialkowski wrote: > > > > Hi, > > > > Here are a few minor suggestion about H.264 controls. > > > > Le jeudi 04 octobre 2018 à 17:11 +0900, Alexandre Courbot a écrit : > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > > b/Documentation/media/uapi/v4l/extended-controls.rst > > > index a9252225b63e..9d06d853d4ff 100644 > > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > > @@ -810,6 +810,31 @@ enum v4l2_mpeg_video_bitrate_mode - > > > otherwise the decoder expects a single frame in per buffer. > > > Applicable to the decoder, all codecs. > > > > > > +.. _v4l2-mpeg-h264: > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_SPS`` > > > +Instance of struct v4l2_ctrl_h264_sps, containing the SPS of to use > > > with > > > +the next queued frame. Applicable to the H.264 stateless decoder. > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_PPS`` > > > +Instance of struct v4l2_ctrl_h264_pps, containing the PPS of to use > > > with > > > +the next queued frame. Applicable to the H.264 stateless decoder. > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX`` > > > > For consistency with MPEG-2 and upcoming JPEG, I think we should call > > this "H264_QUANTIZATION". > > I'd rather stay consistent with H.264 specification, which uses the > wording as defined in Alex's patch. Otherwise it would be difficult to > correlate between the controls and the specification, which is > something that the userspace developer would definitely need to > understand how to properly parse the stream and obtain the decoding > parameters. Okay, I agree this makes more sense than trying to keep the names consistent across codecs. > > > > > +Instance of struct v4l2_ctrl_h264_scaling_matrix, containing the > > > scaling > > > +matrix to use when decoding the next queued frame. Applicable to the > > > H.264 > > > +stateless decoder. > > > + > > > +``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM`` > > > > Ditto with "H264_SLICE_PARAMS". > > > > It doesn't seem to be related to the spec in this case and "params" > sounds better indeed. Cheers, Paul signature.asc Description: This is a digitally signed message part
Re: [PATCH] media: venus: add support for key frame
Hi Malathi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Malathi-Gottam/media-venus-add-support-for-key-frame/20181009-214918
base: git://linuxtv.org/media_tree.git master
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/media//platform/qcom/venus/venc_ctrls.c: In function
'venc_op_s_ctrl':
>> drivers/media//platform/qcom/venus/venc_ctrls.c:180:7: warning: 'ptr' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
ret = hfi_session_set_property(inst, ptype, ptr);
^~~~
vim +/ptr +180 drivers/media//platform/qcom/venus/venc_ctrls.c
77
78 static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
79 {
80 struct venus_inst *inst = ctrl_to_inst(ctrl);
81 struct venc_controls *ctr = &inst->controls.enc;
82 u32 bframes;
83 int ret;
84 void *ptr;
85 u32 ptype;
86
87 switch (ctrl->id) {
88 case V4L2_CID_MPEG_VIDEO_BITRATE_MODE:
89 ctr->bitrate_mode = ctrl->val;
90 break;
91 case V4L2_CID_MPEG_VIDEO_BITRATE:
92 ctr->bitrate = ctrl->val;
93 break;
94 case V4L2_CID_MPEG_VIDEO_BITRATE_PEAK:
95 ctr->bitrate_peak = ctrl->val;
96 break;
97 case V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE:
98 ctr->h264_entropy_mode = ctrl->val;
99 break;
100 case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
101 ctr->profile.mpeg4 = ctrl->val;
102 break;
103 case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
104 ctr->profile.h264 = ctrl->val;
105 break;
106 case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
107 ctr->profile.vpx = ctrl->val;
108 break;
109 case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
110 ctr->level.mpeg4 = ctrl->val;
111 break;
112 case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
113 ctr->level.h264 = ctrl->val;
114 break;
115 case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP:
116 ctr->h264_i_qp = ctrl->val;
117 break;
118 case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP:
119 ctr->h264_p_qp = ctrl->val;
120 break;
121 case V4L2_CID_MPEG_VIDEO_H264_B_FRAME_QP:
122 ctr->h264_b_qp = ctrl->val;
123 break;
124 case V4L2_CID_MPEG_VIDEO_H264_MIN_QP:
125 ctr->h264_min_qp = ctrl->val;
126 break;
127 case V4L2_CID_MPEG_VIDEO_H264_MAX_QP:
128 ctr->h264_max_qp = ctrl->val;
129 break;
130 case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE:
131 ctr->multi_slice_mode = ctrl->val;
132 break;
133 case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BYTES:
134 ctr->multi_slice_max_bytes = ctrl->val;
135 break;
136 case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_MB:
137 ctr->multi_slice_max_mb = ctrl->val;
138 break;
139 case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_ALPHA:
140 ctr->h264_loop_filter_alpha = ctrl->val;
141 break;
142 case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_BETA:
143 ctr->h264_loop_filter_beta = ctrl->val;
144 break;
145 case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE:
146 ctr->h264_loop_filter_mode = ctrl->val;
147 break;
148 case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
149 ctr->header_mode = ctrl->val;
150 break;
151 case V4L2_CID_MPEG_VI
[PATCHv3] media: rc: add driver for Xbox DVD Movie Playback Kit
The Xbox DVD Movie Playback Kit is a USB dongle with an IR remote for the
Original Xbox.
Historically it has been supported by the out-of-tree lirc_xbox driver,
but this one has fallen out of favour and was just dropped from popular
Kodi (formerly XBMC) distributions.
This driver is heaviely based on the ati_remote driver where all the
boilerplate was taken from - I was mostly just removing code.
Signed-off-by: Benjamin Valentin
---
Changes from v2:
I've addressed the review comments by Sean Young
- dropped the use of DMA
- dropped custom error/debug print macros
- fixed KConfig entry and added depends on USB_ARCH_HAS_HCD
- fixed checkpatch.pl issues
MAINTAINERS| 6 +
drivers/media/rc/Kconfig | 12 +
drivers/media/rc/Makefile | 1 +
drivers/media/rc/keymaps/Makefile | 1 +
drivers/media/rc/keymaps/rc-xbox-dvd.c | 63 +
drivers/media/rc/xbox_remote.c | 305 +
include/media/rc-map.h | 1 +
7 files changed, 389 insertions(+)
create mode 100644 drivers/media/rc/keymaps/rc-xbox-dvd.c
create mode 100644 drivers/media/rc/xbox_remote.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 22065048d89d..712a51a1a955 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15973,6 +15973,12 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso
S: Maintained
F: arch/x86/entry/vdso/
+XBOX DVD IR REMOTE
+M: Benjamin Valentin
+S: Maintained
+F: drivers/media/rc/xbox_remote.c
+F: drivers/media/rc/keymaps/rc-xbox-dvd.c
+
XC2028/3028 TUNER DRIVER
M: Mauro Carvalho Chehab
L: linux-media@vger.kernel.org
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 1021c08a9ba4..8a216068a35a 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -493,6 +493,18 @@ config IR_TANGO
The HW decoder supports NEC, RC-5, RC-6 IR protocols.
When compiled as a module, look for tango-ir.
+config RC_XBOX_DVD
+ tristate "Xbox DVD Movie Playback Kit"
+ depends on RC_CORE
+ depends on USB_ARCH_HAS_HCD
+ select USB
+ help
+ Say Y here if you want to use the Xbox DVD Movie Playback Kit.
+ These are IR remotes with USB receivers for the Original Xbox (2001).
+
+ To compile this driver as a module, choose M here: the module will be
+ called xbox_remote.
+
config IR_ZX
tristate "ZTE ZX IR remote control"
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index e0340d043fe8..92c163816849 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -48,3 +48,4 @@ obj-$(CONFIG_IR_SIR) += sir_ir.o
obj-$(CONFIG_IR_MTK) += mtk-cir.o
obj-$(CONFIG_IR_ZX) += zx-irdec.o
obj-$(CONFIG_IR_TANGO) += tango-ir.o
+obj-$(CONFIG_RC_XBOX_DVD) += xbox_remote.o
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index d6b913a3032d..5b1399af6b3a 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -116,4 +116,5 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-winfast.o \
rc-winfast-usbii-deluxe.o \
rc-su3000.o \
+ rc-xbox-dvd.o \
rc-zx-irdec.o
diff --git a/drivers/media/rc/keymaps/rc-xbox-dvd.c
b/drivers/media/rc/keymaps/rc-xbox-dvd.c
new file mode 100644
index ..61da6706715c
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-xbox-dvd.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Keytable for Xbox DVD remote
+// Copyright (c) 2018 by Benjamin Valentin
+
+#include
+#include
+
+/* based on lircd.conf.xbox */
+static struct rc_map_table xbox_dvd[] = {
+ {0x0b, KEY_OK},
+ {0xa6, KEY_UP},
+ {0xa7, KEY_DOWN},
+ {0xa8, KEY_RIGHT},
+ {0xa9, KEY_LEFT},
+ {0xc3, KEY_INFO},
+
+ {0xc6, KEY_9},
+ {0xc7, KEY_8},
+ {0xc8, KEY_7},
+ {0xc9, KEY_6},
+ {0xca, KEY_5},
+ {0xcb, KEY_4},
+ {0xcc, KEY_3},
+ {0xcd, KEY_2},
+ {0xce, KEY_1},
+ {0xcf, KEY_0},
+
+ {0xd5, KEY_ANGLE},
+ {0xd8, KEY_BACK},
+ {0xdd, KEY_PREVIOUSSONG},
+ {0xdf, KEY_NEXTSONG},
+ {0xe0, KEY_STOP},
+ {0xe2, KEY_REWIND},
+ {0xe3, KEY_FASTFORWARD},
+ {0xe5, KEY_TITLE},
+ {0xe6, KEY_PAUSE},
+ {0xea, KEY_PLAY},
+ {0xf7, KEY_MENU},
+};
+
+static struct rc_map_list xbox_dvd_map = {
+ .map = {
+ .scan = xbox_dvd,
+ .size = ARRAY_SIZE(xbox_dvd),
+ .rc_proto = RC_PROTO_UNKNOWN,
+ .name = RC_MAP_XBOX_DVD,
+ }
+};
+
+static int __init init_rc_map(void)
+{
+ return rc_map_register(&xbox_dvd_map);
+}
+
+static void __exit exit_rc_map(void)
+{
+ rc_map_unregister(&xbox_dvd_map);
+}
+
+module_init(init_rc_ma
Re: [PATCH] media: venus: queue initial buffers
Hi Malathi,
On 10/09/2018 10:50 AM, Malathi Gottam wrote:
> Buffers can be queued to driver before the planes are
> set to start streaming. Queue those buffers to firmware
> once start streaming is called on both the planes.
yes and this is done in venus_helper_m2m_device_run mem2mem operation
when streamon on both queues is called, thus below function just
duplicates .device_run.
Do you fix an issue with that patch?
>
> Signed-off-by: Malathi Gottam
> ---
> drivers/media/platform/qcom/venus/helpers.c | 22 ++
> drivers/media/platform/qcom/venus/helpers.h | 1 +
> drivers/media/platform/qcom/venus/venc.c| 5 +
> 3 files changed, 28 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> b/drivers/media/platform/qcom/venus/helpers.c
> index e436385..2679adb 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -1041,6 +1041,28 @@ void venus_helper_vb2_stop_streaming(struct vb2_queue
> *q)
> }
> EXPORT_SYMBOL_GPL(venus_helper_vb2_stop_streaming);
>
> +int venus_helper_queue_initial_bufs(struct venus_inst *inst)
> +{
> + struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
> + struct v4l2_m2m_buffer *buf, *n;
> + int ret;
> +
> + v4l2_m2m_for_each_dst_buf_safe(m2m_ctx, buf, n) {
> + ret = session_process_buf(inst, &buf->vb);
> + if (ret)
> + return_buf_error(inst, &buf->vb);
> + }
> +
> + v4l2_m2m_for_each_src_buf_safe(m2m_ctx, buf, n) {
> + ret = session_process_buf(inst, &buf->vb);
> + if (ret)
> + return_buf_error(inst, &buf->vb);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(venus_helper_queue_initial_bufs);
> +
> int venus_helper_vb2_start_streaming(struct venus_inst *inst)
> {
> struct venus_core *core = inst->core;
> diff --git a/drivers/media/platform/qcom/venus/helpers.h
> b/drivers/media/platform/qcom/venus/helpers.h
> index 2475f284..f4d76ab 100644
> --- a/drivers/media/platform/qcom/venus/helpers.h
> +++ b/drivers/media/platform/qcom/venus/helpers.h
> @@ -31,6 +31,7 @@ void venus_helper_buffers_done(struct venus_inst *inst,
> int venus_helper_vb2_start_streaming(struct venus_inst *inst);
> void venus_helper_m2m_device_run(void *priv);
> void venus_helper_m2m_job_abort(void *priv);
> +int venus_helper_queue_initial_bufs(struct venus_inst *inst);
> int venus_helper_get_bufreq(struct venus_inst *inst, u32 type,
> struct hfi_buffer_requirements *req);
> u32 venus_helper_get_framesz_raw(u32 hfi_fmt, u32 width, u32 height);
> diff --git a/drivers/media/platform/qcom/venus/venc.c
> b/drivers/media/platform/qcom/venus/venc.c
> index ce85962..ef11495 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -989,6 +989,11 @@ static int venc_start_streaming(struct vb2_queue *q,
> unsigned int count)
> if (ret)
> goto deinit_sess;
>
> + ret = venus_helper_queue_initial_bufs(inst);
> + if (ret)
> + goto deinit_sess;
> + }
> +
> mutex_unlock(&inst->lock);
>
> return 0;
>
--
regards,
Stan
Re: [PATCH] media: venus: handle peak bitrate set property
Hi Malathi,
Thanks for the patch!
On 10/09/2018 10:51 AM, Malathi Gottam wrote:
> Max bitrate property is not supported for venus version 4xx.
> Add a version check for the same.
I'd like to avoid version checks in this layer of the driver. Could just
black-list this property in pkt_session_set_property_4xx? Hint, see
HFI_PROPERTY_CONFIG_VENC_MAX_BITRATE in the same function.
>
> Signed-off-by: Malathi Gottam
> ---
> drivers/media/platform/qcom/venus/venc.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/venc.c
> b/drivers/media/platform/qcom/venus/venc.c
> index ef11495..3f50cd0 100644
> --- a/drivers/media/platform/qcom/venus/venc.c
> +++ b/drivers/media/platform/qcom/venus/venc.c
> @@ -757,18 +757,20 @@ static int venc_set_properties(struct venus_inst *inst)
> if (ret)
> return ret;
>
> - if (!ctr->bitrate_peak)
> - bitrate *= 2;
> - else
> - bitrate = ctr->bitrate_peak;
> + if (!IS_V4(inst->core)) {
> + if (!ctr->bitrate_peak)
> + bitrate *= 2;
> + else
> + bitrate = ctr->bitrate_peak;
>
> - ptype = HFI_PROPERTY_CONFIG_VENC_MAX_BITRATE;
> - brate.bitrate = bitrate;
> - brate.layer_id = 0;
> + ptype = HFI_PROPERTY_CONFIG_VENC_MAX_BITRATE;
> + brate.bitrate = bitrate;
> + brate.layer_id = 0;
>
> - ret = hfi_session_set_property(inst, ptype, &brate);
> - if (ret)
> - return ret;
> + ret = hfi_session_set_property(inst, ptype, &brate);
> + if (ret)
> + return ret;
> + }
>
> if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264) {
> profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_PROFILE,
>
--
regards,
Stan
Re: [PATCH v2] media: vivid: Support 480p for webcam capture
Hi Keiichi,
Thank you for the patch update,
On 09/10/18 14:43, Keiichi Watanabe wrote:
> Support 640x480 as a frame size for video input devices of vivid.
>
> Signed-off-by: Keiichi Watanabe
My concerns have been addressed,
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/vivid/vivid-vid-cap.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
> b/drivers/media/platform/vivid/vivid-vid-cap.c
> index 58e14dd1dcd3..6cf910a60ecf 100644
> --- a/drivers/media/platform/vivid/vivid-vid-cap.c
> +++ b/drivers/media/platform/vivid/vivid-vid-cap.c
> @@ -51,7 +51,7 @@ static const struct vivid_fmt formats_ovl[] = {
> };
>
> /* The number of discrete webcam framesizes */
> -#define VIVID_WEBCAM_SIZES 5
> +#define VIVID_WEBCAM_SIZES 6
> /* The number of discrete webcam frameintervals */
> #define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
>
> @@ -59,6 +59,7 @@ static const struct vivid_fmt formats_ovl[] = {
> static const struct v4l2_frmsize_discrete webcam_sizes[VIVID_WEBCAM_SIZES] =
> {
> { 320, 180 },
> { 640, 360 },
> + { 640, 480 },
> { 1280, 720 },
> { 1920, 1080 },
> { 3840, 2160 },
> @@ -74,9 +75,11 @@ static const struct v4l2_fract
> webcam_intervals[VIVID_WEBCAM_IVALS] = {
> { 1, 4 },
> { 1, 5 },
> { 1, 10 },
> + { 2, 25 },
> { 1, 15 },
> { 1, 25 },
> { 1, 30 },
> + { 1, 40 },
> { 1, 50 },
> { 1, 60 },
> };
>
--
Regards
--
Kieran
Re: [PATCH 1/1] omap3isp: Unregister media device as first
Hi Sakari,
Thank you for the patch.
On Tuesday, 9 October 2018 15:03:16 EEST Sakari Ailus wrote:
> While there are issues related to object lifetime management, unregister the
> media device first when the driver is being unbound. This is slightly
> safer.
>
> Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 93f032a39470..4194ea82e6c4
> 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -1587,6 +1587,8 @@ static void isp_pm_complete(struct device *dev)
>
> static void isp_unregister_entities(struct isp_device *isp)
> {
> + media_device_unregister(&isp->media_dev);
> +
> omap3isp_csi2_unregister_entities(&isp->isp_csi2a);
> omap3isp_ccp2_unregister_entities(&isp->isp_ccp2);
> omap3isp_ccdc_unregister_entities(&isp->isp_ccdc);
> @@ -1597,7 +1599,6 @@ static void isp_unregister_entities(struct isp_device
> *isp) omap3isp_stat_unregister_entities(&isp->isp_hist);
>
> v4l2_device_unregister(&isp->v4l2_dev);
> - media_device_unregister(&isp->media_dev);
> media_device_cleanup(&isp->media_dev);
> }
--
Regards,
Laurent Pinchart
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
On Tue, 09 Oct 2018 at 07:29, Mauro Carvalho Chehab wrote: > Em Mon, 8 Oct 2018 13:53:29 +0200 > Hans Verkuil escreveu: > > > Hi all, > > > > I would like to meet up somewhere during the ELCE to discuss userspace > > support > > for stateless (and perhaps stateful as well?) codecs. > > > > It is also planned as a topic during the summit, but I would prefer to > > prepare > > for that in advance, esp. since I myself do not have any experience writing > > userspace SW for such devices. > > > > Nicolas, it would be really great if you can participate in this meeting > > since you probably have the most experience with this by far. > > > > Looking through the ELCE program I found two timeslots that are likely to > > work > > for most of us (because the topics in the program appear to be boring for us > > media types!): > > > > Tuesday from 10:50-15:50 > I would like to participate in the meeting too. And Tuesday fits to me, since I'll arrive to Edinburgh on Monday night. vmjl
Re: [PATCH v2] media: vivid: Support 480p for webcam capture
On 10/09/18 15:43, Keiichi Watanabe wrote:
> Support 640x480 as a frame size for video input devices of vivid.
>
> Signed-off-by: Keiichi Watanabe
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/vivid/vivid-vid-cap.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
> b/drivers/media/platform/vivid/vivid-vid-cap.c
> index 58e14dd1dcd3..6cf910a60ecf 100644
> --- a/drivers/media/platform/vivid/vivid-vid-cap.c
> +++ b/drivers/media/platform/vivid/vivid-vid-cap.c
> @@ -51,7 +51,7 @@ static const struct vivid_fmt formats_ovl[] = {
> };
>
> /* The number of discrete webcam framesizes */
> -#define VIVID_WEBCAM_SIZES 5
> +#define VIVID_WEBCAM_SIZES 6
> /* The number of discrete webcam frameintervals */
> #define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
>
> @@ -59,6 +59,7 @@ static const struct vivid_fmt formats_ovl[] = {
> static const struct v4l2_frmsize_discrete webcam_sizes[VIVID_WEBCAM_SIZES] =
> {
> { 320, 180 },
> { 640, 360 },
> + { 640, 480 },
> { 1280, 720 },
> { 1920, 1080 },
> { 3840, 2160 },
> @@ -74,9 +75,11 @@ static const struct v4l2_fract
> webcam_intervals[VIVID_WEBCAM_IVALS] = {
> { 1, 4 },
> { 1, 5 },
> { 1, 10 },
> + { 2, 25 },
> { 1, 15 },
> { 1, 25 },
> { 1, 30 },
> + { 1, 40 },
> { 1, 50 },
> { 1, 60 },
> };
>
[PATCH v2] media: vivid: Support 480p for webcam capture
Support 640x480 as a frame size for video input devices of vivid.
Signed-off-by: Keiichi Watanabe
---
drivers/media/platform/vivid/vivid-vid-cap.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 58e14dd1dcd3..6cf910a60ecf 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -51,7 +51,7 @@ static const struct vivid_fmt formats_ovl[] = {
};
/* The number of discrete webcam framesizes */
-#define VIVID_WEBCAM_SIZES 5
+#define VIVID_WEBCAM_SIZES 6
/* The number of discrete webcam frameintervals */
#define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
@@ -59,6 +59,7 @@ static const struct vivid_fmt formats_ovl[] = {
static const struct v4l2_frmsize_discrete webcam_sizes[VIVID_WEBCAM_SIZES] = {
{ 320, 180 },
{ 640, 360 },
+ { 640, 480 },
{ 1280, 720 },
{ 1920, 1080 },
{ 3840, 2160 },
@@ -74,9 +75,11 @@ static const struct v4l2_fract
webcam_intervals[VIVID_WEBCAM_IVALS] = {
{ 1, 4 },
{ 1, 5 },
{ 1, 10 },
+ { 2, 25 },
{ 1, 15 },
{ 1, 25 },
{ 1, 30 },
+ { 1, 40 },
{ 1, 50 },
{ 1, 60 },
};
--
2.19.0.605.g01d371f741-goog
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
On Mon, 2018-10-08 at 13:53 +0200, Hans Verkuil wrote: > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace support > for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to prepare > for that in advance, esp. since I myself do not have any experience writing > userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to work > for most of us (because the topics in the program appear to be boring for us > media types!): > > Tuesday from 10:50-15:50 > > or: > > Monday from 15:45 onward > > My guess is that we need 2-3 hours or so. Hard to predict. > > The basic question that I would like to have answered is what the userspace > component should look like? libv4l-like plugin or a library that userspace can > link with? Do we want more general support for stateful codecs as well that > deals > with resolution changes and the more complex parts of the codec API? > > I've mailed this directly to those that I expect are most interested in this, > but if someone want to join in let me know. > > I want to keep the group small though, so you need to bring relevant > experience > to the table. > No preference for me either. Thanks!
[PATCH 1/1] omap3isp: Unregister media device as first
While there are issues related to object lifetime management, unregister the
media device first when the driver is being unbound. This is slightly
safer.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/isp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 93f032a39470..4194ea82e6c4 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1587,6 +1587,8 @@ static void isp_pm_complete(struct device *dev)
static void isp_unregister_entities(struct isp_device *isp)
{
+ media_device_unregister(&isp->media_dev);
+
omap3isp_csi2_unregister_entities(&isp->isp_csi2a);
omap3isp_ccp2_unregister_entities(&isp->isp_ccp2);
omap3isp_ccdc_unregister_entities(&isp->isp_ccdc);
@@ -1597,7 +1599,6 @@ static void isp_unregister_entities(struct isp_device
*isp)
omap3isp_stat_unregister_entities(&isp->isp_hist);
v4l2_device_unregister(&isp->v4l2_dev);
- media_device_unregister(&isp->media_dev);
media_device_cleanup(&isp->media_dev);
}
--
2.11.0
Re: [PATCH 1/1] media: docs: Document metadata format in struct v4l2_format
On Tue, Oct 09, 2018 at 01:32:57PM +0200, Hans Verkuil wrote: > On 10/09/18 13:31, Sakari Ailus wrote: > > The format fields in struct v4l2_format were otherwise reported but the > > meta field was missing. Document it. > > > > Reported-by: Hans Verkuil > > Signed-off-by: Sakari Ailus > > Acked-by: Hans Verkuil > > Thanks! Thanks! I'll replace "reported" in the commit message by "documented" for the pull request. -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH 1/1] media: docs: Document metadata format in struct v4l2_format
On 10/09/18 13:31, Sakari Ailus wrote:
> The format fields in struct v4l2_format were otherwise reported but the
> meta field was missing. Document it.
>
> Reported-by: Hans Verkuil
> Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
Thanks!
Hans
> ---
> Documentation/media/uapi/v4l/dev-meta.rst | 2 +-
> Documentation/media/uapi/v4l/vidioc-g-fmt.rst | 5 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/media/uapi/v4l/dev-meta.rst
> b/Documentation/media/uapi/v4l/dev-meta.rst
> index f7ac8d0d3af14..b65dc078abeb8 100644
> --- a/Documentation/media/uapi/v4l/dev-meta.rst
> +++ b/Documentation/media/uapi/v4l/dev-meta.rst
> @@ -40,7 +40,7 @@ To use the :ref:`format` ioctls applications set the
> ``type`` field of the
> the desired operation. Both drivers and applications must set the remainder
> of
> the :c:type:`v4l2_format` structure to 0.
>
> -.. _v4l2-meta-format:
> +.. c:type:: v4l2_meta_format
>
> .. tabularcolumns:: |p{1.4cm}|p{2.2cm}|p{13.9cm}|
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
> b/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
> index 3ead350e099f9..9ea494a8facab 100644
> --- a/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
> @@ -133,6 +133,11 @@ The format as returned by :ref:`VIDIOC_TRY_FMT
> ` must be identical
>- Definition of a data format, see :ref:`pixfmt`, used by SDR
> capture and output devices.
> * -
> + - struct :c:type:`v4l2_meta_format`
> + - ``meta``
> + - Definition of a metadata format, see :ref:`meta-formats`, used by
> + metadata capture devices.
> +* -
>- __u8
>- ``raw_data``\ [200]
>- Place holder for future extensions.
>
[PATCH 1/1] media: docs: Document metadata format in struct v4l2_format
The format fields in struct v4l2_format were otherwise reported but the
meta field was missing. Document it.
Reported-by: Hans Verkuil
Signed-off-by: Sakari Ailus
---
Documentation/media/uapi/v4l/dev-meta.rst | 2 +-
Documentation/media/uapi/v4l/vidioc-g-fmt.rst | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/dev-meta.rst
b/Documentation/media/uapi/v4l/dev-meta.rst
index f7ac8d0d3af14..b65dc078abeb8 100644
--- a/Documentation/media/uapi/v4l/dev-meta.rst
+++ b/Documentation/media/uapi/v4l/dev-meta.rst
@@ -40,7 +40,7 @@ To use the :ref:`format` ioctls applications set the ``type``
field of the
the desired operation. Both drivers and applications must set the remainder of
the :c:type:`v4l2_format` structure to 0.
-.. _v4l2-meta-format:
+.. c:type:: v4l2_meta_format
.. tabularcolumns:: |p{1.4cm}|p{2.2cm}|p{13.9cm}|
diff --git a/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
b/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
index 3ead350e099f9..9ea494a8facab 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-fmt.rst
@@ -133,6 +133,11 @@ The format as returned by :ref:`VIDIOC_TRY_FMT
` must be identical
- Definition of a data format, see :ref:`pixfmt`, used by SDR
capture and output devices.
* -
+ - struct :c:type:`v4l2_meta_format`
+ - ``meta``
+ - Definition of a metadata format, see :ref:`meta-formats`, used by
+ metadata capture devices.
+* -
- __u8
- ``raw_data``\ [200]
- Place holder for future extensions.
--
2.11.0
Re: [PATCH 4/7] mfd: ds90ux9xx: add TI DS90Ux9xx de-/serializer MFD driver
On 10/09/2018 07:08 AM, kbuild test robot wrote: > Hi Vladimir, > > I love your patch! Perhaps something to improve: > > [auto build test WARNING on ljones-mfd/for-mfd-next] > [also build test WARNING on v4.19-rc7 next-20181008] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Vladimir-Zapolskiy/mfd-pinctrl-add-initial-support-of-TI-DS90Ux9xx-ICs/20181009-090135 > base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > for-mfd-next > config: i386-allyesconfig (attached as .config) > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > Note: it may well be a FALSE warning. FWIW you are at least aware of it now. > http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings > And it is a false positive. -- Best wishes, Vladimir
Re: [PATCH 1/7] dt-bindings: mfd: ds90ux9xx: add description of TI DS90Ux9xx ICs
Hi Marek,
On 10/09/2018 03:13 AM, Marek Vasut wrote:
> On 10/08/2018 11:11 PM, Vladimir Zapolskiy wrote:
>> From: Sandeep Jain
>>
>> The change adds device tree binding description of TI DS90Ux9xx
>> series of serializer and deserializer controllers which support video,
>> audio and control data transmission over FPD-III Link connection.
>>
>> Signed-off-by: Sandeep Jain
>> [vzapolskiy: various updates and corrections of secondary importance]
>> Signed-off-by: Vladimir Zapolskiy
>> ---
>> .../devicetree/bindings/mfd/ti,ds90ux9xx.txt | 66 +++
>> 1 file changed, 66 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/ti,ds90ux9xx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx.txt
>> b/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx.txt
>> new file mode 100644
>> index ..0733da88f7ef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/ti,ds90ux9xx.txt
>> @@ -0,0 +1,66 @@
>> +Texas Instruments DS90Ux9xx de-/serializer controllers
>> +
>> +Required properties:
>> +- compatible: Must contain a generic "ti,ds90ux9xx" value and
>> +may contain one more specific value from the list:
>> +"ti,ds90ub925q",
>> +"ti,ds90uh925q",
>> +"ti,ds90ub927q",
>> +"ti,ds90uh927q",
>> +"ti,ds90ub926q",
>> +"ti,ds90uh926q",
>
> Keep the list sorted.
>
actually the list is a concatenation of two sorted lists, one for
serializers, another for deserializers.
Perhaps it makes sense to keep the list as it is done now and just
mention the selected order, but then it will complicate the formal
description.
>> +"ti,ds90ub928q",
>> +"ti,ds90uh928q",
>> +"ti,ds90ub940q",
>> +"ti,ds90uh940q".
>> +
>> +Optional properties:
>> +- reg : Specifies the I2C slave address of a local de-/serializer.
>> +- power-gpios : GPIO line to control supplied power to the device.
>
> Shouldn't this be regulator phandle ?
It could be, right. I'll ponder upon it.
>> +- ti,backward-compatible-mode : Overrides backward compatibility mode.
>> +Possible values are "<1>" or "<0>".
>
> Make this bool , ie. present or not.
>
It is a real tristate property which is represented by non-present, 0, 1.
It shall not be bool IMHO.
>> +If "ti,backward-compatible-mode" is not mentioned, the backward
>> +compatibility mode is not touched and given by hardware pin strapping.
>> +- ti,low-frequency-mode : Overrides low frequency mode.
>> +Possible values are "<1>" or "<0>".
>> +If "ti,low-frequency-mode" is not mentioned, the low frequency mode
>> +is not touched and given by hardware pin strapping.
>> +- ti,video-map-select-msb: Sets video bridge pins to MSB mode, if it is set
>> +MAPSEL pin value is ignored.
>> +- ti,video-map-select-lsb: Sets video bridge pins to LSB mode, if it is set
>> +MAPSEL pin value is ignored.
>
> This needs some additional explanation, what's this about ?
>
Please reference to datasheet, for instance search for MAPSEL pin description
and overriding I2C commands in
http://www.ti.com/lit/ds/symlink/ds90ub927q-q1.pdf
I believe it makes little sense to copy excessive information from an open
datasheet into bindings documentation.
>> +- ti,pixel-clock-edge : Selects Pixel Clock Edge.
>> +Possible values are "<1>" or "<0>".
>> +If "ti,pixel-clock-edge" is High <1>, output data is strobed on the
>> +Rising edge of the PCLK. If ti,pixel-clock-edge is Low <0>, data is
>> +strobed on the Falling edge of the PCLK.
>> +If "ti,pixel-clock-edge" is not mentioned, the pixel clock edge
>> +value is not touched and given by hardware pin strapping.
>> +- ti,spread-spectrum-clock-generation : Spread Sprectrum Clock Generation.
>> +Possible values are from "<0>" to "<7>". The same value will be
>> +written to SSC register. If "ti,spread-spectrum-clock-gen" is not
>> +found, then SSCG will be disabled.
>> +
>> +TI DS90Ux9xx serializers and deserializer device nodes may contain a number
>> +of children device nodes to describe and enable particular subcomponents
>> +found on ICs.
>> +
>> +Example:
>> +
>> +serializer: serializer@c {
>> +compatible = "ti,ds90ub927q", "ti,ds90ux9xx";
>> +reg = <0xc>;
>> +power-gpios = <&gpio5 12 GPIO_ACTIVE_HIGH>;
>> +ti,backward-compatible-mode = <0>;
>> +ti,low-frequency-mode = <0>;
>> +ti,pixel-clock-edge = <0>;
>> +...
>> +}
>> +
>> +deserializer: deserializer@3c {
>> +compatible = "ti,ds90ub940q", "ti,ds90ux9xx";
>> +reg = <0x3c>;
>> +power-gpios = <&gpio6 31 GPIO_ACTIVE_HIGH>;
>> +...
>> +}
>> +
>>
>
--
Best wishes,
Vladimir
Re: [PATCH] media: videodev2: add V4L2_FMT_FLAG_NO_SOURCE_CHANGE
Hi Tomasz,
On Tue, Oct 9, 2018 at 9:59 AM Tomasz Figa wrote:
>
> Hi Maxime,
>
> On Thu, Oct 4, 2018 at 10:38 PM Maxime Jourdan wrote:
> >
> > When a v4l2 driver exposes V4L2_EVENT_SOURCE_CHANGE, some (usually
> > OUTPUT) formats may not be able to trigger this event.
> >
> > Add a enum_fmt format flag to tag those specific formats.
> >
> > Signed-off-by: Maxime Jourdan
> > ---
> > Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 5 +
> > include/uapi/linux/videodev2.h | 5 +++--
> > 2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> > b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> > index 019c513df217..e0040b36ac43 100644
> > --- a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> > +++ b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> > @@ -116,6 +116,11 @@ one until ``EINVAL`` is returned.
> >- This format is not native to the device but emulated through
> > software (usually libv4l2), where possible try to use a native
> > format instead for better performance.
> > +* - ``V4L2_FMT_FLAG_NO_SOURCE_CHANGE``
> > + - 0x0004
> > + - The event ``V4L2_EVENT_SOURCE_CHANGE`` is not supported
> > + for this format.
> > +
> >
> >
> > Return Value
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 3a65951ca51e..a28acee1cb52 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -723,8 +723,9 @@ struct v4l2_fmtdesc {
> > __u32 reserved[4];
> > };
> >
> > -#define V4L2_FMT_FLAG_COMPRESSED 0x0001
> > -#define V4L2_FMT_FLAG_EMULATED 0x0002
> > +#define V4L2_FMT_FLAG_COMPRESSED 0x0001
> > +#define V4L2_FMT_FLAG_EMULATED 0x0002
> > +#define V4L2_FMT_FLAG_NO_SOURCE_CHANGE 0x0004
>
> I think it indeed makes sense. I'd suggest submitting this patch
> together with the series that adds the affected driver, though, since
> we'd be otherwise just adding a dead API.
>
> Also, it would be good to refer to it from the Decoder Interface
> documentation. Depending on which one gets in earlier, you might
> either want to base on it or I'd add a note myself.
>
> Best regards,
> Tomasz
Agreed on both points. If your documentation makes it in before, I'll
update it within the patch. We'll have time to sync on that anyway in
the coming weeks.
Maxime
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
Em Mon, 8 Oct 2018 13:53:29 +0200 Hans Verkuil escreveu: > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace support > for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to prepare > for that in advance, esp. since I myself do not have any experience writing > userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to work > for most of us (because the topics in the program appear to be boring for us > media types!): > > Tuesday from 10:50-15:50 Should work. There's an speech from Julia that could be interesting, related to the usage of AI for improving the quality of patches that could be interesting. > > or: > > Monday from 15:45 onward I won't be able to attend on Monday. > > My guess is that we need 2-3 hours or so. Hard to predict. > > The basic question that I would like to have answered is what the userspace > component should look like? libv4l-like plugin or a library that userspace can > link with? Do we want more general support for stateful codecs as well that > deals > with resolution changes and the more complex parts of the codec API? > > I've mailed this directly to those that I expect are most interested in this, > but if someone want to join in let me know. > > I want to keep the group small though, so you need to bring relevant > experience > to the table. > > Regards, > > Hans Thanks, Mauro
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
Hi! Thanks for setting this up On Mon, Oct 08, 2018 at 01:53:29PM +0200, Hans Verkuil wrote: > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace support > for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to prepare > for that in advance, esp. since I myself do not have any experience writing > userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to work > for most of us (because the topics in the program appear to be boring for us > media types!): > > Tuesday from 10:50-15:50 > > or: > > Monday from 15:45 onward I have no strong preference there, both work for me. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [RFC PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
On 10/09/18 09:41, Tomasz Figa wrote: > On Mon, Oct 8, 2018 at 8:02 PM Hans Verkuil wrote: >> >> On 10/04/2018 10:11 AM, Alexandre Courbot wrote: >>> This patch documents the protocol that user-space should follow when >>> communicating with stateless video decoders. It is based on the >>> following references: >>> >>> * The current protocol used by Chromium (converted from config store to >>> request API) >>> >>> * The submitted Cedrus VPU driver >>> >>> As such, some things may not be entirely consistent with the current >>> state of drivers, so it would be great if all stakeholders could point >>> out these inconsistencies. :) >>> >>> This patch is supposed to be applied on top of the Request API V18 as >>> well as the memory-to-memory video decoder interface series by Tomasz >>> Figa. >>> >>> Changes since V1: >>> >>> * Applied fixes received as feedback, >>> * Moved controls descriptions to the extended controls file, >>> * Document reference frame management and referencing (need Hans' feedback >>> on >>> that). >>> >>> Signed-off-by: Alexandre Courbot >>> --- >>> .../media/uapi/v4l/dev-stateless-decoder.rst | 348 ++ >>> Documentation/media/uapi/v4l/devices.rst | 1 + >>> .../media/uapi/v4l/extended-controls.rst | 25 ++ >>> .../media/uapi/v4l/pixfmt-compressed.rst | 54 ++- >>> 4 files changed, 424 insertions(+), 4 deletions(-) >>> create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst >>> >>> diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst >>> b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst >> >> >> >>> +Buffer management during decoding >>> += >>> +Contrary to stateful decoder drivers, a stateless decoder driver does not >>> +perform any kind of buffer management. In particular, it guarantees that >>> +``CAPTURE`` buffers will be dequeued in the same order as they are queued. >>> This >>> +allows user-space to know in advance which ``CAPTURE`` buffer will contain >>> a >>> +given frame, and thus to use that buffer ID as the key to indicate a >>> reference >>> +frame. >>> + >>> +This also means that user-space is fully responsible for not queuing a >>> given >>> +``CAPTURE`` buffer for as long as it is used as a reference frame. Failure >>> to do >>> +so will overwrite the reference frame's data while it is still in use, and >>> +result in visual corruption of future frames. >>> + >>> +Note that this applies to all types of buffers, and not only to >>> +``V4L2_MEMORY_MMAP`` ones, as drivers supporting ``V4L2_MEMORY_DMABUF`` >>> will >>> +typically maintain a map of buffer IDs to DMABUF handles for reference >>> frame >>> +management. Queueing a buffer will result in the map entry to be >>> overwritten >>> +with the new DMABUF handle submitted in the :c:func:`VIDIOC_QBUF` ioctl. >> >> The more I think about this, the more I believe that relying on capture >> buffer >> indices is wrong. It's easy enough if there is a straightforward 1-1 >> relationship, >> but what if you have H264 slices as Nicolas mentioned and it becomes a N-1 >> relationship? >> >> Yes, you can still do this in userspace, but it becomes a lot more >> complicated. >> >> And what if in the future instead of having one capture buffer per decoded >> frame >> there will be multiple capture buffers per decoded frame, each with a single >> slice (for example)? > > Is there any particular scenario you have in mind, where such case would > happen? Video conferencing to reduce the latency, i.e. no need to wait for the full frame to be available, just start processing as soon as a decoded slice arrives. > >> >> I would feel much happier if we used a 'cookie' to refer to buffers. > > Hmm, how would this cookie work in a case of N OUTPUT -> 1 CAPTURE case? The output buffers would use the same cookie. Regards, Hans > > Best regards, > Tomasz >
[PATCH] media: venus: add support for key frame
When client requests for a keyframe, set the property
to hardware to generate the sync frame.
Signed-off-by: Malathi Gottam
---
drivers/media/platform/qcom/venus/venc_ctrls.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 45910172..f332c8e 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -81,6 +81,8 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
struct venc_controls *ctr = &inst->controls.enc;
u32 bframes;
int ret;
+ void *ptr;
+ u32 ptype;
switch (ctrl->id) {
case V4L2_CID_MPEG_VIDEO_BITRATE_MODE:
@@ -173,6 +175,14 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
ctr->num_b_frames = bframes;
break;
+ case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:
+ ptype = HFI_PROPERTY_CONFIG_VENC_REQUEST_SYNC_FRAME;
+ ret = hfi_session_set_property(inst, ptype, ptr);
+
+ if (ret)
+ return ret;
+
+ break;
default:
return -EINVAL;
}
@@ -309,6 +319,9 @@ int venc_ctrl_init(struct venus_inst *inst)
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_H264_I_PERIOD, 0, (1 << 16) - 1, 1, 0);
+ v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME, 0, 0, 0, 0);
+
ret = inst->ctrl_handler.error;
if (ret)
goto err;
--
1.9.1
[PATCH] media: venus: add support for selection rectangles
Handles target type crop by setting the new active rectangle
to hardware. The new rectangle should be within YUV size.
Signed-off-by: Malathi Gottam
---
drivers/media/platform/qcom/venus/venc.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 3f50cd0..754c19a 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -478,16 +478,31 @@ static int venc_g_fmt(struct file *file, void *fh, struct
v4l2_format *f)
venc_s_selection(struct file *file, void *fh, struct v4l2_selection *s)
{
struct venus_inst *inst = to_inst(file);
+ int ret;
+ u32 buftype;
if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)
return -EINVAL;
switch (s->target) {
case V4L2_SEL_TGT_CROP:
- if (s->r.width != inst->out_width ||
- s->r.height != inst->out_height ||
+ if (s->r.width > inst->out_width ||
+ s->r.height > inst->out_height ||
s->r.top != 0 || s->r.left != 0)
return -EINVAL;
+ if (s->r.width != inst->width ||
+ s->r.height != inst->height) {
+ buftype = HFI_BUFFER_OUTPUT;
+ ret = venus_helper_set_output_resolution(inst,
+s->r.width,
+s->r.height,
+buftype);
+ if (ret)
+ return ret;
+
+ inst->width = s->r.width;
+ inst->height = s->r.height;
+ }
break;
default:
return -EINVAL;
--
1.9.1
[PATCH] media: venus: queue initial buffers
Buffers can be queued to driver before the planes are
set to start streaming. Queue those buffers to firmware
once start streaming is called on both the planes.
Signed-off-by: Malathi Gottam
---
drivers/media/platform/qcom/venus/helpers.c | 22 ++
drivers/media/platform/qcom/venus/helpers.h | 1 +
drivers/media/platform/qcom/venus/venc.c| 5 +
3 files changed, 28 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index e436385..2679adb 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -1041,6 +1041,28 @@ void venus_helper_vb2_stop_streaming(struct vb2_queue *q)
}
EXPORT_SYMBOL_GPL(venus_helper_vb2_stop_streaming);
+int venus_helper_queue_initial_bufs(struct venus_inst *inst)
+{
+ struct v4l2_m2m_ctx *m2m_ctx = inst->m2m_ctx;
+ struct v4l2_m2m_buffer *buf, *n;
+ int ret;
+
+ v4l2_m2m_for_each_dst_buf_safe(m2m_ctx, buf, n) {
+ ret = session_process_buf(inst, &buf->vb);
+ if (ret)
+ return_buf_error(inst, &buf->vb);
+ }
+
+ v4l2_m2m_for_each_src_buf_safe(m2m_ctx, buf, n) {
+ ret = session_process_buf(inst, &buf->vb);
+ if (ret)
+ return_buf_error(inst, &buf->vb);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(venus_helper_queue_initial_bufs);
+
int venus_helper_vb2_start_streaming(struct venus_inst *inst)
{
struct venus_core *core = inst->core;
diff --git a/drivers/media/platform/qcom/venus/helpers.h
b/drivers/media/platform/qcom/venus/helpers.h
index 2475f284..f4d76ab 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -31,6 +31,7 @@ void venus_helper_buffers_done(struct venus_inst *inst,
int venus_helper_vb2_start_streaming(struct venus_inst *inst);
void venus_helper_m2m_device_run(void *priv);
void venus_helper_m2m_job_abort(void *priv);
+int venus_helper_queue_initial_bufs(struct venus_inst *inst);
int venus_helper_get_bufreq(struct venus_inst *inst, u32 type,
struct hfi_buffer_requirements *req);
u32 venus_helper_get_framesz_raw(u32 hfi_fmt, u32 width, u32 height);
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index ce85962..ef11495 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -989,6 +989,11 @@ static int venc_start_streaming(struct vb2_queue *q,
unsigned int count)
if (ret)
goto deinit_sess;
+ ret = venus_helper_queue_initial_bufs(inst);
+ if (ret)
+ goto deinit_sess;
+ }
+
mutex_unlock(&inst->lock);
return 0;
--
1.9.1
[PATCH] media: venus: amend buffer size for bitstream plane
For lower resolutions, incase of encoder, the compressed
frame size is more than half of the corresponding input
YUV. Keep the size as same as YUV considering worst case.
Signed-off-by: Malathi Gottam
---
drivers/media/platform/qcom/venus/helpers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 2679adb..05c5423 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -649,7 +649,7 @@ u32 venus_helper_get_framesz(u32 v4l2_fmt, u32 width, u32
height)
}
if (compressed) {
- sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 / 2;
+ sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2;
return ALIGN(sz, SZ_4K);
}
--
1.9.1
Re: [PATCH] media: videodev2: add V4L2_FMT_FLAG_NO_SOURCE_CHANGE
Hi Maxime,
On Thu, Oct 4, 2018 at 10:38 PM Maxime Jourdan wrote:
>
> When a v4l2 driver exposes V4L2_EVENT_SOURCE_CHANGE, some (usually
> OUTPUT) formats may not be able to trigger this event.
>
> Add a enum_fmt format flag to tag those specific formats.
>
> Signed-off-by: Maxime Jourdan
> ---
> Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 5 +
> include/uapi/linux/videodev2.h | 5 +++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> index 019c513df217..e0040b36ac43 100644
> --- a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> @@ -116,6 +116,11 @@ one until ``EINVAL`` is returned.
>- This format is not native to the device but emulated through
> software (usually libv4l2), where possible try to use a native
> format instead for better performance.
> +* - ``V4L2_FMT_FLAG_NO_SOURCE_CHANGE``
> + - 0x0004
> + - The event ``V4L2_EVENT_SOURCE_CHANGE`` is not supported
> + for this format.
> +
>
>
> Return Value
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 3a65951ca51e..a28acee1cb52 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -723,8 +723,9 @@ struct v4l2_fmtdesc {
> __u32 reserved[4];
> };
>
> -#define V4L2_FMT_FLAG_COMPRESSED 0x0001
> -#define V4L2_FMT_FLAG_EMULATED 0x0002
> +#define V4L2_FMT_FLAG_COMPRESSED 0x0001
> +#define V4L2_FMT_FLAG_EMULATED 0x0002
> +#define V4L2_FMT_FLAG_NO_SOURCE_CHANGE 0x0004
I think it indeed makes sense. I'd suggest submitting this patch
together with the series that adds the affected driver, though, since
we'd be otherwise just adding a dead API.
Also, it would be good to refer to it from the Decoder Interface
documentation. Depending on which one gets in earlier, you might
either want to base on it or I'd add a note myself.
Best regards,
Tomasz
[PATCH] media: venus: add support for USERPTR to queue
Add USERPTR to queue access methods by adding this support to io_modes on both the planes. Signed-off-by: Malathi Gottam --- drivers/media/platform/qcom/venus/venc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c index 754c19a..b86994c 100644 --- a/drivers/media/platform/qcom/venus/venc.c +++ b/drivers/media/platform/qcom/venus/venc.c @@ -1096,7 +1096,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue *src_vq, int ret; src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE; - src_vq->io_modes = VB2_MMAP | VB2_DMABUF; + src_vq->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; src_vq->ops = &venc_vb2_ops; src_vq->mem_ops = &vb2_dma_sg_memops; @@ -1112,7 +1112,7 @@ static int m2m_queue_init(void *priv, struct vb2_queue *src_vq, return ret; dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; - dst_vq->io_modes = VB2_MMAP | VB2_DMABUF; + dst_vq->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; dst_vq->ops = &venc_vb2_ops; dst_vq->mem_ops = &vb2_dma_sg_memops; -- 1.9.1
[PATCH] media: venus: handle peak bitrate set property
Max bitrate property is not supported for venus version 4xx.
Add a version check for the same.
Signed-off-by: Malathi Gottam
---
drivers/media/platform/qcom/venus/venc.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index ef11495..3f50cd0 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -757,18 +757,20 @@ static int venc_set_properties(struct venus_inst *inst)
if (ret)
return ret;
- if (!ctr->bitrate_peak)
- bitrate *= 2;
- else
- bitrate = ctr->bitrate_peak;
+ if (!IS_V4(inst->core)) {
+ if (!ctr->bitrate_peak)
+ bitrate *= 2;
+ else
+ bitrate = ctr->bitrate_peak;
- ptype = HFI_PROPERTY_CONFIG_VENC_MAX_BITRATE;
- brate.bitrate = bitrate;
- brate.layer_id = 0;
+ ptype = HFI_PROPERTY_CONFIG_VENC_MAX_BITRATE;
+ brate.bitrate = bitrate;
+ brate.layer_id = 0;
- ret = hfi_session_set_property(inst, ptype, &brate);
- if (ret)
- return ret;
+ ret = hfi_session_set_property(inst, ptype, &brate);
+ if (ret)
+ return ret;
+ }
if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264) {
profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_PROFILE,
--
1.9.1
Re: [RFC PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
On Mon, Oct 8, 2018 at 8:02 PM Hans Verkuil wrote: > > On 10/04/2018 10:11 AM, Alexandre Courbot wrote: > > This patch documents the protocol that user-space should follow when > > communicating with stateless video decoders. It is based on the > > following references: > > > > * The current protocol used by Chromium (converted from config store to > > request API) > > > > * The submitted Cedrus VPU driver > > > > As such, some things may not be entirely consistent with the current > > state of drivers, so it would be great if all stakeholders could point > > out these inconsistencies. :) > > > > This patch is supposed to be applied on top of the Request API V18 as > > well as the memory-to-memory video decoder interface series by Tomasz > > Figa. > > > > Changes since V1: > > > > * Applied fixes received as feedback, > > * Moved controls descriptions to the extended controls file, > > * Document reference frame management and referencing (need Hans' feedback > > on > > that). > > > > Signed-off-by: Alexandre Courbot > > --- > > .../media/uapi/v4l/dev-stateless-decoder.rst | 348 ++ > > Documentation/media/uapi/v4l/devices.rst | 1 + > > .../media/uapi/v4l/extended-controls.rst | 25 ++ > > .../media/uapi/v4l/pixfmt-compressed.rst | 54 ++- > > 4 files changed, 424 insertions(+), 4 deletions(-) > > create mode 100644 Documentation/media/uapi/v4l/dev-stateless-decoder.rst > > > > diff --git a/Documentation/media/uapi/v4l/dev-stateless-decoder.rst > > b/Documentation/media/uapi/v4l/dev-stateless-decoder.rst > > > > > +Buffer management during decoding > > += > > +Contrary to stateful decoder drivers, a stateless decoder driver does not > > +perform any kind of buffer management. In particular, it guarantees that > > +``CAPTURE`` buffers will be dequeued in the same order as they are queued. > > This > > +allows user-space to know in advance which ``CAPTURE`` buffer will contain > > a > > +given frame, and thus to use that buffer ID as the key to indicate a > > reference > > +frame. > > + > > +This also means that user-space is fully responsible for not queuing a > > given > > +``CAPTURE`` buffer for as long as it is used as a reference frame. Failure > > to do > > +so will overwrite the reference frame's data while it is still in use, and > > +result in visual corruption of future frames. > > + > > +Note that this applies to all types of buffers, and not only to > > +``V4L2_MEMORY_MMAP`` ones, as drivers supporting ``V4L2_MEMORY_DMABUF`` > > will > > +typically maintain a map of buffer IDs to DMABUF handles for reference > > frame > > +management. Queueing a buffer will result in the map entry to be > > overwritten > > +with the new DMABUF handle submitted in the :c:func:`VIDIOC_QBUF` ioctl. > > The more I think about this, the more I believe that relying on capture buffer > indices is wrong. It's easy enough if there is a straightforward 1-1 > relationship, > but what if you have H264 slices as Nicolas mentioned and it becomes a N-1 > relationship? > > Yes, you can still do this in userspace, but it becomes a lot more > complicated. > > And what if in the future instead of having one capture buffer per decoded > frame > there will be multiple capture buffers per decoded frame, each with a single > slice (for example)? Is there any particular scenario you have in mind, where such case would happen? > > I would feel much happier if we used a 'cookie' to refer to buffers. Hmm, how would this cookie work in a case of N OUTPUT -> 1 CAPTURE case? Best regards, Tomasz
Re: [RFC PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
On Sat, Oct 6, 2018 at 2:09 AM Paul Kocialkowski wrote: > > Hi, > > Le jeudi 04 octobre 2018 à 14:10 -0400, Nicolas Dufresne a écrit : > > Le jeudi 04 octobre 2018 à 14:47 +0200, Paul Kocialkowski a écrit : > > > > +Instance of struct v4l2_ctrl_h264_scaling_matrix, containing the > > > > scaling > > > > +matrix to use when decoding the next queued frame. Applicable to > > > > the H.264 > > > > +stateless decoder. > > > > + > > > > +``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM`` > > > > > > Ditto with "H264_SLICE_PARAMS". > > > > > > > +Array of struct v4l2_ctrl_h264_slice_param, containing at least as > > > > many > > > > +entries as there are slices in the corresponding ``OUTPUT`` buffer. > > > > +Applicable to the H.264 stateless decoder. > > > > + > > > > +``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAM`` > > > > +Instance of struct v4l2_ctrl_h264_decode_param, containing the > > > > high-level > > > > +decoding parameters for a H.264 frame. Applicable to the H.264 > > > > stateless > > > > +decoder. > > > > > > Since we require all the macroblocks to decode one frame to be held in > > > the same OUTPUT buffer, it probably doesn't make sense to keep > > > DECODE_PARAM and SLICE_PARAM distinct. > > > > > > I would suggest merging both in "SLICE_PARAMS", similarly to what I > > > have proposed for H.265: https://patchwork.kernel.org/patch/10578023/ > > > > > > What do you think? > > > > I don't understand why we add this arbitrary restriction of "all the > > macroblocks to decode one frame". The bitstream may contain multiple > > NALs per frame (e.g. slices), and stateless API shall pass each NAL > > separately imho. The driver can then decide to combine them if needed, > > or to keep them seperate. I would expect most decoder to decode each > > slice independently from each other, even though they write into the > > same frame. > > Well, we sort of always assumed that there is a 1:1 correspondency > between request and output frame when implemeting the software for > cedrus, which simplified both userspace and the driver. The approach we > have taken is to use one of the slice parameters for the whole series > of slices and just append the slice data. > > Now that you bring it up, I realize this is an unfortunate decision. > This may have been the cause of bugs and limitations with our driver > because the slice parameters may very well be distinct for each slice. I might be misunderstanding something, but, at least for the H.264 API, there is no relation between the number of buffers/requests and number of slice parameters. The V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM is an array, with each element describing each slice in the OUTPUT buffer. So actually, it could be up to the userspace if it want to have 1 OUTPUT buffer per slice or all slices in 1 OUTPUT buffer - the former would have v4l2_ctrl_h264_decode_param::num_slices = 1 and only one valid element in V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS. > Moreover, I suppose that just appending the slices data implies that > they are coded in the same order as the picture, which is probably > often the case but certainly not anything guaranteed. Again, at least in the H.264 API being proposed here, the order of slices is not specified by the order of slice data in the buffer. Each entry of the V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS array points to the specific offset within the buffer. Best regards, Tomasz
Re: [RFC PATCH v2] media: docs-rst: Document m2m stateless video decoder interface
On Thu, Oct 4, 2018 at 9:46 PM Paul Kocialkowski wrote: > > Hi, > > Here are a few minor suggestion about H.264 controls. > > Le jeudi 04 octobre 2018 à 17:11 +0900, Alexandre Courbot a écrit : > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > b/Documentation/media/uapi/v4l/extended-controls.rst > > index a9252225b63e..9d06d853d4ff 100644 > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > @@ -810,6 +810,31 @@ enum v4l2_mpeg_video_bitrate_mode - > > otherwise the decoder expects a single frame in per buffer. > > Applicable to the decoder, all codecs. > > > > +.. _v4l2-mpeg-h264: > > + > > +``V4L2_CID_MPEG_VIDEO_H264_SPS`` > > +Instance of struct v4l2_ctrl_h264_sps, containing the SPS of to use > > with > > +the next queued frame. Applicable to the H.264 stateless decoder. > > + > > +``V4L2_CID_MPEG_VIDEO_H264_PPS`` > > +Instance of struct v4l2_ctrl_h264_pps, containing the PPS of to use > > with > > +the next queued frame. Applicable to the H.264 stateless decoder. > > + > > +``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX`` > > For consistency with MPEG-2 and upcoming JPEG, I think we should call > this "H264_QUANTIZATION". I'd rather stay consistent with H.264 specification, which uses the wording as defined in Alex's patch. Otherwise it would be difficult to correlate between the controls and the specification, which is something that the userspace developer would definitely need to understand how to properly parse the stream and obtain the decoding parameters. > > > +Instance of struct v4l2_ctrl_h264_scaling_matrix, containing the > > scaling > > +matrix to use when decoding the next queued frame. Applicable to the > > H.264 > > +stateless decoder. > > + > > +``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAM`` > > Ditto with "H264_SLICE_PARAMS". > It doesn't seem to be related to the spec in this case and "params" sounds better indeed. Best regards, Tomasz
[GIT PULL FOR v4.20] v4l2-tpg kernel oops fix
The following changes since commit 9e5b5081fa117ae34eca94b63b1cb6d43dc28f10: media: dw9807-vcm: Fix probe error handling (2018-10-08 11:51:31 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-for-v4.20g for you to fetch changes up to 936f118946f8f8d35d96346641a5ec873ac8125d: v4l2-tpg: fix kernel oops when enabling HFLIP and OSD (2018-10-09 09:09:44 +0200) Tag branch Hans Verkuil (1): v4l2-tpg: fix kernel oops when enabling HFLIP and OSD drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
