Re: [RFC] How to get current position/status of iris/focus/pan/tilt/zoom?
Hi Laurent, On 07/08/15 13:25, Laurent Pinchart wrote: Hi Hans, On Thursday 02 July 2015 14:00:23 Hans Verkuil wrote: When using V4L2_CID_IRIS/FOCUS/PAN/TILT/ZOOM_ABSOLUTE/RELATIVE, how do you know when the new position has been reached? If this is controlled through a motor, then it may take some time and ideally you would like to be able to get the current absolute position (if the hardware knows) and whether the final position has been reached or not. There's only two drivers implementing pan and tilt (pwc and uvcvideo), one driver implementing focus and iris (uvcvideo) and three drivers implementing zoom (uvcvideo, m5mols and s5c73m3). Both m5mols and s5c73m3 seem to use the zoom control for digital zoom, so we can ignore them for this discussion. Where's thus left with pwc and uvcvideo. I'll comment mainly on the latter. In addition, it should be possible to raise fault conditions. UVC specifies a way to implement asynchronous controls and report, through a USB interrupt endpoint, completion of the control set operation. This can be used by devices to report that physical motion has finished, or to report errors. Whether a control is implemented in a synchronous or asynchronous way is device dependent. The way the ABSOLUTE controls are defined is ambiguous since it doesn't say anything about what it returns when you read it: is that the current absolute position, or the last set absolute position? I suspect it is the second one. If it is the second one, then I propose a V4L2_CID_IRIS_CURRENT control (and ditto for the other variants) that is a read-only control returning the current position with the same range and unit as the ABSOLUTE control. UVC doesn't explicitly define what a device should report. It hints in a couple of places that it should be the current position, but I believe it might be device-dependent in practice. What does the uvc driver do today when an application asks for the IRIS_ABSOLUTE value? Does it pass that request on to the webcam or does it return the last set value? We can choose to have the control type determine what the control does: if it is just a normal integer control, then it returns the last set value. If the hardware can return the current position, then it can set the new V4L2_CTRL_FLAG_EXECUTE_ON_WRITE flag, which means that when you read it you get the actual position, and when you write it you set the desired position. But I don't know if the UVC driver can use this. I guess from your description that it can determine this based on whether the control is synchronous or asynchronous. For the status/fault information I think the V4L2_CID_AUTO_FOCUS_STATUS comes close, but it is too specific for auto focus. For manually positioning things this might be more suitable: V4L2_CID_IRIS_STATUS bitmask V4L2_IRIS_STATUS_MOVING (or perhaps _BUSY?) V4L2_IRIS_STATUS_FAILED And ditto for the other variants. Do we need to report that the control set operation is in progress, or could applications infer that information from the fact that they haven't received a control change event that notifies of end of motion ? You do need some sort of 'in progress' control or status. You don't want to require applications to check control change events for the new value and compare it to the end-value to determine if it is moving. And you can't use that anyway if an error occurs that forces the motor to stop moving before the final position has been reached. Failures need to be reported, but they're not limited to the controls you mention above, at least in theory. A UVC device is free to implement any control as an asynchronous control and report failures. Would it make sense to add a control change error event instead of creating status controls for lots of V4L2 controls ? Hmm, interesting, need to think about this. Question: when you set an asynchronous uvc control, does it report back that the new value was set OK, or does it only report back errors? And what sort of errors are defined? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] [media] tc358743: support probe from device tree
Hi Hans,
Am Montag, den 13.07.2015, 12:57 +0200 schrieb Hans Verkuil:
[...]
@@ -69,6 +72,7 @@ static const struct v4l2_dv_timings_cap
tc358743_timings_cap = {
struct tc358743_state {
struct tc358743_platform_data pdata;
+ struct v4l2_of_bus_mipi_csi2 bus;
Where is this bus struct set?
Uh-oh, I have accidentally dropped setting the bus struct when switching
to v4l2_of_alloc_parse_endpoint.
[...]
@@ -700,7 +706,8 @@ static void tc358743_set_csi(struct v4l2_subdev *sd)
((lanes 2) ? MASK_D2M_HSTXVREGEN : 0x0) |
((lanes 3) ? MASK_D3M_HSTXVREGEN : 0x0));
- i2c_wr32(sd, TXOPTIONCNTRL, MASK_CONTCLKMODE);
+ i2c_wr32(sd, TXOPTIONCNTRL, (state-bus.flags
+V4L2_MBUS_CSI2_CONTINUOUS_CLOCK) ? MASK_CONTCLKMODE : 0);
It's used here.
BTW, since I don't see state-bus being set, that means bus.flags == 0 and
so this register is now set to 0 instead of MASK_CONTCLKMODE.
When using platform data I guess bus.flags should be set to
V4L2_MBUS_CSI2_CONTINUOUS_CLOCK to prevent breakage.
Ok.
[..]
+ /*
+* The CSI bps per lane must be between 62.5 Mbps and 1 Gbps.
+* The default is 594 Mbps for 4-lane 1080p60 or 2-lane 720p60.
+*/
+ bps_pr_lane = 2 * endpoint-link_frequencies[0];
+ if (bps_pr_lane 6250U || bps_pr_lane 10U) {
+ dev_err(dev, unsupported bps per lane: %u bps\n, bps_pr_lane);
+ goto disable_clk;
+ }
+
+ /* The CSI speed per lane is refclk / pll_prd * pll_fbd */
+ state-pdata.pll_fbd = bps_pr_lane /
+ state-pdata.refclk_hz * state-pdata.pll_prd;
+
+ /*
+* FIXME: These timings are from REF_02 for 594 Mbps per lane (297 MHz
+* link frequency). In principle it should be possible to calculate
+* them based on link frequency and resolution.
+*/
+ if (bps_pr_lane != 59400U)
+ dev_warn(dev, untested bps per lane: %u bps\n, bps_pr_lane);
+ state-pdata.lineinitcnt = 0xe80;
+ state-pdata.lptxtimecnt = 0x003;
+ /* tclk-preparecnt: 3, tclk-zerocnt: 20 */
+ state-pdata.tclk_headercnt = 0x1403;
+ state-pdata.tclk_trailcnt = 0x00;
+ /* ths-preparecnt: 3, ths-zerocnt: 1 */
+ state-pdata.ths_headercnt = 0x0103;
+ state-pdata.twakeup = 0x4882;
+ state-pdata.tclk_postcnt = 0x008;
+ state-pdata.ths_trailcnt = 0x2;
+ state-pdata.hstxvregcnt = 0;
Do you have any suggestion how to handle this? AFAIK REF_02 is not
public, and I do not know the formulas it uses internally to calculate
these timings. I wouldn't want to add all the timing parameters to the
device tree just because of that.
[...]
@@ -1658,14 +1794,19 @@ static int tc358743_probe(struct i2c_client *client,
if (!state)
return -ENOMEM;
+ state-i2c_client = client;
+
/* platform data */
- if (!pdata) {
- v4l_err(client, No platform data!\n);
- return -ENODEV;
+ if (pdata) {
+ state-pdata = *pdata;
+ } else {
+ err = tc358743_probe_of(state);
+ if (err == -ENODEV)
+ v4l_err(client, No platform data!\n);
I'd replace this with No device tree data! or something like that.
I'll do that, thank you.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] [media] tc358743: allow event subscription
Am Montag, den 13.07.2015, 13:07 +0200 schrieb Hans Verkuil:
On 07/10/2015 03:11 PM, Philipp Zabel wrote:
This is useful to subscribe to HDMI hotplug events via the
V4L2_CID_DV_RX_POWER_PRESENT control.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/i2c/tc358743.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 4a889d4..91fffa8 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -40,6 +40,7 @@
#include media/v4l2-dv-timings.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
#include media/v4l2-of.h
#include media/tc358743.h
@@ -1604,6 +1605,8 @@ static const struct v4l2_subdev_core_ops
tc358743_core_ops = {
.s_register = tc358743_s_register,
#endif
.interrupt_service_routine = tc358743_isr,
+ .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
Ah, they are set here.
But note that v4l2_ctrl_subdev_subscribe_event is not enough, since this
driver
also issues the V4L2_EVENT_SOURCE_CHANGE event.
See this patch on how to do that:
http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/commit/?h=for-v4.3aid=85c9b0b83795dac3d27043619a727af5c7313fe7
Note: requires the new v4l2_subdev_notify_event function that's not yet
merged (just posted the pull request for that).
Ok, I think I'll split this up and send patch 5 separately, then.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] [media] tc358743: support probe from device tree
On 07/14/15 12:10, Philipp Zabel wrote:
Hi Hans,
Am Montag, den 13.07.2015, 12:57 +0200 schrieb Hans Verkuil:
[...]
@@ -69,6 +72,7 @@ static const struct v4l2_dv_timings_cap
tc358743_timings_cap = {
struct tc358743_state {
struct tc358743_platform_data pdata;
+ struct v4l2_of_bus_mipi_csi2 bus;
Where is this bus struct set?
Uh-oh, I have accidentally dropped setting the bus struct when switching
to v4l2_of_alloc_parse_endpoint.
[...]
@@ -700,7 +706,8 @@ static void tc358743_set_csi(struct v4l2_subdev *sd)
((lanes 2) ? MASK_D2M_HSTXVREGEN : 0x0) |
((lanes 3) ? MASK_D3M_HSTXVREGEN : 0x0));
- i2c_wr32(sd, TXOPTIONCNTRL, MASK_CONTCLKMODE);
+ i2c_wr32(sd, TXOPTIONCNTRL, (state-bus.flags
+V4L2_MBUS_CSI2_CONTINUOUS_CLOCK) ? MASK_CONTCLKMODE : 0);
It's used here.
BTW, since I don't see state-bus being set, that means bus.flags == 0 and
so this register is now set to 0 instead of MASK_CONTCLKMODE.
When using platform data I guess bus.flags should be set to
V4L2_MBUS_CSI2_CONTINUOUS_CLOCK to prevent breakage.
Ok.
[..]
+ /*
+* The CSI bps per lane must be between 62.5 Mbps and 1 Gbps.
+* The default is 594 Mbps for 4-lane 1080p60 or 2-lane 720p60.
+*/
+ bps_pr_lane = 2 * endpoint-link_frequencies[0];
+ if (bps_pr_lane 6250U || bps_pr_lane 10U) {
+ dev_err(dev, unsupported bps per lane: %u bps\n, bps_pr_lane);
+ goto disable_clk;
+ }
+
+ /* The CSI speed per lane is refclk / pll_prd * pll_fbd */
+ state-pdata.pll_fbd = bps_pr_lane /
+ state-pdata.refclk_hz * state-pdata.pll_prd;
+
+ /*
+* FIXME: These timings are from REF_02 for 594 Mbps per lane (297 MHz
+* link frequency). In principle it should be possible to calculate
+* them based on link frequency and resolution.
+*/
+ if (bps_pr_lane != 59400U)
+ dev_warn(dev, untested bps per lane: %u bps\n, bps_pr_lane);
+ state-pdata.lineinitcnt = 0xe80;
+ state-pdata.lptxtimecnt = 0x003;
+ /* tclk-preparecnt: 3, tclk-zerocnt: 20 */
+ state-pdata.tclk_headercnt = 0x1403;
+ state-pdata.tclk_trailcnt = 0x00;
+ /* ths-preparecnt: 3, ths-zerocnt: 1 */
+ state-pdata.ths_headercnt = 0x0103;
+ state-pdata.twakeup = 0x4882;
+ state-pdata.tclk_postcnt = 0x008;
+ state-pdata.ths_trailcnt = 0x2;
+ state-pdata.hstxvregcnt = 0;
Do you have any suggestion how to handle this? AFAIK REF_02 is not
public, and I do not know the formulas it uses internally to calculate
these timings. I wouldn't want to add all the timing parameters to the
device tree just because of that.
As you said, it's not public and without the formulas there is nothing you
can do but hardcode it.
If I understand this correctly these values depend on the link frequency,
so the DT should contain the link frequency and the driver can hardcode the
values based on that. Which means that if someone needs to support a new
link frequency the driver needs to be extended for that frequency.
As long as Toshiba keeps the formulas under NDA there isn't much else you can
do.
Regards,
Hans
[...]
@@ -1658,14 +1794,19 @@ static int tc358743_probe(struct i2c_client *client,
if (!state)
return -ENOMEM;
+ state-i2c_client = client;
+
/* platform data */
- if (!pdata) {
- v4l_err(client, No platform data!\n);
- return -ENODEV;
+ if (pdata) {
+ state-pdata = *pdata;
+ } else {
+ err = tc358743_probe_of(state);
+ if (err == -ENODEV)
+ v4l_err(client, No platform data!\n);
I'd replace this with No device tree data! or something like that.
I'll do that, thank you.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem
sorry I don’t know how can I do .. can you help me to fix the problem? Please ensure that all communication include the linux media mailing list. It looks like Hauppauge have released an updated HVR-1275 card, as indicated by the updated PCI-SubDevice ID 2A38. The hardware has changed and the driver needs to be modified to support these changes. Modprobing with option=19 isn't going to help. I've reached out to Hauppauge for comment on the new H/W. Stay tuned. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem
Adding in the linux-media mailing list Subject: Hauppauge hvr1275 TV Tuner card linux problem Message: I had one trouble about Hauppauge hvr1275 TV Tuner card Because of I want use tvtime app to play this TV Tuner card with ATI V4900 VGA Card under centos 6.5 linux 2.6.32-431.el6.i686 First I have download Firmeare from: # wget http://steventoth.net/linux/hvr1200/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip # wget http://steventoth.net/linux/hvr1200/extract.sh # /bin/sh extract.sh # sudo cp v4l-cx23885-enc.fw v4l-cx23885-avcore-01.fw dvb-fe-tda10048-1.0.fw /lib/firmware Second create cx23885.conf in /etc/modprobe.d/ Options cx23885 card=19 Type modprobe cx23885 in terminal When I execute tvtime app always show can’t open /dev/video0 When I use dmesg in terminal show below Linux video capture interface: v2.00 cx23885 driver version 0.0.2 loaded cx23885 :04:00.0: PCI INT A -_ GSI 16 (level, low) -_ IRQ 16 CORE cx23885[0]: subsystem: 0070:2a38, board: Hauppauge WinTV-HVR1275 [card=19,insmod option] IR NEC protocol handler initialized IR RC5(x) protocol handler initialized IR RC6 protocol handler initialized IR JVC protocol handler initialized IR Sony protocol handler initialized lirc_dev: IR Remote Control driver registered, major 248 IR LIRC bridge handler initialized tveeprom 11-0050: Hauppauge model 161100, rev A1I6, serial# 9140928 tveeprom 11-0050: MAC address is 00:0d:fe:8b:7a:c0 tveeprom 11-0050: tuner model is unknown (idx 186, type 4) tveeprom 11-0050: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc) tveeprom 11-0050: audio processor is CX23888 (idx 40) tveeprom 11-0050: decoder processor is CX23888 (idx 34) tveeprom 11-0050: has no radio, has IR receiver, has no IR transmitter cx23885[0]: warning: unknown hauppauge model #161100 cx23885[0]: hauppauge eeprom: model=161100 cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card lgdt3305_attach: unable to detect LGDT3305 hardware cx23885[0]: frontend initialization failed cx23885_dvb_register() dvb_register failed err = -1 cx23885_dev_setup() Failed to register dvb on VID_C cx23885_dev_checkrevision() Hardware revision = 0xd0 cx23885[0]/0: found at :04:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xfbe0 cx23885 :04:00.0: setting latency timer to 64 alloc irq_desc for 34 on node -1 alloc kstat_irqs on node -1 if use dmesg | grep cx23885 in terminal show below cx23885 driver version 0.0.2 loaded cx23885 :05:00.0: PCI INT A -_ GSI 16 (level, low) -_ IRQ 16 CORE cx23885[0]: subsystem: 0070:2a38, board: Hauppauge WinTV-HVR1275 [card=19,insmod option] cx23885[0]: warning: unknown hauppauge model #161100 cx23885[0]: hauppauge eeprom: model=161100 cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card cx23885[0]: frontend initialization failed cx23885_dvb_register() dvb_register failed err = -1 cx23885_dev_setup() Failed to register dvb on VID_C cx23885_dev_checkrevision() Hardware revision = 0xd0 cx23885[0]/0: found at :05:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xfbe0 cx23885 :05:00.0: setting latency timer to 64 cx23885 :05:00.0: irq 35 for MSI/MSI-X sorry I don’t know how can I do .. can you help me to fix the problem? Please ensure that all communication include the linux media mailing list. It looks like Hauppauge have released an updated HVR-1275 card, as indicated by the updated PCI-SubDevice ID 2A38. The hardware has changed and the driver needs to be modified to support these changes. Modprobing with option=19 isn't going to help. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] i.MX5/6 mem2mem scaler
Hi Fabio, Am Montag, den 13.07.2015, 09:57 -0300 schrieb Fabio Estevam: On Fri, Apr 10, 2015 at 11:41 AM, Kamil Debski k.deb...@samsung.com wrote: Hi, From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Philipp Zabel Sent: Tuesday, March 17, 2015 4:48 PM Hi, this series uses the IPU IC post-processing task, to implement a mem2mem device for scaling and colorspace conversion. This patchset makes changes in two subsystems - media and gpu. It would be good to merge these patchset through a single subsystem. The media part of this patchset is good, are there any comments to the gpu part of this patchset? I talked with Mauro on the IRC and he acked that this patchset could be merged via the gpu subsystem. Do you plan to resend this series? It is still not applied. Yes, thank you for the reminder. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Controller - graph_mutex
Hi Shuah, Shuah Khan wrote: All, ALSA has to make media_entity_pipeline_start() call in irq path. I am seeing warnings that the graph_mutex is unsafe irq lock as expected. We have to update MC start/stop pipeline to be irq safe for ALSA. Maybe there are other MC interfaces that need to be irq safe, but I haven't seen any problems with my limited testing. So as per options, graph_mutex could be changed to a spinlock. It looks like drivers hold this lock and it isn't abstracted to MC API. Unfortunate, this would require changes to drivers that directly hold the lock for graph walks if this mutex is changed to spinlock. e.g: drivers/media/platform/exynos4-is/fimc-isp-video.c Changes aren't complex, just that the scope isn't limited to MC API. Other ideas?? Do you have (preliminary?) patches and / or more information? I'd like to understand why would ALSA need this. The graph_mutex is currently also taken when the link state is modified, and the callbacks to the drivers may involve power state changes and device initialisation. On some busses such as I2C these are blocking operations. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Controller - graph_mutex
On 07/14/2015 08:06 AM, Sakari Ailus wrote: Hi Shuah, Shuah Khan wrote: All, ALSA has to make media_entity_pipeline_start() call in irq path. I am seeing warnings that the graph_mutex is unsafe irq lock as expected. We have to update MC start/stop pipeline to be irq safe for ALSA. Maybe there are other MC interfaces that need to be irq safe, but I haven't seen any problems with my limited testing. So as per options, graph_mutex could be changed to a spinlock. It looks like drivers hold this lock and it isn't abstracted to MC API. Unfortunate, this would require changes to drivers that directly hold the lock for graph walks if this mutex is changed to spinlock. e.g: drivers/media/platform/exynos4-is/fimc-isp-video.c Changes aren't complex, just that the scope isn't limited to MC API. Other ideas?? Do you have (preliminary?) patches and / or more information? I'd like to understand why would ALSA need this. The graph_mutex is currently also taken when the link state is modified, and the callbacks to the drivers may involve power state changes and device initialisation. On some busses such as I2C these are blocking operations. I am getting close to sending the RFC patches for review. I am looking at one last issue in addition to this mutex problem. I have dmesg logs to send and I will send them when I send the patches, so you have code to look at as well as the dmesg. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l2-subdev: return -EPIPE instead of -EINVAL in link validate default
On 07/13/15 10:03, Sakari Ailus wrote: Hi Helen, Helen Fornazier wrote: Hi, On Tue, Jun 30, 2015 at 4:26 PM, Helen Fornazier helen.fornaz...@gmail.com wrote: Hi Sakari and Laurent, Thanks for reviewing this On Tue, Jun 30, 2015 at 6:19 AM, Sakari Ailus sakari.ai...@linux.intel.com wrote: Hi Laurent, Laurent Pinchart wrote: Hi Sakari, On Monday 29 June 2015 10:23:34 Sakari Ailus wrote: Helen Fornazier wrote: According to the V4L2 API, the VIDIOC_STREAMON ioctl should return EPIPE when the pipeline configuration is invalid. As the .vidioc_streamon in the v4l2_ioctl_ops usually forwards the error caused by the v4l2_subdev_link_validate_default (if it is in use), it should return -EPIPE if it detects a format mismatch in the pipeline configuration Only link configuration errors have yielded -EPIPE so far, sub-device format configuration error has returned -INVAL instead as you noticed. It should also be noted that while v4l2_subdev_link_validate() will return - EINVAL in case of error, the only driver that performs custom link validation (omap3isp/ispccdc.c) will return -EPIPE. Good point. That has escaped me until now. There are not many sources of -EINVAL while enabling streaming and all others are directly caused by the application; I lean towards thinking the code is good as it was. The documentation could be improved though. It may not be clear which error codes could be caused by different conditions. The debug level messages from media module (drivers/media/media-entity.c) do provide more information if needed, albeit this certainly is not an application interface. I wonder what others think. There's a discrepancy between the implementation and the documentation, so at least one of them need to be fixed. -EPIPE would be coherent with the documentation and seems appropriately named, but another error code would allow userspace to tell link configuration and format configuration problems apart. That was the original intent, I think. Do you think -EINVAL is the most appropriate error code for format configuration ? It's already used to indicate that the stream type is invalid or that not enough buffers have been allocated, and is also used by drivers directly for various purposes. That's true, it's been used also for that purpose. At the time this certainly was not the primary concern. If you can think of a better error code for the purpose (than EINVAL) I'm certainly fine with using one. I still think that -EPIPE is worse for telling about incorrect format configuration than -EINVAL since it's relatively easy to avoid -EINVAL for the documented reasons. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com I'd like just to point out where in the docs EPIPE for format mismatch is specified, as it is not described in the streamon page as I thought it would, but it is in the subdev page in case anyone is looking for it (as I took some time to find it too): http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html Applications are responsible for configuring coherent parameters on the whole pipeline and making sure that connected pads have compatible formats. The pipeline is checked for formats mismatch at VIDIOC_STREAMON time, and an EPIPE error code is then returned if the configuration is invalid So maybe the doc should be improved as you already stated. -- Helen Fornazier I would like to revive this subject. Should we change the docs? Change the -EINVAL to -EPIPE, or create another error code? What are your opinion? I read in the docs of dev-kmsg that EPIPE is returned when messages get overwritten, and in other parts of the code EPIPE is returned when there is an error in the pipeline communication level while trying to send information through the pipe or a pipe broken error. But in the error-codes.txt files, the EPIPE error is defined as: *EPIPE The pipe type specified in the URB doesn't match the endpoint's actual type* This exact definition sound USB specific to me. Then, if EPIPE is used when types don't match between two endpoints, it seems reasonable to me to use EPIPE when formats don't match either. Or do types in this context have a specific definition? I don't know much about URB, you may be able to judge this better. A short recap of the current situation as far as I understand it: - MC link validation failure yields EPIPE to the user space, - V4L2 sub-device format validation failure generally results in EINVAL, except that I think that returning EINVAL here is wrong. EINVAL is returned when you set e.g. a format and the format is invalid. In this case the format for each subdev is perfectly fine, it's just that the sink and source formats do not match. Rather than returning EINVAL I think ENOLINK would work well here as you can't setup a link between two entities. And EPIPE can still be used for other higher-level pipeline errors. - omap3isp CCDC
Re: tw5864 driver development, help needed
An update with a request for help. Asking for help with h264 headers generation. Both copying headers from similar videos and porting headers generation code from reference driver don't work for me (ref driver is weird and very complicated, so porting involved importing of lots of code, but still in my case the generated header differs from the one produced by reference driver, and resulting files are not decodable). Wireshark seems not able to dissect raw h264 files, so that I could compare headers bitfield-wise. I have dumped 64 first encoded frames as they appear from hardware, so that you could look at it. This is archive: http://lizard.bluecherry.net/~autkin/vlc.tar.gz and this is contents list of archive http://lizard.bluecherry.net/~autkin/vlc.contents Only one camera is attached to this multi-channel video grabber and encoder, and i don't know which chip has it (4, 5, 6 or 7). The produced frames should have the same settings as this file: http://lizard.bluecherry.net/~autkin/test_main.h264 This is PAL D1, 720x576. Thanks in advance for any help. At last, the ability to look at visualization of those h264 streams would be great. -- Bluecherry developer. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l2-subdev: return -EPIPE instead of -EINVAL in link validate default
Hi Hans, On Tuesday 14 July 2015 16:19:50 Hans Verkuil wrote: On 07/13/15 10:03, Sakari Ailus wrote: Helen Fornazier wrote: On Tue, Jun 30, 2015 at 4:26 PM, Helen Fornazier wrote: On Tue, Jun 30, 2015 at 6:19 AM, Sakari Ailus wrote: Laurent Pinchart wrote: On Monday 29 June 2015 10:23:34 Sakari Ailus wrote: Helen Fornazier wrote: According to the V4L2 API, the VIDIOC_STREAMON ioctl should return EPIPE when the pipeline configuration is invalid. As the .vidioc_streamon in the v4l2_ioctl_ops usually forwards the error caused by the v4l2_subdev_link_validate_default (if it is in use), it should return -EPIPE if it detects a format mismatch in the pipeline configuration Only link configuration errors have yielded -EPIPE so far, sub-device format configuration error has returned -INVAL instead as you noticed. It should also be noted that while v4l2_subdev_link_validate() will return - EINVAL in case of error, the only driver that performs custom link validation (omap3isp/ispccdc.c) will return -EPIPE. Good point. That has escaped me until now. There are not many sources of -EINVAL while enabling streaming and all others are directly caused by the application; I lean towards thinking the code is good as it was. The documentation could be improved though. It may not be clear which error codes could be caused by different conditions. The debug level messages from media module (drivers/media/media-entity.c) do provide more information if needed, albeit this certainly is not an application interface. I wonder what others think. There's a discrepancy between the implementation and the documentation, so at least one of them need to be fixed. -EPIPE would be coherent with the documentation and seems appropriately named, but another error code would allow userspace to tell link configuration and format configuration problems apart. That was the original intent, I think. Do you think -EINVAL is the most appropriate error code for format configuration ? It's already used to indicate that the stream type is invalid or that not enough buffers have been allocated, and is also used by drivers directly for various purposes. That's true, it's been used also for that purpose. At the time this certainly was not the primary concern. If you can think of a better error code for the purpose (than EINVAL) I'm certainly fine with using one. I still think that -EPIPE is worse for telling about incorrect format configuration than -EINVAL since it's relatively easy to avoid - EINVAL for the documented reasons. I'd like just to point out where in the docs EPIPE for format mismatch is specified, as it is not described in the streamon page as I thought it would, but it is in the subdev page in case anyone is looking for it (as I took some time to find it too): http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html Applications are responsible for configuring coherent parameters on the whole pipeline and making sure that connected pads have compatible formats. The pipeline is checked for formats mismatch at VIDIOC_STREAMON time, and an EPIPE error code is then returned if the configuration is invalid So maybe the doc should be improved as you already stated. I would like to revive this subject. Should we change the docs? Change the -EINVAL to -EPIPE, or create another error code? What are your opinion? I read in the docs of dev-kmsg that EPIPE is returned when messages get overwritten, and in other parts of the code EPIPE is returned when there is an error in the pipeline communication level while trying to send information through the pipe or a pipe broken error. But in the error-codes.txt files, the EPIPE error is defined as: *EPIPE The pipe type specified in the URB doesn't match the endpoint's actual type* This exact definition sound USB specific to me. Then, if EPIPE is used when types don't match between two endpoints, it seems reasonable to me to use EPIPE when formats don't match either. Or do types in this context have a specific definition? I don't know much about URB, you may be able to judge this better. A short recap of the current situation as far as I understand it: - MC link validation failure yields EPIPE to the user space, - V4L2 sub-device format validation failure generally results in EINVAL, except that I think that returning EINVAL here is wrong. EINVAL is returned when you set e.g. a format and the format is invalid. In this case the format for each subdev is perfectly fine, it's just that the sink and source formats do not match. Rather than returning EINVAL I think ENOLINK would work well here as you can't setup a link between two entities. And EPIPE can still be used for other higher-level pipeline errors. - omap3isp CCDC driver returns EPIPE instead and
Re: [PATCH] Doc: pps: Fix file name in pps.txt
On Mon, 13 Jul 2015 12:29:11 +0900 Masanari Iida standby2...@gmail.com wrote: This patch fix a file name of example code. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] media: Add ALSA Media Controller devnodes
Add ALSA Media Controller capture, playback, and mixer
devnode defines.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
include/uapi/linux/media.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4e816be..4a30ea3 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -49,12 +49,17 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE(1 MEDIA_ENT_TYPE_SHIFT)
#define MEDIA_ENT_T_DEVNODE_V4L(MEDIA_ENT_T_DEVNODE + 1)
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
+/* Legacy ALSA symbol. Keep it to avoid userspace compilation breakages */
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
#define MEDIA_ENT_T_DEVNODE_DVB_DVR(MEDIA_ENT_T_DEVNODE + 6)
#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
#define MEDIA_ENT_T_DEVNODE_DVB_NET(MEDIA_ENT_T_DEVNODE + 8)
+/* ALSA devnodes */
+#define MEDIA_ENT_T_DEVNODE_ALSA_CAPTURE (MEDIA_ENT_T_DEVNODE + 9)
+#define MEDIA_ENT_T_DEVNODE_ALSA_PLAYBACK (MEDIA_ENT_T_DEVNODE + 10)
+#define MEDIA_ENT_T_DEVNODE_ALSA_MIXER (MEDIA_ENT_T_DEVNODE + 11)
/* Legacy symbol. Use it to avoid userspace compilation breakages */
#define MEDIA_ENT_T_DEVNODE_DVBMEDIA_ENT_T_DEVNODE_DVB_FE
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] media: au8522 change to create MC pad for ALSA Audio Out
Add new pad for ALSA Audio Out to au8522_media_pads. Move the
au8522_media_pads enum to au8522.h from au8522_priv.h. This will
allow au0828-core to use these defines instead of hard-coding the
pad values when it creates media graph linking decode pads to other
entities.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/dvb-frontends/au8522.h | 8
drivers/media/dvb-frontends/au8522_decoder.c | 1 +
drivers/media/dvb-frontends/au8522_priv.h| 8
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb-frontends/au8522.h
b/drivers/media/dvb-frontends/au8522.h
index dde6158..d7a997f 100644
--- a/drivers/media/dvb-frontends/au8522.h
+++ b/drivers/media/dvb-frontends/au8522.h
@@ -90,4 +90,12 @@ enum au8522_audio_input {
AU8522_AUDIO_SIF,
};
+enum au8522_media_pads {
+ AU8522_PAD_INPUT,
+ AU8522_PAD_VID_OUT,
+ AU8522_PAD_VBI_OUT,
+ AU8522_PAD_AUDIO_OUT,
+
+ AU8522_NUM_PADS
+};
#endif /* __AU8522_H__ */
diff --git a/drivers/media/dvb-frontends/au8522_decoder.c
b/drivers/media/dvb-frontends/au8522_decoder.c
index 24990db..01d8fe7 100644
--- a/drivers/media/dvb-frontends/au8522_decoder.c
+++ b/drivers/media/dvb-frontends/au8522_decoder.c
@@ -775,6 +775,7 @@ static int au8522_probe(struct i2c_client *client,
state-pads[AU8522_PAD_INPUT].flags = MEDIA_PAD_FL_SINK;
state-pads[AU8522_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
state-pads[AU8522_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
+ state-pads[AU8522_PAD_AUDIO_OUT].flags = MEDIA_PAD_FL_SINK;
sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
ret = media_entity_init(sd-entity, ARRAY_SIZE(state-pads),
diff --git a/drivers/media/dvb-frontends/au8522_priv.h
b/drivers/media/dvb-frontends/au8522_priv.h
index d6209d9..4c2a6ed 100644
--- a/drivers/media/dvb-frontends/au8522_priv.h
+++ b/drivers/media/dvb-frontends/au8522_priv.h
@@ -39,14 +39,6 @@
#define AU8522_DIGITAL_MODE 1
#define AU8522_SUSPEND_MODE 2
-enum au8522_media_pads {
- AU8522_PAD_INPUT,
- AU8522_PAD_VID_OUT,
- AU8522_PAD_VBI_OUT,
-
- AU8522_NUM_PADS
-};
-
struct au8522_state {
struct i2c_client *c;
struct i2c_adapter *i2c;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] sound/usb: Update ALSA driver to use Managed Media Controller API
Change ALSA driver to use Managed ~media Managed Controller
API to share tuner with DVB and V4L2 drivers that control
AU0828 media device. Media device is created based on a
newly added field value in the struct snd_usb_audio_quirk.
Using this approach, the media controller API usage can be
added for a specific device. In this patch, Media Controller
API is enabled for AU0828 hw. snd_usb_create_quirk() will
check this new field, if set will create a media device using
media_device_get_devres() interface.
media_device_get_devres() will allocate a new media device
devres or return an existing one, if it finds one.
During probe, media usb driver could have created the media
device devres. It will then register the media device if it
isn't already registered. Media device unregister is done from
usb_audio_disconnect().
During probe, media usb driver could have created the
media device devres. It will then register the media
device if it isn't already registered. Media device
unregister is done from usb_audio_disconnect().
New structure media_ctl is added to group the new
fields to support media entity and links. This new
structure is added to struct snd_usb_substream.
A new entity_notify hook and a new ALSA capture media
entity are registered from snd_usb_pcm_open() after
setting up hardware information for the PCM device.
When a new entity is registered, Media Controller API
interface media_device_register_entity() invokes all
registered entity_notify hooks for the media device.
ALSA entity_notify hook parses all the entity list to
find a link from decoder it ALSA entity. This indicates
that the bridge driver created a link from decoder to
ALSA capture entity. At this time, ALSA will attempt to
enable the tuner to link the tuner to the decoder calling
media_entity_setup_link(). media_entity_setup_link() will
either return success activating tuner to decoder link or
error if it tuner is busy.
Media pipeline gets started to mark the tuner busy from
snd_usb_substream_capture_trigger() in response to
SNDRV_PCM_TRIGGER_START and pipeline is stopped in
response to SNDRV_PCM_TRIGGER_STOP. snd_usb_pcm_close()
stops pipeline to cover the case when SNDRV_PCM_TRIGGER_STOP
isn't issued. Pipeline start and stop are done only when
decoder_linked is set. Tuner enable step could be done
from snd_usb_substream_capture_trigger(). The reason it
is done from snd_usb_pcm_open() is that it reduces the
work that is needed from snd_usb_substream_capture_trigger().
There is an open issue with graph_mutex hold in Media Controller
media_entity_pipeline_start() and media_entity_pipeline_stop()
API. snd-us-audio calls these from snd_usb_substream_capture_trigger()
which could be called in irq path. This issue needs to be resolved
before this patch can go in.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
sound/usb/Makefile | 15 ++-
sound/usb/card.c | 5 +
sound/usb/card.h | 1 +
sound/usb/media.c| 260 +++
sound/usb/media.h| 52 ++
sound/usb/pcm.c | 15 ++-
sound/usb/quirks-table.h | 1 +
sound/usb/quirks.c | 9 +-
sound/usb/stream.c | 2 +
sound/usb/usbaudio.h | 1 +
10 files changed, 357 insertions(+), 4 deletions(-)
create mode 100644 sound/usb/media.c
create mode 100644 sound/usb/media.h
diff --git a/sound/usb/Makefile b/sound/usb/Makefile
index 2d2d122..665fdd9 100644
--- a/sound/usb/Makefile
+++ b/sound/usb/Makefile
@@ -2,6 +2,18 @@
# Makefile for ALSA
#
+# Media Controller
+ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
+ ifeq ($(CONFIG_MEDIA_SUPPORT),y)
+KBUILD_CFLAGS += -DUSE_MEDIA_CONTROLLER
+ endif
+ ifeq ($(CONFIG_MEDIA_SUPPORT_MODULE),y)
+ifeq ($(MODULE),y)
+ KBUILD_CFLAGS += -DUSE_MEDIA_CONTROLLER
+endif
+ endif
+endif
+
snd-usb-audio-objs := card.o \
clock.o \
endpoint.o \
@@ -13,7 +25,8 @@ snd-usb-audio-objs := card.o \
pcm.o \
proc.o \
quirks.o \
- stream.o
+ stream.o \
+ media.o
snd-usbmidi-lib-objs := midi.o
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 1fab977..469d2bf 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -66,6 +66,7 @@
#include format.h
#include power.h
#include stream.h
+#include media.h
MODULE_AUTHOR(Takashi Iwai ti...@suse.de);
MODULE_DESCRIPTION(USB Audio);
@@ -619,6 +620,10 @@ static void usb_audio_disconnect(struct usb_interface
*intf)
list_for_each_entry(mixer, chip-mixer_list, list) {
snd_usb_mixer_disconnect(mixer);
}
+ /* Nice to check quirk quirk-media_device
+* need some special handlings. Doesn't look like
+* we have access to quirk here */
+ media_device_delete(intf);
}
[PATCH] media-ctl: Update to add support for ALSA devices
Add support to recognize ALSA media nodes and generate
media graph that includes ALSA pcm and mixer devices.
This patch depends on kernel Media Controller changes
to support ALSA.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
utils/media-ctl/libmediactl.c | 18 --
utils/media-ctl/media-ctl.c | 3 +++
utils/media-ctl/mediactl.h| 4 +++-
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index dce8eeb..329a41a 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -153,7 +153,9 @@ struct media_entity *media_get_default_entity(struct
media_device *media,
return media-def.v4l;
case MEDIA_ENT_T_DEVNODE_FB:
return media-def.fb;
- case MEDIA_ENT_T_DEVNODE_ALSA:
+ case MEDIA_ENT_T_DEVNODE_ALSA_CAPTURE:
+ case MEDIA_ENT_T_DEVNODE_ALSA_PLAYBACK:
+ case MEDIA_ENT_T_DEVNODE_ALSA_MIXER:
return media-def.alsa;
case MEDIA_ENT_T_DEVNODE_DVB_FE:
case MEDIA_ENT_T_DEVNODE_DVB_DEMUX:
@@ -481,7 +483,6 @@ static int media_get_devname_sysfs(struct media_entity
*entity)
if (p == NULL)
return -EINVAL;
- sprintf(devname, /dev/%s, p + 1);
if (strstr(p + 1, dvb)) {
char *s = p + 1;
@@ -493,6 +494,8 @@ static int media_get_devname_sysfs(struct media_entity
*entity)
return -EINVAL;
*p = '/';
sprintf(devname, /dev/dvb/adapter%s, s);
+ } else if (strstr(p + 1, pcm) || strstr(p + 1, control)) {
+ sprintf(devname, /dev/snd/%s, p + 1);
} else {
sprintf(devname, /dev/%s, p + 1);
}
@@ -562,7 +565,9 @@ static int media_enum_entities(struct media_device *media)
case MEDIA_ENT_T_DEVNODE_FB:
media-def.fb = entity;
break;
- case MEDIA_ENT_T_DEVNODE_ALSA:
+ case MEDIA_ENT_T_DEVNODE_ALSA_CAPTURE:
+ case MEDIA_ENT_T_DEVNODE_ALSA_PLAYBACK:
+ case MEDIA_ENT_T_DEVNODE_ALSA_MIXER:
media-def.alsa = entity;
break;
case MEDIA_ENT_T_DEVNODE_DVB_FE:
@@ -577,8 +582,7 @@ static int media_enum_entities(struct media_device *media)
/* Find the corresponding device name. */
if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE
- media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV
- entity-info.type == MEDIA_ENT_T_DEVNODE_ALSA)
+ media_entity_type(entity) != MEDIA_ENT_T_V4L2_SUBDEV)
continue;
/* Try to get the device name via udev */
@@ -774,7 +778,9 @@ int media_device_add_entity(struct media_device *media,
defent = media-def.fb;
entity-info.fb = desc-fb;
break;
- case MEDIA_ENT_T_DEVNODE_ALSA:
+ case MEDIA_ENT_T_DEVNODE_ALSA_CAPTURE:
+ case MEDIA_ENT_T_DEVNODE_ALSA_PLAYBACK:
+ case MEDIA_ENT_T_DEVNODE_ALSA_MIXER:
defent = media-def.alsa;
entity-info.alsa = desc-alsa;
break;
diff --git a/utils/media-ctl/media-ctl.c b/utils/media-ctl/media-ctl.c
index 602486f..85151b5 100644
--- a/utils/media-ctl/media-ctl.c
+++ b/utils/media-ctl/media-ctl.c
@@ -290,6 +290,9 @@ static const char *media_entity_subtype_to_string(unsigned
type)
DVB DVR,
DVB CA,
DVB NET,
+ ALSA CAPTURE,
+ ALSA PLAYBACK,
+ ALSA MIXER,
};
static const char *subdev_types[] = {
Unknown,
diff --git a/utils/media-ctl/mediactl.h b/utils/media-ctl/mediactl.h
index 03d9f70..3ac91eb 100644
--- a/utils/media-ctl/mediactl.h
+++ b/utils/media-ctl/mediactl.h
@@ -305,7 +305,9 @@ struct media_entity *media_get_entity(struct media_device
*media, unsigned int i
*
* MEDIA_ENT_T_DEVNODE_V4L
* MEDIA_ENT_T_DEVNODE_FB
- * MEDIA_ENT_T_DEVNODE_ALSA
+ * MEDIA_ENT_T_DEVNODE_ALSA_CAPTURE
+ * MEDIA_ENT_T_DEVNODE_ALSA_PLAYBACK
+ * MEDIA_ENT_T_DEVNODE_ALSA_MIXER
* MEDIA_ENT_T_DEVNODE_DVB_FE
* MEDIA_ENT_T_DEVNODE_DVB_DEMUX
* MEDIA_ENT_T_DEVNODE_DVB_DVR
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Update ALSA, and au0828 drivers to use Managed Media Controller API
s patch series updates ALSA driver, and au0828 core driver to use Managed Media controller API to share tuner. Please note that Managed Media Controller API and DVB and V4L2 drivers updates to use Media Controller API have been added in a prior patch series. Media Controller API is enhanced with two new interfaces to register and unregister entity_notify hooks to allow drivers to take appropriate actions when as new entities get added to the shared media device. Tested exclusion between digital, analog, and audio to ensure when tuner has an active link to DVB FE, analog, and audio will detect and honor the tuner busy conditions and vice versa. This patch series has been updated to address comments from 3 previous versions of this series. Link to v3 below for reference. https://www.mail-archive.com/linux-media%40vger.kernel.org/msg89491.html https://www.mail-archive.com/linux-media@vger.kernel.org/msg89492.html https://www.mail-archive.com/linux-media%40vger.kernel.org/msg89493.html Open Issues: ALSA has makes media_entity_pipeline_start() call in irq path. I am seeing warnings that the graph_mutex is unsafe irq lock. Media Controller API updates to start/stop pipeline to be irq safe might be necessary. Maybe there are other MC interfaces that need to be irq safe, but I haven't seen any problems with my testing. So as per options, graph_mutex could be changed to a spinlock. It looks like drivers hold this lock and it isn't abstracted to MC API. Unfortunate, this would require changes to drivers that directly hold the lock for graph walks if this mutex is changed to spinlock. This issue needs to be resolved. Note: This series includes a revert to a patch that added media controller entity framework enhancements that implemented entity ops for entity_notify functionality. Entity ops for entity_notify doesn't handle and cover entity create ordering variations that could occur during boot. entity_notify list has been moved to media device level which makes the entity_notify calls to work correctly. Shuah Khan (7): Revert [media] media: media controller entity framework enhancements for ALSA media: Media Controller register/unregister entity_notify API media: Add ALSA Media Controller devnodes media: change dvb-frontend to honor MC tuner enable error media: au8522 change to create MC pad for ALSA Audio Out media: au0828 change to use Managed Media Controller API sound/usb: Update ALSA driver to use Managed Media Controller API drivers/media/dvb-core/dvb_frontend.c| 5 +- drivers/media/dvb-frontends/au8522.h | 8 + drivers/media/dvb-frontends/au8522_decoder.c | 1 + drivers/media/dvb-frontends/au8522_priv.h| 8 - drivers/media/media-device.c | 46 - drivers/media/usb/au0828/au0828-core.c | 132 -- drivers/media/usb/au0828/au0828.h| 5 + include/media/media-device.h | 23 +++ include/media/media-entity.h | 4 - include/uapi/linux/media.h | 5 + sound/usb/Makefile | 15 +- sound/usb/card.c | 5 + sound/usb/card.h | 1 + sound/usb/media.c| 260 +++ sound/usb/media.h| 52 ++ sound/usb/pcm.c | 15 +- sound/usb/quirks-table.h | 1 + sound/usb/quirks.c | 9 +- sound/usb/stream.c | 2 + sound/usb/usbaudio.h | 1 + 20 files changed, 523 insertions(+), 75 deletions(-) create mode 100644 sound/usb/media.c create mode 100644 sound/usb/media.h -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] media: Media Controller register/unregister entity_notify API
Add new interfaces to register and unregister entity_notify
hook to media device to allow drivers to take appropriate
actions when as new entities get added to the shared media
device.When a new entity is registered, all registered
entity_notify hooks are invoked to allow drivers or modules
that registered hook to take appropriate action. For example,
ALSA driver registers an entity_notify hook to parse the list
of registered entities to determine if decoder has been linked
to ALSA entity. au0828 bridge driver registers an entity_notify
hook to create media graph for the device.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/media-device.c | 45
include/media/media-device.h | 23 ++
2 files changed, 68 insertions(+)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index c55ab50..22565a8 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -381,6 +381,7 @@ int __must_check __media_device_register(struct
media_device *mdev,
mdev-entity_id = 1;
INIT_LIST_HEAD(mdev-entities);
+ INIT_LIST_HEAD(mdev-entity_notify);
spin_lock_init(mdev-lock);
mutex_init(mdev-graph_mutex);
@@ -411,9 +412,12 @@ void media_device_unregister(struct media_device *mdev)
{
struct media_entity *entity;
struct media_entity *next;
+ struct media_entity_notify *notify, *nextp;
list_for_each_entry_safe(entity, next, mdev-entities, list)
media_device_unregister_entity(entity);
+ list_for_each_entry_safe(notify, nextp, mdev-entity_notify, list)
+ media_device_unregister_entity_notify(mdev, notify);
device_remove_file(mdev-devnode.dev, dev_attr_model);
media_devnode_unregister(mdev-devnode);
@@ -421,6 +425,39 @@ void media_device_unregister(struct media_device *mdev)
EXPORT_SYMBOL_GPL(media_device_unregister);
/**
+ * media_device_register_entity_notify - Register a media entity notify
+ * callback with a media device. When a new entity is registered, all
+ * the registered media_entity_notify callbacks are invoked.
+ * @mdev: The media device
+ * @nptr: The media_entity_notify
+ */
+int __must_check media_device_register_entity_notify(struct media_device *mdev,
+ struct media_entity_notify *nptr)
+{
+ spin_lock(mdev-lock);
+ list_add_tail(nptr-list, mdev-entity_notify);
+ spin_unlock(mdev-lock);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(media_device_register_entity_notify);
+
+/**
+ * media_device_unregister_entity_notify - Unregister a media entity notify
+ * callback with a media device. When a new entity is registered, all
+ * the registered media_entity_notify callbacks are invoked.
+ * @mdev: The media device
+ * @nptr: The media_entity_notify
+ */
+void media_device_unregister_entity_notify(struct media_device *mdev,
+ struct media_entity_notify *nptr)
+{
+ spin_lock(mdev-lock);
+ list_del(nptr-list);
+ spin_unlock(mdev-lock);
+}
+EXPORT_SYMBOL_GPL(media_device_unregister_entity_notify);
+
+/**
* media_device_register_entity - Register an entity with a media device
* @mdev: The media device
* @entity:The entity
@@ -428,6 +465,8 @@ EXPORT_SYMBOL_GPL(media_device_unregister);
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity)
{
+ struct media_entity_notify *notify, *next;
+
/* Warn if we apparently re-register an entity */
WARN_ON(entity-parent != NULL);
entity-parent = mdev;
@@ -440,6 +479,11 @@ int __must_check media_device_register_entity(struct
media_device *mdev,
list_add_tail(entity-list, mdev-entities);
spin_unlock(mdev-lock);
+ /* invoke entity_notify callbacks */
+ list_for_each_entry_safe(notify, next, mdev-entity_notify, list) {
+ (notify)-notify(entity, notify-notify_data);
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(media_device_register_entity);
@@ -462,6 +506,7 @@ void media_device_unregister_entity(struct media_entity
*entity)
list_del(entity-list);
spin_unlock(mdev-lock);
entity-parent = NULL;
+ /* invoke entity_notify callbacks to handle entity removal?? */
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index a44f18f..a3854f6 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -32,6 +32,12 @@
struct device;
+struct media_entity_notify {
+ struct list_head list;
+ void *notify_data;
+ void (*notify)(struct media_entity *entity, void *notify_data);
+};
+
/**
* struct media_device - Media device
* @dev: Parent device
@@ -70,6 +76,8 @@ struct media_device {
[PATCH 4/7] media: change dvb-frontend to honor MC tuner enable error
Change dvb_frontend_thread() to honor MC tuner enable error and
return as opposed to ignoring the error and continuing to use it.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/dvb-core/dvb_frontend.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 842b9c8..5a86211 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -713,9 +713,8 @@ static int dvb_frontend_thread(void *data)
#ifdef CONFIG_MEDIA_CONTROLLER_DVB
ret = dvb_enable_media_tuner(fe);
if (ret) {
- /* FIXME: return an error if it fails */
- dev_info(fe-dvb-device,
- proceeding with FE task\n);
+ dev_err(fe-dvb-device, Tuner is busy. Error %d\n, ret);
+ return ret;
} else if (fepriv-pipe_start_entity) {
ret = media_entity_pipeline_start(fepriv-pipe_start_entity,
fepriv-pipe);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] Revert [media] media: media controller entity framework enhancements for ALSA
This reverts commit ed64cf1e182fb30fe67652386c0880fcf3302f97.
This patch is no longer necessary as the entity register
callback is implemented at media_device level.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/media-device.c | 7 ---
include/media/media-entity.h | 4
2 files changed, 11 deletions(-)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 76590ba..c55ab50 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -428,8 +428,6 @@ EXPORT_SYMBOL_GPL(media_device_unregister);
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity)
{
- struct media_entity *eptr;
-
/* Warn if we apparently re-register an entity */
WARN_ON(entity-parent != NULL);
entity-parent = mdev;
@@ -442,11 +440,6 @@ int __must_check media_device_register_entity(struct
media_device *mdev,
list_add_tail(entity-list, mdev-entities);
spin_unlock(mdev-lock);
- media_device_for_each_entity(eptr, mdev) {
- if (eptr != entity)
- media_entity_call(eptr, register_notify);
- }
-
return 0;
}
EXPORT_SYMBOL_GPL(media_device_register_entity);
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 0bc4c2f..0c003d8 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -46,7 +46,6 @@ struct media_pad {
/**
* struct media_entity_operations - Media entity operations
- * @register_notifyNotify entity of newly registered entity
* @link_setup:Notify the entity of link changes. The
operation can
* return an error, in which case link setup will be
* cancelled. Optional.
@@ -55,7 +54,6 @@ struct media_pad {
* validates all links by calling this operation. Optional.
*/
struct media_entity_operations {
- int (*register_notify)(struct media_entity *entity);
int (*link_setup)(struct media_entity *entity,
const struct media_pad *local,
const struct media_pad *remote, u32 flags);
@@ -103,8 +101,6 @@ struct media_entity {
/* Sub-device specifications */
/* Nothing needed yet */
} info;
-
- void *private; /* private data for the entity */
};
static inline u32 media_entity_type(struct media_entity *entity)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiler warning from drivers/media/usb/au0828/au0828-video.c: In function ‘queue_setup’
On 06/23/2015 09:05 PM, Shuah Khan wrote: Hi Mauro, I am seeing the following warning from au0828 - linux_media media_controller branch: drivers/media/usb/au0828/au0828-video.c: In function ‘queue_setup’: drivers/media/usb/au0828/au0828-video.c:679:6: warning: ‘entity’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (sink == entity) ^ drivers/media/usb/au0828/au0828-video.c:644:24: note: ‘entity’ was declared here struct media_entity *entity, *source; ^ This looks real to me, but don't know what entity should have been initialized to. Hi Mauro, I don't your patch that fixes this issue in the media-controller branch. Are you planning to get that in? thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] media: au0828 change to use Managed Media Controller API
Change au0828 to use Managed Media Controller API to coordinate
creating/deleting media device on parent usb device it shares
with the snd-usb-audio driver. With this change, au0828 uses
media_device_get_devres() to allocate a new media device devres
or return an existing one, if it finds one.
In addition, au0828 registers entity_notify hook to create media
graph for the device. It creates necessary links from video, vbi,
and ALSA entities to decoder and links tuner and decoder entities.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828-core.c | 132 -
drivers/media/usb/au0828/au0828.h | 5 ++
2 files changed, 85 insertions(+), 52 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index 0378a2c..492e910 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -20,6 +20,7 @@
*/
#include au0828.h
+#include au8522.h
#include linux/module.h
#include linux/slab.h
@@ -131,10 +132,12 @@ static void au0828_unregister_media_device(struct
au0828_dev *dev)
{
#ifdef CONFIG_MEDIA_CONTROLLER
- if (dev-media_dev) {
- media_device_unregister(dev-media_dev);
- kfree(dev-media_dev);
- dev-media_dev = NULL;
+ if (dev-media_dev
+ media_devnode_is_registered(dev-media_dev-devnode)) {
+ media_device_unregister_entity_notify(dev-media_dev,
+ dev-entity_notify);
+ media_device_unregister(dev-media_dev);
+ dev-media_dev = NULL;
}
#endif
}
@@ -196,53 +199,23 @@ static void au0828_usb_disconnect(struct usb_interface
*interface)
au0828_usb_release(dev);
}
-static void au0828_media_device_register(struct au0828_dev *dev,
- struct usb_device *udev)
-{
-#ifdef CONFIG_MEDIA_CONTROLLER
- struct media_device *mdev;
- int ret;
-
- mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
- if (!mdev)
- return;
-
- mdev-dev = udev-dev;
-
- if (!dev-board.name)
- strlcpy(mdev-model, unknown au0828, sizeof(mdev-model));
- else
- strlcpy(mdev-model, dev-board.name, sizeof(mdev-model));
- if (udev-serial)
- strlcpy(mdev-serial, udev-serial, sizeof(mdev-serial));
- strcpy(mdev-bus_info, udev-devpath);
- mdev-hw_revision = le16_to_cpu(udev-descriptor.bcdDevice);
- mdev-driver_version = LINUX_VERSION_CODE;
-
- ret = media_device_register(mdev);
- if (ret) {
- pr_err(
- Couldn't create a media device. Error: %d\n,
- ret);
- kfree(mdev);
- return;
- }
-
- dev-media_dev = mdev;
-#endif
-}
-
-
-static void au0828_create_media_graph(struct au0828_dev *dev)
+void au0828_create_media_graph(struct media_entity *new, void *notify_data)
{
#ifdef CONFIG_MEDIA_CONTROLLER
+ struct au0828_dev *dev = (struct au0828_dev *) notify_data;
struct media_device *mdev = dev-media_dev;
struct media_entity *entity;
struct media_entity *tuner = NULL, *decoder = NULL;
+ struct media_entity *alsa_capture = NULL;
+ int ret = 0;
if (!mdev)
return;
+ if (dev-tuner_linked dev-vdev_linked dev-vbi_linked
+ dev-alsa_capture_linked)
+ return;
+
media_device_for_each_entity(entity, mdev) {
switch (entity-type) {
case MEDIA_ENT_T_V4L2_SUBDEV_TUNER:
@@ -251,6 +224,9 @@ static void au0828_create_media_graph(struct au0828_dev
*dev)
case MEDIA_ENT_T_V4L2_SUBDEV_DECODER:
decoder = entity;
break;
+ case MEDIA_ENT_T_DEVNODE_ALSA_CAPTURE:
+ alsa_capture = entity;
+ break;
}
}
@@ -259,15 +235,69 @@ static void au0828_create_media_graph(struct au0828_dev
*dev)
if (!decoder)
return;
- if (tuner)
- media_entity_create_link(tuner, 0, decoder, 0,
+ if (tuner !dev-tuner_linked) {
+ ret = media_entity_create_link(tuner, 0, decoder, 0,
MEDIA_LNK_FL_ENABLED);
- if (dev-vdev.entity.links)
- media_entity_create_link(decoder, 1, dev-vdev.entity, 0,
-MEDIA_LNK_FL_ENABLED);
- if (dev-vbi_dev.entity.links)
- media_entity_create_link(decoder, 2, dev-vbi_dev.entity, 0,
-MEDIA_LNK_FL_ENABLED);
+ if (ret == 0)
+ dev-tuner_linked = 1;
+ }
+ if (dev-vdev.entity.links !dev-vdev_linked) {
+ ret =
RE: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem
Dear : Steven Toth Thanks for your professional answer Thanks a lot Best Regards -Original Message- From: Steven Toth [mailto:st...@kernellabs.com] Sent: Tuesday, July 14, 2015 8:56 PM To: to...@wincomm.com.tw Cc: Linux-Media Subject: Re: www.kernellabs.com Contact: Hauppauge hvr1275 TV Tuner card linux problem sorry I don't know how can I do .. can you help me to fix the problem? Please ensure that all communication include the linux media mailing list. It looks like Hauppauge have released an updated HVR-1275 card, as indicated by the updated PCI-SubDevice ID 2A38. The hardware has changed and the driver needs to be modified to support these changes. Modprobing with option=19 isn't going to help. I've reached out to Hauppauge for comment on the new H/W. Stay tuned. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 Jul 15 04:00:15 CEST 2015 git branch: test git hash: 8783b9c50400c6279d7c3b716637b98e83d3c933 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS 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/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: file permissions for a video device
Never mind, it worked after adding the following entry into ueventd.rc. #camera /dev/video* 0660 system camera On Mon, Jul 13, 2015 at 8:51 PM, karthik poduval karthik.podu...@gmail.com wrote: Hi All, I was working with a USB camera. As soon as I plug it into the host, it probes and video device node gets created with the following permission. # ll /dev/video0 crw--- root root 81, 0 2015-07-13 20:39 video0 However it grants permissions to only a root user. I need to be able to access this device node from a daemon (running in a non root user account). I can ofcourse chmod the devnode, but was wondering if there is a way this can be done from the kernel itself ? Is there some place in the uvc code which sets the created the devnode file permissions ? -- Regards, Karthik Poduval -- Regards, Karthik Poduval -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] DocBook: Fix typo in intro.xml
On Tue, 14 Jul 2015 08:36:50 +0900 Masanari Iida standby2...@gmail.com wrote: This patch fix spelling typos in intro.xml. This xml file is not created from comments within source, I fix the xml file. Applied to the docs tree, thanks. jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
