RE: [BUG] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used
Hi dCrypt, I'm not a developer at all. I'm not even sure why I read this list, but can you determine if the problem is associated with a particular kernel version? i.e. if it works on x.y.z but fails on x.y.(z+1) you have a starting point. If you use the word regression and a kernel version number you might get more attention - but I'm only guessing. Good luck, blind Pete dCrypt wrote: Hi again, I'm sorry if I sound quite rude, but I'm not sure if I am doing it right or not. I subscribed to this mailing list in order to ask for help, or to help with a bug that I've found (as instructed in the wiki http://linuxtv.org/wiki/index.php/Bug_Report), but it seems to me that the mailing list is filled up with developing messages. I don't want to participate in the development, I am a developer but I don't have the skills nor the knowledge. If this is not the right place to direct my questions, I would appreciate some advice. Thank you very much, and best regards. -Mensaje original- De: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] En nombre de dCrypt Enviado el: jueves, 01 de enero de 2015 22:04 Para: linux-media@vger.kernel.org Asunto: [BUG] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used Hi, I just subscribed to the mailing list to submit information on the bug which is driving me crazy since one month ago. I have a VDR based PVR at home, installed over an Ubuntu 14.04 LTS. Everything was working perfectly, until beginning of December. It seems to me that something changed that broke my PVR pretty bad. The problem is the following: tuning (zap) both tuners (it's not needed that both are tuned simultaneously, only one after the other, in no particular order) makes the tuners to enter an state where they can't lock the signal anymore. Facts: - My TV card is a Cinergy T PCIe Dual from Terratec (http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_PCIe_dual). - The problem arose in the form of frontend x/0 timed out while tuning to channel ... in /var/log/syslog. It happened when both tuners are active, during EPG scan. The problem does not happen if VDR is run with -D parameter to limit the number of frontends enabled. Disabling the EPG scan with both frontends enabled minimizes the problem, but doesn't solve it because tuning both frontends without any EPG scan makes the error happen again. - I initially thought about a problem in the DVB-T signal, because it all started the 1st of December, during the transition to a new set of frequencies in Spain. - Everything was working perfectly before the 1st, and the problems started suddenly. - I setup testing board for debugging, different board and processor, less memory, lots of Linux distros tested, Windows tested as well. - Both tuners works in windows without problems. Confirmed. - I have completely discarded problems/errors in hardware (because in Windows I can enable both tuners without problems) and VDR (because I can reproduce the problems at OS level, without even having VDR installed). - I have almost narrowed the problem at the cx23885 driver, because when it happens, I can restart the TV card to working conditions by executing rmmod cx23885 and modprobe cx23885; however, as with rmmod several dependencies are unloaded as well, I am stuck and I am unable to go on with debugging to find out where the problem really is. - Tools used to test and confirm the problem are: VDR, MythTV, TVHeadend, dvbscan, dvbv5-scan, dvbv5-zap and others - Linux distros tested: Ubuntu, Fedora, Suse, yaVDR (not sure if the card worked at all), MythBuntu (dvb-fe-tool -a 1 -c DVBT was required to force DVB-T mode for the second tuner), and probably others - I have a Sony PlayTV also with dual tuners, which works without any problem. http://www.linuxtv.org/wiki/index.php/Sony_PlayTV_dual_tuner_DVB-T So, that's why I ask for your help. How can I further debug the problem? Is there something I can do? BR, and happy new year! INFO TEST: pvr@prueba:~$ sudo lspci -vvv -s 03:00.0 03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04) Subsystem: TERRATEC Electronic GmbH Cinergy T PCIe Dual Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 4 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at fba0 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd-
cron job: media_tree daily build: ERRORS
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: Fri Jan 9 04:00:08 CET 2015 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.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: 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: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16-i686: ERRORS linux-3.17-i686: ERRORS linux-3.18-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17-x86_64: ERRORS linux-3.18-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: [RFC v01] Driver for Toshiba TC358743 CSI-2 to HDMI bridge
Thanks for testing the driver!
On 01/08/2015 06:12 PM, Philipp Zabel wrote:
Hi Mats,
Am Montag, den 15.12.2014, 19:21 +0100 schrieb matra...@cisco.com:
From: Mats Randgaard matra...@cisco.com
The driver is tested on our hardware and all the implemented features
works as expected.
Missing features:
- CEC support
- HDCP repeater support
- IR support
Signed-off-by: Mats Randgaard matra...@cisco.com
---
MAINTAINERS|6 +
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/tc358743.c | 1768
drivers/media/i2c/tc358743_regs.h | 670 ++
include/media/tc358743.h | 89 ++
include/uapi/linux/v4l2-controls.h |4 +
7 files changed, 2550 insertions(+)
create mode 100644 drivers/media/i2c/tc358743.c
create mode 100644 drivers/media/i2c/tc358743_regs.h
create mode 100644 include/media/tc358743.h
[...]
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
new file mode 100644
index 000..a86cbe0
--- /dev/null
+++ b/drivers/media/i2c/tc358743.c
[...]
+/* --- CUSTOM CTRLS --- */
+
+static const struct v4l2_ctrl_config tc358743_ctrl_audio_sampling_rate = {
+ .id = TC358743_CID_AUDIO_SAMPLING_RATE,
+ .name = Audio sampling rate,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .min = 0,
+ .max = 768000,
+ .step = 1,
+ .def = 0,
+ .flags = V4L2_CTRL_FLAG_READ_ONLY,
+};
+
+static const struct v4l2_ctrl_config tc358743_ctrl_audio_present = {
+ .id = TC358743_CID_AUDIO_PRESENT,
+ .name = Audio present,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
If I don't add
+ .max = 1,
+ .step = 1,
here, I get -ERANGE from v4l2_ctrl_new_custom for this control.
The product I use for testing of this driver has a really old kernel
where this validation of the boolean controls is missing. I'll fix this
in the next revision of this driver.
Thanks,
Mats Randgaard
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: [BUG] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used
Hi, blind Pete. Thank you for taking your time to answer. Yes, I tried different kernels focusing con Ubuntu distro. I don't remember the exact kernel version, but at least those included by default in the Ubuntu 12.04 lts and 14.04 lts ISO image, which worked for me. The latest Ubuntu version I tested was the nightly 15.04 from the 7th of January. BREl 9/1/2015 4:46, blind Pete 0123pe...@gmail.com escribió: Hi dCrypt, I'm not a developer at all. I'm not even sure why I read this list, but can you determine if the problem is associated with a particular kernel version? i.e. if it works on x.y.z but fails on x.y.(z+1) you have a starting point. If you use the word regression and a kernel version number you might get more attention - but I'm only guessing. Good luck, blind Pete dCrypt wrote: Hi again, I'm sorry if I sound quite rude, but I'm not sure if I am doing it right or not. I subscribed to this mailing list in order to ask for help, or to help with a bug that I've found (as instructed in the wiki http://linuxtv.org/wiki/index.php/Bug_Report), but it seems to me that the mailing list is filled up with developing messages. I don't want to participate in the development, I am a developer but I don't have the skills nor the knowledge. If this is not the right place to direct my questions, I would appreciate some advice. Thank you very much, and best regards. -Mensaje original- De: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] En nombre de dCrypt Enviado el: jueves, 01 de enero de 2015 22:04 Para: linux-media@vger.kernel.org Asunto: [BUG] Dual tuner TV card, works using one tuner only, doesn't work if both tuners are used Hi, I just subscribed to the mailing list to submit information on the bug which is driving me crazy since one month ago. I have a VDR based PVR at home, installed over an Ubuntu 14.04 LTS. Everything was working perfectly, until beginning of December. It seems to me that something changed that broke my PVR pretty bad. The problem is the following: tuning (zap) both tuners (it's not needed that both are tuned simultaneously, only one after the other, in no particular order) makes the tuners to enter an state where they can't lock the signal anymore. Facts: - My TV card is a Cinergy T PCIe Dual from Terratec (http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_T_PCIe_dual). - The problem arose in the form of frontend x/0 timed out while tuning to channel ... in /var/log/syslog. It happened when both tuners are active, during EPG scan. The problem does not happen if VDR is run with -D parameter to limit the number of frontends enabled. Disabling the EPG scan with both frontends enabled minimizes the problem, but doesn't solve it because tuning both frontends without any EPG scan makes the error happen again. - I initially thought about a problem in the DVB-T signal, because it all started the 1st of December, during the transition to a new set of frequencies in Spain. - Everything was working perfectly before the 1st, and the problems started suddenly. - I setup testing board for debugging, different board and processor, less memory, lots of Linux distros tested, Windows tested as well. - Both tuners works in windows without problems. Confirmed. - I have completely discarded problems/errors in hardware (because in Windows I can enable both tuners without problems) and VDR (because I can reproduce the problems at OS level, without even having VDR installed). - I have almost narrowed the problem at the cx23885 driver, because when it happens, I can restart the TV card to working conditions by executing rmmod cx23885 and modprobe cx23885; however, as with rmmod several dependencies are unloaded as well, I am stuck and I am unable to go on with debugging to find out where the problem really is. - Tools used to test and confirm the problem are: VDR, MythTV, TVHeadend, dvbscan, dvbv5-scan, dvbv5-zap and others - Linux distros tested: Ubuntu, Fedora, Suse, yaVDR (not sure if the card worked at all), MythBuntu (dvb-fe-tool -a 1 -c DVBT was required to force DVB-T mode for the second tuner), and probably others - I have a Sony PlayTV also with dual tuners, which works without any problem. http://www.linuxtv.org/wiki/index.php/Sony_PlayTV_dual_tuner_DVB-T So, that's why I ask for your help. How can I further debug the problem? Is there something I can do? BR, and happy new year! INFO TEST: pvr@prueba:~$ sudo lspci -vvv -s 03:00.0 03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04) Subsystem: TERRATEC Electronic GmbH Cinergy T PCIe Dual
Re: Media Summit planning for 2015 - was: Re: ELC 2015 - March - San Jose
Em Thu, 08 Jan 2015 22:29:43 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 01/08/2015 08:19 PM, Mauro Carvalho Chehab wrote: Hi all, I want to do the media planning for 2015. As we've agreed last year, we're planning to do one media summit together with the Kernel Summit. While things may change, this year, KS will likely happen by Oct in Korea. I think we may do another summit in US. Looking at: http://events.linuxfoundation.org/ Some possible events would be to do it together with: ELC - end of March - San Jose, CA - US LinuxCon - mid of August - Seattle, WA - US I'll be at the ELC (as mentioned before) ... Ok, I added a request today in order to do it together with ELC, as it seems we'll have enough people there for some discussions. From what I got, we'll have: Hans V. Steven Shuah Mauro Who else? I requested for one day (March, 26), as I'm not sure if we have enough stuff for 2 days. As usual, let's start collecting themes for discussions ;) Regards, Mauro -- 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 1/2] V4L: remove clock name from v4l2_clk API
Hi Josh,
On Wed, 7 Jan 2015, Josh Wu wrote:
Hi, Guennadi
On 1/7/2015 6:17 AM, Guennadi Liakhovetski wrote:
Hi Josh,
On Tue, 6 Jan 2015, Josh Wu wrote:
Hi, Guennadi
After look deep into this patch, I found you miss one line that should be
changed as well.
It's In function v4l2_clk_get(), there still has one line code called
v4l2_clk_find(dev_id, id).
You need to change it to v4l2_clk_find(dev_id, NULL) as well.
Otherwise the code that many sensor used: v4l2_clk_get(client-dev,
mclk)
cannot acquired the mclk clock.
After above changes, this patch works for me.
I think you're right, in fact, since we now don't store CCF-based v4l2_clk
wrappers on the list, this can be simplified even further, I'll update the
patch. Did you only test this patch or both?
I tested both patches with Atmel-isi driver. For the 2/2 patch I applied the
modification Laurent suggested.
Those patches works for me.
The only concern is in ov2640 I still need to acquired two v4l2 clocks:
xvclk that will get the xvclk CCF clock directly.
mclk that make ISI driver call his clock_start()/stop() to
enable/disable ISI's peripheral clock.
If I only get xvclk clock, then the camera capture will be failed with a ISI
timeout error.
No, this doesn't look right to me. The camera sensor has only one clock
input, so, it should only request one clock. Where does the clock signal
to the camera come from on your system?
If it comes from the ISI itself, you don't need to specify the clock in
the DT, since the ISI doesn't produce a clock from DT. If you do want to
have your clock consumer (ov2640) and the supplier (ISI) properly
described in DT, you'll have to teach the ISI to register a CCF clock
source, which then will be connected to from the ov2640. If you choose not
to show your clock in the DT, you can just use v4l2_clk_get(dev, xvclk)
and it will be handled by v4l2_clk / soc-camera / isi-atmel.
If the closk to ov2640 is supplied by a separate clock source, then you
v4l2_clk_get() will connect ov2640 to it directly and soc-camera will
enable and disable it on power-on / -off as required.
From your above description it looks like the clock to ov2640 is supplied
by a separate source, but atmel-isi's .clock_start() / .clock_stop()
functions still need to be called? By looking at those functions it looks
like they turn on and off clocks, supplying the ISI itself... Instead of
only turning on and off clocks, provided by the ISI to a camera sensor. If
my understanding is right, then this is a bug in atmel-isi and it has to
be fixed.
Thanks
Guennadi
But I think this is acceptable as we will keep go forward. Finally we'll
switch to CCF and removed the v4l2_clock then we will move the
clock_start()/stop() caller code to soc_camera.c.
Best Regards,
Josh Wu
Thanks
Guennadi
On 1/2/2015 7:48 PM, Guennadi Liakhovetski wrote:
All uses of the v4l2_clk API so far only register one clock with a fixed
name. This allows us to get rid of it, which also will make CCF and DT
integration easier.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/soc_camera/soc_camera.c | 6 +++---
drivers/media/usb/em28xx/em28xx-camera.c | 2 +-
drivers/media/v4l2-core/v4l2-clk.c | 24
+++-
include/media/v4l2-clk.h | 7 +++
4 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..ce192b6 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1380,7 +1380,7 @@ static int soc_camera_i2c_init(struct
soc_camera_device *icd,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
shd-i2c_adapter_id, shd-board_info-addr);
-icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name,
mclk,
icd);
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name,
icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1561,7 +1561,7 @@ static int scan_async_group(struct soc_camera_host
*ici,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
sasd-asd.match.i2c.adapter_id,
sasd-asd.match.i2c.address);
-icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name,
mclk,
icd);
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name,
icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1666,7 +1666,7 @@ static int soc_of_bind(struct soc_camera_host
*ici,
snprintf(clk_name, sizeof(clk_name), of-%s,
Re: [PATCH 1/2] V4L: remove clock name from v4l2_clk API
Hi Guennadi and Josh, On Thursday 08 January 2015 23:37:58 Guennadi Liakhovetski wrote: On Wed, 7 Jan 2015, Josh Wu wrote: On 1/7/2015 6:17 AM, Guennadi Liakhovetski wrote: On Tue, 6 Jan 2015, Josh Wu wrote: Hi, Guennadi After look deep into this patch, I found you miss one line that should be changed as well. It's In function v4l2_clk_get(), there still has one line code called v4l2_clk_find(dev_id, id). You need to change it to v4l2_clk_find(dev_id, NULL) as well. Otherwise the code that many sensor used: v4l2_clk_get(client-dev, mclk) cannot acquired the mclk clock. After above changes, this patch works for me. I think you're right, in fact, since we now don't store CCF-based v4l2_clk wrappers on the list, this can be simplified even further, I'll update the patch. Did you only test this patch or both? I tested both patches with Atmel-isi driver. For the 2/2 patch I applied the modification Laurent suggested. Those patches works for me. The only concern is in ov2640 I still need to acquired two v4l2 clocks: xvclk that will get the xvclk CCF clock directly. mclk that make ISI driver call his clock_start()/stop() to enable/disable ISI's peripheral clock. If I only get xvclk clock, then the camera capture will be failed with a ISI timeout error. No, this doesn't look right to me. The camera sensor has only one clock input, so, it should only request one clock. Where does the clock signal to the camera come from on your system? That's correct, the sensor driver only has one clock input, so it should just request the xvclk clock. If it comes from the ISI itself, you don't need to specify the clock in the DT, since the ISI doesn't produce a clock from DT. If you do want to have your clock consumer (ov2640) and the supplier (ISI) properly described in DT, you'll have to teach the ISI to register a CCF clock source, which then will be connected to from the ov2640. If you choose not to show your clock in the DT, you can just use v4l2_clk_get(dev, xvclk) and it will be handled by v4l2_clk / soc-camera / isi-atmel. If the closk to ov2640 is supplied by a separate clock source, then you v4l2_clk_get() will connect ov2640 to it directly and soc-camera will enable and disable it on power-on / -off as required. The ISI has no way to supply a sensor clock, the clock is supplied by a separate clock source. From your above description it looks like the clock to ov2640 is supplied by a separate source, but atmel-isi's .clock_start() / .clock_stop() functions still need to be called? By looking at those functions it looks like they turn on and off clocks, supplying the ISI itself... Instead of only turning on and off clocks, provided by the ISI to a camera sensor. If my understanding is right, then this is a bug in atmel-isi and it has to be fixed. That's correct as well, the ISI driver needs to be fixed. -- Regards, Laurent Pinchart -- 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] coda: improve safety in coda_register_device()
On Thu, Jan 08, 2015 at 12:04:20PM +0100, walter harms wrote:
@@ -1844,10 +1844,11 @@ static int coda_register_device(struct coda_dev
*dev, int i)
{
struct video_device *vfd = dev-vfd[i];
- if (i ARRAY_SIZE(dev-vfd))
+ if (i = dev-devtype-num_vdevs)
return -EINVAL;
hi,
just a minor question. if i can not be trusted, i feel you should move the
array access:
struct video_device *vfd = dev-vfd[i];
after the check
i = dev-devtype-num_vdevs
at least that would improve the readability by not trigger my internal alarm
check after access
The access is just taking the address, not dereferencing so it's ok.
This kind of code is fairly common and CodingStyle doesn't have an
opinion here so I left it how the original author wrote it.
regards,
dan carpenter
--
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/3] media-doc: Fix MFC display delay control doc
-Original Message- From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com] Sent: Monday, December 15, 2014 10:11 PM To: linux-media@vger.kernel.org Cc: Kamil Debski; Arun Kumar K; Nicolas Dufresne Subject: [PATCH 3/3] media-doc: Fix MFC display delay control doc The V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE control is a boolean but was documented as a integer. The documentation was also slightly miss-leading. Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com Acked-by: Kamil Debski k.deb...@samsung.com --- Documentation/DocBook/media/v4l/controls.xml | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index e013e4b..4e9462f 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2692,12 +2692,11 @@ in the S5P family of SoCs by Samsung. rowentry/entry/row row entry spanname=idconstantV4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_ DELAY_ENABLE/constantnbsp;/entry - entryinteger/entry - /rowrowentry spanname=descrIf the display delay is enabled then the decoder has to return a -CAPTURE buffer after processing a certain number of OUTPUT buffers. If this number is low, then it may result in -buffers not being dequeued in display order. In addition hardware may still use those buffers as reference, thus -application should not write to those buffers. This feature can be used for example for generating thumbnails of videos. -Applicable to the H264 decoder. + entryboolean/entry + /rowrowentry spanname=descrIf the display delay is +enabled then the decoder is forced to return a CAPTURE buffer (decoded +frame) after processing a certain number of OUTPUT buffers. The delay +can be set through constantV4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY/constan t. This feature can be used for example for generating thumbnails of videos. Applicable to the H264 decoder. /entry /row rowentry/entry/row -- 2.1.0 -- 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 2/3] s5p-mfc-dec: Don't use encoder stop command
-Original Message-
From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
Sent: Monday, December 15, 2014 10:11 PM
To: linux-media@vger.kernel.org
Cc: Kamil Debski; Arun Kumar K; Nicolas Dufresne
Subject: [PATCH 2/3] s5p-mfc-dec: Don't use encoder stop command
The decoder should handle V4L2_DEC_CMD_STOP to trigger drain, but it
currently expecting V4L2_ENC_CMD_STOP.
Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Acked-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 99e2e84..98304fc 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -816,7 +816,7 @@ static int vidioc_decoder_cmd(struct file *file,
void *priv,
unsigned long flags;
switch (cmd-cmd) {
- case V4L2_ENC_CMD_STOP:
+ case V4L2_DEC_CMD_STOP:
if (cmd-flags != 0)
return -EINVAL;
--
2.1.0
--
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/3] Various fixes for s5p-mfc driver
Hi Nicolas, I usually don't ack patches that I plan to take into my tree, but it might be a good idea to let know the submitter that patches are good. Best wishes, -- Kamil Debski Samsung RD Institute Poland -Original Message- From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com] Sent: Thursday, January 08, 2015 12:15 AM To: linux-media@vger.kernel.org Cc: Kamil Debski; Arun Kumar K Subject: Re: [PATCH 0/3] Various fixes for s5p-mfc driver Just a friendly reminder that this patch is pending review ;-P cheers, Nicolas Le 2014-12-15 16:10, Nicolas Dufresne a écrit : This patchset fixes ability to drain the decoder due to use of wrong enumeration name and fixes implementation of display delay controls for MFC firmware v6 and higher. Note that there is no need in the display delay fix for trying to be backward compatible with what the comment was saying since the control properties was preventing it. There was basically no way other then setting a large delay value to get the frames in display order. Nicolas Dufresne (3): s5p-mfc-v6+: Use display_delay_enable CID s5p-mfc-dec: Don't use encoder stop command media-doc: Fix MFC display delay control doc Documentation/DocBook/media/v4l/controls.xml| 11 +-- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 6 +- 3 files changed, 7 insertions(+), 12 deletions(-) -- 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 1/3] s5p-mfc-v6+: Use display_delay_enable CID
-Original Message-
From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
Sent: Monday, December 15, 2014 10:11 PM
To: linux-media@vger.kernel.org
Cc: Kamil Debski; Arun Kumar K; Nicolas Dufresne
Subject: [PATCH 1/3] s5p-mfc-v6+: Use display_delay_enable CID
The MFC driver has two controls, DISPLAY_DELAY and DISPLAY_DELAY_ENABLE
that allow forcing the decoder to return a decoded frame sooner
regardless of the order. The added support for firmware version 6 and
higher was not taking into account the DISPLAY_DELAY_ENABLE boolean.
Instead it had a comment stating that DISPLAY_DELAY should be set to a
negative value to disable it. This is not possible since the control
range is from 0 to 65535. This feature was also supposed to be disabled
by default in order to produce frames in display order.
Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Acked-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 92032a0..0675515 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1340,11 +1340,7 @@ static int s5p_mfc_init_decode_v6(struct
s5p_mfc_ctx *ctx)
/* FMO_ASO_CTRL - 0: Enable, 1: Disable */
reg |= (fmo_aso_ctrl S5P_FIMV_D_OPT_FMO_ASO_CTRL_MASK_V6);
- /* When user sets desplay_delay to 0,
- * It works as display_delay enable and delay set to 0.
- * If user wants display_delay disable, It should be
- * set to negative value. */
- if (ctx-display_delay = 0) {
+ if (ctx-display_delay_enable) {
reg |= (0x1 S5P_FIMV_D_OPT_DDELAY_EN_SHIFT_V6);
writel(ctx-display_delay, mfc_regs-d_display_delay);
}
--
2.1.0
--
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] [media] coda: improve safety in coda_register_device()
The i variable is used as an offset into both the dev-vfd[] and the
dev-devtype-vdevs[] arrays. The second array is smaller so we should
use that as a limit instead of ARRAY_SIZE(dev-vfd). Also the original
check was off by one.
We should use a format string as well in case the -name has any funny
characters and also to stop static checkers from complaining.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 39330a7..5dd6cae 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1844,10 +1844,11 @@ static int coda_register_device(struct coda_dev *dev,
int i)
{
struct video_device *vfd = dev-vfd[i];
- if (i ARRAY_SIZE(dev-vfd))
+ if (i = dev-devtype-num_vdevs)
return -EINVAL;
- snprintf(vfd-name, sizeof(vfd-name), dev-devtype-vdevs[i]-name);
+ snprintf(vfd-name, sizeof(vfd-name), %s,
+dev-devtype-vdevs[i]-name);
vfd-fops = coda_fops;
vfd-ioctl_ops = coda_ioctl_ops;
vfd-release= video_device_release_empty,
--
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] coda: improve safety in coda_register_device()
Am 08.01.2015 11:07, schrieb Dan Carpenter:
The i variable is used as an offset into both the dev-vfd[] and the
dev-devtype-vdevs[] arrays. The second array is smaller so we should
use that as a limit instead of ARRAY_SIZE(dev-vfd). Also the original
check was off by one.
We should use a format string as well in case the -name has any funny
characters and also to stop static checkers from complaining.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 39330a7..5dd6cae 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1844,10 +1844,11 @@ static int coda_register_device(struct coda_dev *dev,
int i)
{
struct video_device *vfd = dev-vfd[i];
- if (i ARRAY_SIZE(dev-vfd))
+ if (i = dev-devtype-num_vdevs)
return -EINVAL;
hi,
just a minor question. if i can not be trusted, i feel you should move the
array access:
struct video_device *vfd = dev-vfd[i];
after the check
i = dev-devtype-num_vdevs
at least that would improve the readability by not trigger my internal alarm
check after access
re,
wh
- snprintf(vfd-name, sizeof(vfd-name), dev-devtype-vdevs[i]-name);
+ snprintf(vfd-name, sizeof(vfd-name), %s,
+ dev-devtype-vdevs[i]-name);
vfd-fops = coda_fops;
vfd-ioctl_ops = coda_ioctl_ops;
vfd-release= video_device_release_empty,
--
To unsubscribe from this list: send the line unsubscribe kernel-janitors in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.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: [PATCH 0/3] Various fixes for s5p-mfc driver
Le 2015-01-08 07:51, Kamil Debski a écrit : I usually don't ack patches that I plan to take into my tree, but it might be a good idea to let know the submitter that patches are good Thanks for letting me know, I may ask informally then next time. cheers, Nicolas -- 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: [PATCHv3 01/20] media: add new types for DVB devnodes
Em Thu, 08 Jan 2015 18:10:13 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Hi Mauro,
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
Mauro Carvalho Chehab wrote:
Most of the DVB subdevs have already their own devnode.
Add support for them at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..707db275f92b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE +
1)
#define MEDIA_ENT_T_DEVNODE_FB(MEDIA_ENT_T_DEVNODE +
2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB(MEDIA_ENT_T_DEVNODE +
4)
+#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)
I'd create another type for the DVB sub-type devices, as there is for
V4L2 sub-devices. I wonder what Laurent thinks.
I discussed this quickly with Laurent on IRC.
There are some concept differences between V4L2 and DVB.
At v4l2:
- the spec is one monolitic header (videodev2.h);
- one devnode is used to control everyhing (/dev/video?)
- there is one v4l core for all types of devices
At DVB:
- each different DVB API has its own header;
- each DVB device type has its own core (ok, they're
linked into one module, but internally they're almost independent);
- each different DVB API has its own devnode.
So, using SUBDEV for DVB (or at least for the devnodes) don't
make much sense.
Ok, there are still some things at DVB side that could be mapped as
subdev. The clear example is the tuner. However, in this case, the
same tuner can be either V4L, DVB or both. So, we need to define just
one subdev type for the tuner.
Also, each DVB device can be identified via major/minor pairs.
I wrote already (and submitted upstream) the patches for media-ctl to
recognize them. They're also on my experimental v4l-utils tree:
http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-
utils.git/log/?h=dvb-media-ctl
As I've mentioned in a previous discussion, the media_entity type field is
too
restrictive. Not only does this use case show that we need a type, sub-type
and sub-sub-type, there are also entities that implement several distinct
types. I thus believe we need a new ioctl is needed to expose detailed
information about entities. This topic has been discussed numerous times in
the past, it just requires someone to implement it.
I'm not opposed to a short-term solution like the one proposed here, but
maybe
we should instead decide it's time to implement the new ioctl instead.
Ok, so let's stick with it for DVB. At DVB side, I don't see a need for
sub-sub-type, especially since DVB has no subdevs (except for the shared
tuner between DVB and V4L). Everything there are devnodes, with their
functionality strictly following the documentation, as the API is fully
handled inside the DVB core[1].
Also, I don't want to mix adding DVB media controller support with the
addition of a new ioctl.
[1] For the non-deprecated DVB devnodes. DVB have 3 devnode types that
are deprecated because they implement functionality found elsewhere
(video, audio and OSD dvb APIs). Only one legacy driver implements it,
and there's no plan to ever add media controller or expand/accept
new drivers using those legacy APIs.
Regards,
Mauro
--
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: linux-next: Tree for Jan 8 (media, v4l2, vb2)
On 01/07/15 21:13, Stephen Rothwell wrote: Hi all, Changes since 20150107: *crickets* Non-merge commits (relative to Linus' tree): 1616 1841 files changed, 45068 insertions(+), 27290 deletions(-) on x86_64: CONFIG_VIDEO_V4L2=m CONFIG_VIDEOBUF2_CORE=y CONFIG_VIDEOBUF2_MEMOPS=y CONFIG_VIDEOBUF2_DMA_CONTIG=y CONFIG_VIDEOBUF2_VMALLOC=m Full randconfig file is attached. drivers/built-in.o: In function `vb2_fop_mmap': (.text+0xa19f3): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_expbuf': (.text+0xa1a31): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamoff': (.text+0xa1abb): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_streamon': (.text+0xa1b45): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_create_bufs': (.text+0xa1bd3): undefined reference to `video_devdata' drivers/built-in.o:(.text+0xa2bdd): more undefined references to `video_devdata' follow drivers/built-in.o: In function `_vb2_fop_release': (.text+0xa3978): undefined reference to `v4l2_fh_release' drivers/built-in.o: In function `vb2_fop_release': (.text+0xa39a5): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_thread': videobuf2-core.c:(.text+0xa43a5): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `__vb2_perform_fileio': videobuf2-core.c:(.text+0xa536a): undefined reference to `v4l2_get_timestamp' drivers/built-in.o: In function `vb2_fop_write': (.text+0xa5508): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_fop_read': (.text+0xa56d8): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_poll': (.text+0xa5886): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_poll': (.text+0xa58e0): undefined reference to `v4l2_event_pending' drivers/built-in.o: In function `vb2_fop_poll': (.text+0xa5fb9): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_qbuf': (.text+0xa61d3): undefined reference to `video_devdata' drivers/built-in.o: In function `vb2_ioctl_prepare_buf': (.text+0xa63fc): undefined reference to `video_devdata' -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.19.0-rc3 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # CONFIG_AUDITSYSCALL is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task
Re: [Linaro-mm-sig] [RFC 1/4] dma-buf: Add constraints sharing information
For me dmabuf and cenalloc offer two different features: one is buffer sharing (dmabuf) and one is buffer allocation (cenalloc). You may want to use dmabuf sharing feature whithout need of the buffer allocation feature, that is what for drm, v4l2, ION and other use dmabuf. In addition of dmabuf we need something aware of hardware devices constraints to allocate the buffer, that will be the role of cenalloc. Like ION, cenalloc will also provide a usespace API to allocate buffers but , unlike ION, the selection of the allocator will be based on devices constraints not on heap ID. In first step I think we can forget the bitmask approach and only use the current fields of devices structure like coherent_dma_mask, dma_parms-max_segment_size or dma_parms-segment_boundary_mask to find matching allocator. What I propose is to add in allocator ops a match(struct device*) function which will be call at attache time. In this way cenalloc could ask to each allocator if it is able to allocate buffer for all attached devices. Regards, Benjamin 2014-12-10 14:47 GMT+01:00 Daniel Vetter dan...@ffwll.ch: On Wed, Dec 10, 2014 at 07:01:16PM +0530, Sumit Semwal wrote: Hi Daniel, Thanks a bunch for your review comments! A few comments, post our discussion at LPC; On 12 October 2014 at 00:25, Daniel Vetter dan...@ffwll.ch wrote: On Sat, Oct 11, 2014 at 01:37:55AM +0530, Sumit Semwal wrote: At present, struct device lacks a mechanism of exposing memory access constraints for the device. Consequently, there is also no mechanism to share these constraints while sharing buffers using dma-buf. If we add support for sharing such constraints, we could use that to try to collect requirements of different buffer-sharing devices to allocate buffers from a pool that satisfies requirements of all such devices. This is an attempt to add this support; at the moment, only a bitmask is added, but if post discussion, we realise we need more information, we could always extend the definition of constraint. A new dma-buf op is also added, to allow exporters to interpret or decide on constraint-masks on their own. A default implementation is provided to just AND () all the constraint-masks. What constitutes a constraint-mask could be left for interpretation on a per-platform basis, while defining some common masks. Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Just a few high-level comments, I'm between conference travel but hopefully I can discuss this a bit at plumbers next week. - I agree that for the insane specific cases we need something opaque like the access constraints mask you propose here. But for the normal case I think the existing dma constraints in dma_params would go a long way, and I think we should look at Rob's RFC from aeons ago to solve those: https://lkml.org/lkml/2012/7/19/285 With this we should be able to cover the allocation constraints of 90% of all cases hopefully. - I'm not sure whether an opaque bitmask is good enough really, I suspect that we also need various priorities between different allocators. With the option that some allocators are flat-out incompatible. Your/Rob's idea to figure out the constraints wrt max number of segments in the sg_list can provide, like you said, maybe 80-90% of the allocation constraints hopefully. The opaque mask should help for the remaining 'crazy' cases, so I'll be glad to merge Rob's and my approach on defining the constraints. I should think a little bit more about the priority idea that you propose here (and in another patch), but atm I am unable to see how that could help solve the finding-out-constraints problem. - The big bummer imo with ION is that it fully side-steps, but this proposal here also seems to add entirely new allocators. My rough idea This proposal does borrow this bit from ION, but once we have the required changes done in the dma api itself, the allocators can just become shims to the dma api allocators (eg dma_alloc_coherent etc) for cases where they can be used directly, while leaving provision for any crazy platform-specific allocators, without the userspace having to worry about it. was that at allocate/attach time we iterate over all attached devices like in Rob's patch and compute the most constrained allocation requirements. Then we pick the underlying dma api allocator for these constraints. That probably means that we need to open up the dma api a bit. But I guess for a start we could simply try to allocate from the most constrained device. Together with the opaque bits you propose here we could even map additional crazy requirements like that an allocation must come from a specific
HDMI recording signals
Hi, Sorry I'm newbie into this. Can anyone help me to record HDMI signal with the DeckLink Mini Recorder via command line? In the SDK there's a program called Capture and I've also tried with a GIT repo from the bmdcapture soft that comes with other cards. When I type this command bmdcapture -m 13 -F nut -A 2 -V 3 -f test.raw I get first time a file with the typical color bars. And second time and so, it generates 0 size files. Same problem testing different inputs with different video formats... Now I've got connected a Raspberry P (B Model), with a Game of Thrones chapter looped, and I can't get any signal. If I install the GUI I can't see anything with the visual soft. I've tried different DeckLink MiniRecorder cards (in case card was broken/not working good), and spoke to the technician support from Blackmagic and it seems that this card is difficult to make it work with Debian. I need to make it work with the command-line. Can somebody help me? Many thanks in advance, Javier-- 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: [RFC 1/6] cec: add new driver for cec support.
Hi Sean, -Original Message- From: Sean Young [mailto:s...@mess.org] Sent: Tuesday, December 30, 2014 2:33 PM To: Kamil Debski Cc: dri-de...@lists.freedesktop.org; linux-media@vger.kernel.org; m.szyprow...@samsung.com; mche...@osg.samsung.com; hverk...@xs4all.nl; kyungmin.p...@samsung.com; Hans Verkuil Subject: Re: [RFC 1/6] cec: add new driver for cec support. On Tue, Dec 23, 2014 at 03:32:17PM +0100, Kamil Debski wrote: +There are still a few todo's, the main one being the remote control +support feature of CEC. I need to research if that should be +implemented via the standard kernel remote control support. I guess a new rc driver type RC_DRIVER_CEC should be introduced (existing types are RC_DRIVER_IR_RAW and RC_DRIVER_SCANCODE). rc_register_device() should not register the sysfs attributes specific for IR, but register sysfs attributes for cec like a link to the device. In addition there should be a new rc_type protocol RC_TYPE_CEC; now rc_keydown_notimeout() can be called for each key press. I guess a new keymap should exist too. Thank you for your suggestions. They are surely helpful and I agree with them. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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: ELC 2015 - March - San Jose
On Wed, Jan 7, 2015 at 11:31 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 01/07/2015 05:20 PM, Steven Toth wrote: Is anyone planning to attend this year? I'm planning to attend. I am planning to attend as well. -- Shuah -- 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
HDMI input on i.MX6 using IPU
Hi,
I have modified both Steve's and Philipp's code, in order to get
something able to get frames from an ADV7611.
Right now, I am back to Philipp's base of code, rebased on top of
media-tree, and everything works fine, except the very last link
between SFMC and IDMAC (using media controller).
Here is a status.
The code is here :
https://github.com/Vodalys/linux-2.6-imx/tree/media-tree-zabel
I am using a DT with this simple connection between adv7611 and IPU :
ipu1_csi0 {
csi0_from_hdmi: endpoint {
remote-endpoint = hdmi0_out;
};
};
hdmiin1: adv7611@4c {
compatible = adi,adv7611;
pinctrl-names = default;
pinctrl-0 = pinctrl_csi0;
reset-gpios = gpio1 20 GPIO_ACTIVE_LOW;
reg = 0x4c 0x68 0x66 0x64 0x62
0x60 0x5e 0x5c 0x5a 0x58 0x56
0x54 0x52;
reg-names = main, avlink, cec, infoframe, esdp,
dpp, afe, rep, edid, hdmi, test,
cp, vdp;
ports {
#address-cells = 1;
#size-cells = 0;
port@0 {
reg = 0;
};
port@1 {
reg = 1;
hdmi0_out: endpoint@1 {
remote-endpoint = csi0_from_hdmi;
bus-width = 16;
};
};
};
};
It seems to be pretty good, I can configure mbus format, etc.
$ media-ctl -v --set-v4l2 'adv7611 1-004c:1 [fmt: YUYV/1280x720]
Opening media device /dev/media0
Enumerating entities
Found 33 entities
Enumerating pads and links
Setting up format YUYV 1280x720 on pad adv7611 1-004c/1
Format set: YUYV 1280x720
Setting up format YUYV 1280x720 on pad /soc/ipu@0240/port@0/0
Format set: YUYV 1280x720
Here is the complete topology right now.
Device topology
- entity 1: /soc/ipu@0240/port@0 (5 pads, 10 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:YUYV/1280x720]
- adv7611 1-004c:1 [ENABLED,IMMUTABLE]
pad1: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 [ENABLED]
- IPU0 SMFC1:0 []
- IPU0 SMFC2:0 []
- IPU0 SMFC3:0 []
- IPU0 IC PRP:0 []
- IPU0 VDIC:0 []
pad2: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 []
pad3: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 []
pad4: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 []
- entity 2: imx-ipuv3-camera.2 (1 pad, 9 links)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
- IPU0 SMFC0:1 []
- IPU0 SMFC1:1 []
- IPU0 SMFC2:1 []
- IPU0 SMFC3:1 []
- IPU0 IC PRP:1 []
- IPU0 IC PRP ENC:1 []
- IPU0 IC PRP VF:1 []
- IPU0 IRT ENC:1 []
- IPU0 IRT VF:1 []
- entity 3: /soc/ipu@0240/port@1 (5 pads, 9 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Sink
[fmt:unknown/0x0]
pad1: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 []
- IPU0 SMFC1:0 []
- IPU0 SMFC2:0 [ENABLED]
- IPU0 SMFC3:0 []
- IPU0 IC PRP:0 []
- IPU0 VDIC:0 []
pad2: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 []
pad3: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 []
pad4: Source
[fmt:unknown/0x0]
- IPU0 SMFC0:0 []
- entity 4: imx-ipuv3-camera.3 (1 pad, 9 links)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
- IPU0 SMFC0:1 []
- IPU0 SMFC1:1 []
- IPU0 SMFC2:1 []
- IPU0 SMFC3:1 []
- IPU0 IC PRP:1 []
- IPU0 IC PRP ENC:1 []
- IPU0 IC PRP VF:1 []
- IPU0 IRT ENC:1 []
- IPU0 IRT VF:1 []
- entity 5: IPU0 SMFC0 (2 pads, 15 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
pad0: Sink
- /soc/ipu@0240/port@0:1 [ENABLED]
- /soc/ipu@0240/port@0:2 []
- /soc/ipu@0240/port@0:3 []
- /soc/ipu@0240/port@0:4 []
- /soc/ipu@0240/port@1:1 []
- /soc/ipu@0240/port@1:2 []
- /soc/ipu@0240/port@1:3 []
- /soc/ipu@0240/port@1:4 []
pad1: Source
- IPU0 IC PRP:0 []
- IPU0 IC PP:0 []
- IPU0 IRT ENC:0 []
- IPU0 IRT VF:0 []
- IPU0 IRT PP:0 []
- imx-ipuv3-camera.3:0 []
- imx-ipuv3-camera.2:0 []
- entity 6: IPU0 SMFC1 (2 pads, 6 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev3
pad0: Sink
- /soc/ipu@0240/port@0:1 []
- /soc/ipu@0240/port@1:1 []
pad1: Source
- IPU0 IRT ENC:0 []
- IPU0 IRT VF:0 []
- imx-ipuv3-camera.3:0 []
- imx-ipuv3-camera.2:0 []
- entity 7: IPU0 SMFC2 (2 pads, 9 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev4
pad0: Sink
-
Re: [RFC v01] Driver for Toshiba TC358743 CSI-2 to HDMI bridge
Hi Mats,
Am Montag, den 15.12.2014, 19:21 +0100 schrieb matra...@cisco.com:
From: Mats Randgaard matra...@cisco.com
The driver is tested on our hardware and all the implemented features
works as expected.
Missing features:
- CEC support
- HDCP repeater support
- IR support
Signed-off-by: Mats Randgaard matra...@cisco.com
---
MAINTAINERS|6 +
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/tc358743.c | 1768
drivers/media/i2c/tc358743_regs.h | 670 ++
include/media/tc358743.h | 89 ++
include/uapi/linux/v4l2-controls.h |4 +
7 files changed, 2550 insertions(+)
create mode 100644 drivers/media/i2c/tc358743.c
create mode 100644 drivers/media/i2c/tc358743_regs.h
create mode 100644 include/media/tc358743.h
[...]
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
new file mode 100644
index 000..a86cbe0
--- /dev/null
+++ b/drivers/media/i2c/tc358743.c
[...]
+/* --- CUSTOM CTRLS --- */
+
+static const struct v4l2_ctrl_config tc358743_ctrl_audio_sampling_rate = {
+ .id = TC358743_CID_AUDIO_SAMPLING_RATE,
+ .name = Audio sampling rate,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .min = 0,
+ .max = 768000,
+ .step = 1,
+ .def = 0,
+ .flags = V4L2_CTRL_FLAG_READ_ONLY,
+};
+
+static const struct v4l2_ctrl_config tc358743_ctrl_audio_present = {
+ .id = TC358743_CID_AUDIO_PRESENT,
+ .name = Audio present,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
If I don't add
+ .max = 1,
+ .step = 1,
here, I get -ERANGE from v4l2_ctrl_new_custom for this control.
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: [PATCHv3 01/20] media: add new types for DVB devnodes
Hi Mauro,
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
Mauro Carvalho Chehab wrote:
Most of the DVB subdevs have already their own devnode.
Add support for them at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..707db275f92b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1)
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA(MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4)
+#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)
I'd create another type for the DVB sub-type devices, as there is for
V4L2 sub-devices. I wonder what Laurent thinks.
I discussed this quickly with Laurent on IRC.
There are some concept differences between V4L2 and DVB.
At v4l2:
- the spec is one monolitic header (videodev2.h);
- one devnode is used to control everyhing (/dev/video?)
- there is one v4l core for all types of devices
At DVB:
- each different DVB API has its own header;
- each DVB device type has its own core (ok, they're
linked into one module, but internally they're almost independent);
- each different DVB API has its own devnode.
So, using SUBDEV for DVB (or at least for the devnodes) don't
make much sense.
Ok, there are still some things at DVB side that could be mapped as
subdev. The clear example is the tuner. However, in this case, the
same tuner can be either V4L, DVB or both. So, we need to define just
one subdev type for the tuner.
Also, each DVB device can be identified via major/minor pairs.
I wrote already (and submitted upstream) the patches for media-ctl to
recognize them. They're also on my experimental v4l-utils tree:
http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-
utils.git/log/?h=dvb-media-ctl
As I've mentioned in a previous discussion, the media_entity type field is too
restrictive. Not only does this use case show that we need a type, sub-type
and sub-sub-type, there are also entities that implement several distinct
types. I thus believe we need a new ioctl is needed to expose detailed
information about entities. This topic has been discussed numerous times in
the past, it just requires someone to implement it.
I'm not opposed to a short-term solution like the one proposed here, but maybe
we should instead decide it's time to implement the new ioctl instead.
--
Regards,
Laurent Pinchart
--
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
Media Summit planning for 2015 - was: Re: ELC 2015 - March - San Jose
Hi all, I want to do the media planning for 2015. As we've agreed last year, we're planning to do one media summit together with the Kernel Summit. While things may change, this year, KS will likely happen by Oct in Korea. I think we may do another summit in US. Looking at: http://events.linuxfoundation.org/ Some possible events would be to do it together with: ELC - end of March - San Jose, CA - US LinuxCon - mid of August - Seattle, WA - US I took a look at https://lwn.net/Calendar/ to see if are there some other event at the first semester, as LinuxCon seems too close to KS, and ELC means about two months to prepare for it, but was unable to find some other interesting event that we could use to merge with the Media Summit. Of course, nothing prevents us to choose some other event or even do a Media Summit that would be independent. We did one like that already in the past, in Helsinki. That's said, probably, the best would be to do the first media summit together with ELC, if we have enough people for it and enough subject for discussions. What do you think? From my side, I'd like to do some deeper discussions related to DVB media controller API. Regards, Mauro Em Thu, 8 Jan 2015 09:54:17 -0700 Shuah Khan shuahk...@gmail.com escreveu: On Wed, Jan 7, 2015 at 11:31 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 01/07/2015 05:20 PM, Steven Toth wrote: Is anyone planning to attend this year? I'm planning to attend. I am planning to attend as well. -- Shuah -- 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 -- Cheers, Mauro -- 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 Summit planning for 2015 - was: Re: ELC 2015 - March - San Jose
On 01/08/2015 08:19 PM, Mauro Carvalho Chehab wrote: Hi all, I want to do the media planning for 2015. As we've agreed last year, we're planning to do one media summit together with the Kernel Summit. While things may change, this year, KS will likely happen by Oct in Korea. I think we may do another summit in US. Looking at: http://events.linuxfoundation.org/ Some possible events would be to do it together with: ELC - end of March - San Jose, CA - US LinuxCon - mid of August - Seattle, WA - US I'll be at the ELC (as mentioned before) but it is highly unlikely I'll be at LinuxCon. A LinuxCon is much more cloud/server/network oriented and much less embedded systems/graphics/video oriented compared to an ELC or LPC. I intend to skip LinuxCons in the future, unless there is some additional reason above and beyond the conference itself for being there. I took a look at https://lwn.net/Calendar/ to see if are there some other event at the first semester, as LinuxCon seems too close to KS, and ELC means about two months to prepare for it, but was unable to find some other interesting event that we could use to merge with the Media Summit. Of course, nothing prevents us to choose some other event or even do a Media Summit that would be independent. We did one like that already in the past, in Helsinki. That's said, probably, the best would be to do the first media summit together with ELC, if we have enough people for it and enough subject for discussions. What do you think? ELC is definitely the right place to do it as far as I am concerned. I have booked the hotel, but not yet the flight. If the summit is going to be next to as opposed to during the ELC, then I need to know soon as I plan to book the flight early February. Regards, Hans From my side, I'd like to do some deeper discussions related to DVB media controller API. Regards, Mauro Em Thu, 8 Jan 2015 09:54:17 -0700 Shuah Khan shuahk...@gmail.com escreveu: On Wed, Jan 7, 2015 at 11:31 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 01/07/2015 05:20 PM, Steven Toth wrote: Is anyone planning to attend this year? I'm planning to attend. I am planning to attend as well. -- Shuah -- 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 -- 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] siano: add support for the media controller at USB driver
Adding support for the media controller for a pure DVB device
is simple: just create a struct media_device and add it to the
dvb adapter. After creating all DVB devices, we need to call
the DVB core, for it to create the media graph.
More work is needed for pure DVB tuners, but this is hidden
at the Siano driver, just like several others non-hybrid
devices. So, this is streight forward.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/common/siano/smscoreapi.h
b/drivers/media/common/siano/smscoreapi.h
index 9c9063cd3208..bf467db5d0b6 100644
--- a/drivers/media/common/siano/smscoreapi.h
+++ b/drivers/media/common/siano/smscoreapi.h
@@ -31,6 +31,8 @@ along with this program. If not, see
http://www.gnu.org/licenses/.
#include linux/wait.h
#include linux/timer.h
+#include media/media-device.h
+
#include asm/page.h
#include smsir.h
@@ -215,6 +217,10 @@ struct smscore_device_t {
bool is_usb_device;
int led_state;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_device *media_dev;
+#endif
};
/* GPIO definitions for antenna frequency domain control (SMS8021) */
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index 85151efdd94c..6872abc3c94b 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -1096,6 +1096,9 @@ static int smsdvb_hotplug(struct smscore_device_t
*coredev,
sms_err(dvb_register_adapter() failed %d, rc);
goto adapter_error;
}
+#ifdef CONFIG_MEDIA_CONTROLLER
+ client-adapter.mdev = coredev-media_dev;
+#endif
/* init dvb demux */
client-demux.dmx.capabilities = DMX_TS_FILTERING;
@@ -1175,6 +1178,8 @@ static int smsdvb_hotplug(struct smscore_device_t
*coredev,
if (smsdvb_debugfs_create(client) 0)
sms_info(failed to create debugfs node);
+ dvb_create_media_graph(coredev-media_dev);
+
return 0;
client_error:
diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
index 94e10b10b66e..68adde1ca749 100644
--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -346,6 +346,42 @@ static void smsusb_term_device(struct usb_interface *intf)
usb_set_intfdata(intf, NULL);
}
+static void siano_media_device_register(struct smsusb_device_t *dev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device *mdev;
+ struct usb_device *udev = dev-udev;
+ int board_id = smscore_get_board_id(dev-coredev);
+ struct sms_board *board = sms_get_board(board_id);
+ int ret;
+
+ mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
+ if (!mdev)
+ return;
+
+ mdev-dev = udev-dev;
+ strlcpy(mdev-model, 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) {
+ sms_err(Couldn't create a media device. Error: %d\n,
+ ret);
+ kfree(mdev);
+ return;
+ }
+
+ dev-coredev-media_dev = mdev;
+
+ sms_info(media controller created);
+
+#endif
+}
+
static int smsusb_init_device(struct usb_interface *intf, int board_id)
{
struct smsdevice_params_t params;
@@ -439,6 +475,7 @@ static int smsusb_init_device(struct usb_interface *intf,
int board_id)
}
sms_info(device 0x%p created, dev);
+ siano_media_device_register(dev);
return rc;
}
--
2.1.0
--
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: [PATCHv3 17/20] dvb-frontend: enable tuner link when the FE thread starts
On Tue, Jan 6, 2015 at 2:08 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
If the dvb frontend thread starts, the tuner should be switched
to the frontend. Add a code that ensures that this will happen,
using the media controller.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index c2c559105f64..04e949ad9722 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -590,12 +590,99 @@ static void dvb_frontend_wakeup(struct dvb_frontend *fe)
wake_up_interruptible(fepriv-wait_queue);
}
+/**
+ * dvb_enable_media_tuner() - tries to enable the DVB tuner
+ *
+ * @fe:struct dvb_frontend pointer
+ *
+ * This function ensures that just one media tuner is enabled for a given
+ * frontend. It has two different behaviors:
+ * - For trivial devices with just one tuner:
+ * it just enables the existing tuner-fe link
+ * - For devices with more than one tuner:
+ * It is up to the driver to implement the logic that will enable one tuner
+ * and disable the other ones. However, if more than one tuner is enabled
for
+ * the same frontend, it will print an error message and return -EINVAL.
+ *
+ * At return, it will return the error code returned by
media_entity_setup_link,
+ * or 0 if everything is OK, if no tuner is linked to the frontend or if the
+ * mdev is NULL.
+ */
+static int dvb_enable_media_tuner(struct dvb_frontend *fe)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct dvb_frontend_private *fepriv = fe-frontend_priv;
+ struct dvb_adapter *adapter = fe-dvb;
+ struct media_device *mdev = adapter-mdev;
+ struct media_entity *entity, *source;
+ struct media_link *link, *found_link = NULL;
+ int i, ret, n_links = 0, active_links = 0;
+
+ if (!mdev)
+ return 0;
+
+ entity = fepriv-dvbdev-entity;
+ for (i = 0; i entity-num_links; i++) {
+ link = entity-links[i];
+ if (link-sink-entity == entity) {
+ found_link = link;
+ n_links++;
+ if (link-flags MEDIA_LNK_FL_ENABLED)
+ active_links++;
+ }
+ }
Does this code path need to be protected with a mutex?
+
+ if (!n_links || active_links == 1 || !found_link)
+ return 0;
+
+ /*
+* If a frontend has more than one tuner linked, it is up to the
driver
+* to select with one will be the active one, as the frontend core
can't
+* guess. If the driver doesn't do that, it is a bug.
+*/
+ if (n_links 1 active_links != 1) {
+ dev_err(fe-dvb-device,
+ WARNING: there are %d active links among %d tuners.
This is a driver's bug!\n,
+ active_links, n_links);
+ return -EINVAL;
+ }
+
+ source = found_link-source-entity;
+ for (i = 0; i source-num_links; i++) {
+ struct media_entity *sink;
+ int flags = 0;
+
+ link = source-links[i];
+ sink = link-sink-entity;
+
+ if (sink == entity)
+ flags = MEDIA_LNK_FL_ENABLED;
+
+ ret = media_entity_setup_link(link, flags);
+ if (ret) {
+ dev_err(fe-dvb-device,
+ Couldn't change link %s-%s to %s. Error
%d\n,
+ source-name, sink-name,
+ flags ? enabled : disabled,
+ ret);
+ return ret;
+ } else
+ dev_dbg(fe-dvb-device,
+ link %s-%s was %s\n,
+ source-name, sink-name,
+ flags ? ENABLED : disabled);
+ }
+#endif
+ return 0;
+}
+
static int dvb_frontend_thread(void *data)
{
struct dvb_frontend *fe = data;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
fe_status_t s;
enum dvbfe_algo algo;
+ int ret;
bool re_tune = false;
bool semheld = false;
@@ -609,6 +696,13 @@ static int dvb_frontend_thread(void *data)
fepriv-wakeup = 0;
fepriv-reinitialise = 0;
+ 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);
+ }
+
dvb_frontend_init(fe);
set_freezable();
--
2.1.0
--
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
Re: [PATCHv3 18/20] cx231xx: enable tuner-decoder link at videobuf start
On Tue, Jan 6, 2015 at 2:08 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
The tuner-decoder needs to be enabled when we're about to
start streaming.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c
b/drivers/media/usb/cx231xx/cx231xx-video.c
index f3d1a488dfa7..634763535d60 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -703,6 +703,74 @@ static void free_buffer(struct videobuf_queue *vq,
struct cx231xx_buffer *buf)
buf-vb.state = VIDEOBUF_NEEDS_INIT;
}
+static int cx231xx_enable_analog_tuner(struct cx231xx *dev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device *mdev = dev-media_dev;
+ struct media_entity *entity, *decoder = NULL, *source;
+ struct media_link *link, *found_link = NULL;
+ int i, ret, active_links = 0;
+
+ if (!mdev)
+ return 0;
+
+/*
+ * This will find the tuner that it is connected into the decoder.
+ * Technically, this is not 100% correct, as the device may be using an
+ * analog input instead of the tuner. However, we can't use the DVB for dvb
+ * while the DMA engine is being used for V4L2.
+ */
+ media_device_for_each_entity(entity, mdev) {
+ if (entity-type == MEDIA_ENT_T_V4L2_SUBDEV_DECODER) {
+ decoder = entity;
+ break;
+ }
+ }
+ if (!decoder)
+ return 0;
+
+ for (i = 0; i decoder-num_links; i++) {
+ link = decoder-links[i];
+ if (link-sink-entity == decoder) {
+ found_link = link;
+ if (link-flags MEDIA_LNK_FL_ENABLED)
+ active_links++;
+ break;
+ }
+ }
Does this code path need to be protected?
+
+ if (active_links == 1 || !found_link)
+ return 0;
+
+ source = found_link-source-entity;
+ for (i = 0; i source-num_links; i++) {
+ struct media_entity *sink;
+ int flags = 0;
+
+ link = source-links[i];
+ sink = link-sink-entity;
+
+ if (sink == entity)
+ flags = MEDIA_LNK_FL_ENABLED;
+
+ ret = media_entity_setup_link(link, flags);
+ if (ret) {
+ dev_err(dev-dev,
+ Couldn't change link %s-%s to %s. Error
%d\n,
+ source-name, sink-name,
+ flags ? enabled : disabled,
+ ret);
+ return ret;
+ } else
+ dev_dbg(dev-dev,
+ link %s-%s was %s\n,
+ source-name, sink-name,
+ flags ? ENABLED : disabled);
+ }
+#endif
+ return 0;
+}
+
static int
buffer_prepare(struct videobuf_queue *vq, struct videobuf_buffer *vb,
enum v4l2_field field)
@@ -756,6 +824,9 @@ buffer_prepare(struct videobuf_queue *vq, struct
videobuf_buffer *vb,
}
buf-vb.state = VIDEOBUF_PREPARED;
+
+ cx231xx_enable_analog_tuner(dev);
+
return 0;
fail:
--
2.1.0
--
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
--
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 Summit planning for 2015 - was: Re: ELC 2015 - March - San Jose
On Thu, Jan 8, 2015 at 12:19 PM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Hi all, I want to do the media planning for 2015. As we've agreed last year, we're planning to do one media summit together with the Kernel Summit. While things may change, this year, KS will likely happen by Oct in Korea. I think we may do another summit in US. Looking at: http://events.linuxfoundation.org/ Some possible events would be to do it together with: ELC - end of March - San Jose, CA - US LinuxCon - mid of August - Seattle, WA - US I took a look at https://lwn.net/Calendar/ to see if are there some other event at the first semester, as LinuxCon seems too close to KS, and ELC means about two months to prepare for it, but was unable to find some other interesting event that we could use to merge with the Media Summit. Of course, nothing prevents us to choose some other event or even do a Media Summit that would be independent. We did one like that already in the past, in Helsinki. That's said, probably, the best would be to do the first media summit together with ELC, if we have enough people for it and enough subject for discussions. What do you think? From my side, I'd like to do some deeper discussions related to DVB media controller API. I will start with voting yes on media summit at ELC. I missed the last one in Europe. I am also interested in DVB media controller API and the work in progress media tokens. thanks, -- Shuah -- 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
