Re: [PATCH resend] [media] rc-core: fix protocol_change regression in ir_raw_event_register
On Thu, Oct 16, 2014 at 11:49 PM, David Härdeman da...@hardeman.nu wrote: I think this is already addressed in this thread: http://www.spinics.net/lists/linux-media/msg79865.html The patch in that thread would have broken things since the store_protocol function is not changed at the same time. The patch I sent also takes that into account. My concern is still that user space behaviour changes. In my case, lirc simply does not work anymore. More generically, anyone now using e.g. nuvoton-cir with anything other than RC6_MCE will not get their devices working without first explictly enabling the correct protocol from sysfs or with ir-keytable. Correct me if I'm wrong but the change_protocol function in struct rc_dev is meant for changing hardware decoder protocols which means only a few drivers actually use it. So the added empty function change_protocol into rc-ir-raw.c doesnt really make sense in the first place. Tomas -- 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 dtv-scan-tables] Add Dusseldorf DVB-T channels
Add Dusseldorf DVB-T channels While travelling for LinuxCon EU, I was able to do scans at the Airport and at the hotel. Those are the channels I was able to find while there. I scanned for DVB-T2 channels too, but was unable to find any. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/dvb-t/de-Dusseldorf b/dvb-t/de-Dusseldorf new file mode 100644 index 000..aaf5a53 --- /dev/null +++ b/dvb-t/de-Dusseldorf @@ -0,0 +1,144 @@ +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 48200 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/8 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 51400 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 53800 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 58600 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 59400 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 60200 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 1/2 + CODE_RATE_LP = NONE + MODULATION = QAM/64 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 67400 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 1/2 + CODE_RATE_LP = NONE + MODULATION = QAM/64 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 69000 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 69800 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 1/2 + CODE_RATE_LP = NONE + MODULATION = QAM/64 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 72200 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 74600 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/4 + HIERARCHY = NONE + INVERSION = AUTO + +[CHANNEL] + DELIVERY_SYSTEM = DVBT + FREQUENCY = 76200 + BANDWIDTH_HZ = 800 + CODE_RATE_HP = 2/3 + CODE_RATE_LP = NONE + MODULATION = QAM/16 + TRANSMISSION_MODE = 8K + GUARD_INTERVAL = 1/8 + HIERARCHY = NONE + INVERSION = AUTO + -- 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 v2 2/3] media: soc_camera: rcar_vin: Add capture width check for NV16 format
Hello.
On 10/16/2014 10:12 AM, Yoshihiro Kaneko wrote:
From: Koji Matsuoka koji.matsuoka...@renesas.com
At the time of NV16 capture format, the user has to specify the
capture output width of the multiple of 32 for H/W specification.
At the time of using NV16 format by ioctl of VIDIOC_S_FMT,
this patch adds align check and the error handling to forbid
specification of the capture output width which is not a multiple of 32.
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
v2 [Yoshihiro Kaneko]
* use u32 instead of unsigned long
drivers/media/platform/soc_camera/rcar_vin.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 34d5b80..ff5f80a 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
[...]
@@ -1087,6 +1091,7 @@ static int rcar_vin_set_rect(struct soc_camera_device
*icd)
unsigned char dsize = 0;
struct v4l2_rect *cam_subrect = cam-subrect;
u32 value;
+ u32 imgstr;
Quite strange name, given the variable's use... what does it stands for?
dev_dbg(icd-parent, Crop %ux%u@%u:%u\n,
icd-user_width, icd-user_height, cam-vin_left, cam-vin_top);
@@ -1164,7 +1169,11 @@ static int rcar_vin_set_rect(struct soc_camera_device
*icd)
break;
}
- iowrite32(ALIGN(cam-out_width, 0x10), priv-base + VNIS_REG);
+ if (icd-current_fmt-host_fmt-fourcc == V4L2_PIX_FMT_NV16)
+ imgstr = ALIGN(cam-out_width, 0x20);
+ else
+ imgstr = ALIGN(cam-out_width, 0x10);
+ iowrite32(imgstr, priv-base + VNIS_REG);
I'd call the variable 'vnis' as it gets written to the VNIS register...
return 0;
}
@@ -1606,6 +1615,17 @@ static int rcar_vin_set_fmt(struct soc_camera_device
*icd,
dev_dbg(dev, S_FMT(pix=0x%x, %ux%u)\n,
pixfmt, pix-width, pix-height);
+ /* At the time of NV16 capture format, the user has to specify the
+ width of the multiple of 32 for H/W specification. */
The preferred multi-line comment format is this:
/*
* bla
* bla
*/
+ if (priv-error_flag == false)
+ priv-error_flag = true;
I don't see where else you check this flag, it seems rather useless. I
also don't see where you clear it, other than the add/remove device paths.
+ else {
+ if ((pixfmt == V4L2_PIX_FMT_NV16) (pix-width 0x1F)) {
+ dev_err(icd-parent, Specified width error in NV16
format.\n);
+ return -EINVAL;
+ }
+ }
+
WBR, Sergei
--
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: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support
Hello. On 10/14/2014 10:22 AM, Yoshihiro Kaneko wrote: From: Koji Matsuoka koji.matsuoka...@renesas.com Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com --- This patch is against master branch of linuxtv.org/media_tree.git. drivers/media/platform/soc_camera/rcar_vin.c | 10 ++ include/linux/platform_data/camera-rcar.h| 1 + 2 files changed, 11 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 20defcb..7eb4f1e 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -74,6 +74,8 @@ #define VNMC_INF_YUV10_BT656 (2 16) #define VNMC_INF_YUV10_BT601 (3 16) #define VNMC_INF_YUV16(5 16) +#define VNMC_INF_RGB888(6 16) +#define VNMC_INF_RGB_MASK (6 16) I don't see why you direly need this mask; you could use VNMC_INF_RGB888. [...] diff --git a/include/linux/platform_data/camera-rcar.h b/include/linux/platform_data/camera-rcar.h index dfc83c5..03a9df6 100644 --- a/include/linux/platform_data/camera-rcar.h +++ b/include/linux/platform_data/camera-rcar.h @@ -17,6 +17,7 @@ #define RCAR_VIN_VSYNC_ACTIVE_LOW (1 1) #define RCAR_VIN_BT601(1 2) #define RCAR_VIN_BT656(1 3) +#define RCAR_VIN_BT709 (1 4) I don't see where it's used... WBR, Sergei -- 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: soc_camera: rcar_vin: Enable VSYNC field toggle mode
Hello. On 10/14/2014 10:25 AM, Yoshihiro Kaneko wrote: From: Koji Matsuoka koji.matsuoka...@renesas.com By applying this patch, it sets to VSYNC field toggle mode not only at the time of progressive mode but at the time of an interlace mode. Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com --- This patch is against master branch of linuxtv.org/media_tree.git. drivers/media/platform/soc_camera/rcar_vin.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 5196c81..bf97ed6 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -108,6 +108,7 @@ #define VNDMR2_VPS(1 30) #define VNDMR2_HPS(1 29) #define VNDMR2_FTEV (1 17) +#define VNDMR2_VLV_1 (1 12) Please instead do: #define VNDMR2_VLV(n) ((n 0xf) 12) WBR, Sergei -- 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 v2 2/3] media: soc_camera: rcar_vin: Add capture width check for NV16 format
On 10/16/2014 10:12 AM, Yoshihiro Kaneko wrote:
From: Koji Matsuoka koji.matsuoka...@renesas.com
At the time of NV16 capture format, the user has to specify the
capture output width of the multiple of 32 for H/W specification.
At the time of using NV16 format by ioctl of VIDIOC_S_FMT,
this patch adds align check and the error handling to forbid
specification of the capture output width which is not a multiple of 32.
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
---
v2 [Yoshihiro Kaneko]
* use u32 instead of unsigned long
drivers/media/platform/soc_camera/rcar_vin.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 34d5b80..ff5f80a 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
[...]
@@ -1606,6 +1615,17 @@ static int rcar_vin_set_fmt(struct soc_camera_device
*icd,
dev_dbg(dev, S_FMT(pix=0x%x, %ux%u)\n,
pixfmt, pix-width, pix-height);
+ /* At the time of NV16 capture format, the user has to specify the
+ width of the multiple of 32 for H/W specification. */
+ if (priv-error_flag == false)
+ priv-error_flag = true;
+ else {
+ if ((pixfmt == V4L2_PIX_FMT_NV16) (pix-width 0x1F)) {
+ dev_err(icd-parent, Specified width error in NV16
format.\n);
+ return -EINVAL;
+ }
+ }
Oh, and the kernel style dictates that {} should be used in all arms of
the *if* statement if they're used in at least one.
WBR, Sergei
--
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 resend] [media] rc-core: fix protocol_change regression in ir_raw_event_register
Em Sat, 18 Oct 2014 13:10:01 +0300 Tomas Melin tomas.me...@iki.fi escreveu: On Thu, Oct 16, 2014 at 11:49 PM, David Härdeman da...@hardeman.nu wrote: I think this is already addressed in this thread: http://www.spinics.net/lists/linux-media/msg79865.html The patch in that thread would have broken things since the store_protocol function is not changed at the same time. The patch I sent also takes that into account. My concern is still that user space behaviour changes. In my case, lirc simply does not work anymore. Yeah, lirc should be enabled by default. More generically, anyone now using e.g. nuvoton-cir with anything other than RC6_MCE will not get their devices working without first explictly enabling the correct protocol from sysfs or with ir-keytable. The right behavior here is to enable the protocol as soon as the new keycode table is written by userspace. Except for LIRC and the protocol of the current table enabled is not a good idea because: 1) It misread the code from some other IR; 2) It will be just spending power without need, running several tasks (one for each IR type) with no reason, as the keytable won't match the codes for other IRs (and if it is currently matching, then this is a bad behavior). Correct me if I'm wrong but the change_protocol function in struct rc_dev is meant for changing hardware decoder protocols which means only a few drivers actually use it. Actually, most drivers are for hardware decoders. So the added empty function change_protocol into rc-ir-raw.c doesnt really make sense in the first place. Tomas -- 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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
Em Thu, 16 Oct 2014 08:59:29 -0600
Shuah Khan shua...@osg.samsung.com escreveu:
On 10/16/2014 08:48 AM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 08:39:14 -0600,
Shuah Khan wrote:
On 10/16/2014 08:16 AM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 08:10:52 -0600,
Shuah Khan wrote:
On 10/16/2014 08:01 AM, Takashi Iwai wrote:
At Thu, 16 Oct 2014 07:10:37 -0600,
Shuah Khan wrote:
On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
On 10/14/2014 04:58 PM, Shuah Khan wrote:
[...]
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
+err = media_get_audio_tkn(subs-dev-dev);
+if (err == -EBUSY) {
+dev_info(subs-dev-dev, %s device is busy\n,
+__func__);
In my opinion this should not dev_info() as this is out of band error
signaling and also as the potential to spam the log. The userspace
application is already properly notified by the return code.
Yes it has the potential to flood the dmesg especially with alsa,
I will remove the dev_info().
Yes. And, I think doing this in the trigger isn't the best.
Why not in open close?
My first cut of this change was in open and close. I saw pulseaudio
application go into this loop trying to open the device. To avoid
such problems, I went with trigger stat and stop. That made all the
pulseaudio continues attempts to open problems go away.
But now starting the stream gives the error, and PA would loop it
again, no?
Also, is this token restriction needed only for PCM? No mixer or
other controls?
snd_pcm_ops are the only ones media drivers implement and use. So
I don't think mixer is needed. If it is needed, it is not to hard
to add for that case.
Well, then I wonder what resource does actually conflict with
usb-audio and media drivers at all...?
audio for dvb/v4l apps gets disrupted when audio app starts. For
example, dvb or v4l app tuned to a channel, and when an audio app
starts. audio path needs protected to avoid conflicts between
digital and analog applications as well.
OK, then concentrating on only PCM is fine.
But, I'm still not convinced about doing the token management in the
trigger. The reason -EBUSY doesn't work is that it's the very same
error code when a PCM device is blocked by other processes. And
-EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.
ah. ok your recommendation is to go with open and close.
Mauro has some reservations with holding at open when I discussed
my observations with pulseaudio when I was holding token in open
instead of trigger start. Maybe he can chime with his concerns.
I think his concern was breaking applications if token is held in
open().
Yes. My concern is that PA has weird behaviors, and it tries to open and
keep opened all audio devices. Is there a way for avoiding it to keep doing
it for V4L devices?
Based on what you are seeing trigger could be worse.
How applications (e.g. PA) should behave if the token get fails?
Shouldn't it retry or totally give up?
It would be up to the application I would think. I see that arecord
quits right away when it finds the device busy. pluseaudio on the other
hand appears to retry. I downloaded pulseaudio sources to understand
what it is doing, however I didn't get too far. The way it does audio
handling is complex for me to follow without spending a lot of time.
thanks,
-- Shuah
--
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
cron job: media_tree daily build: WARNINGS
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: Sun Oct 19 04:00:17 CEST 2014 git branch: test git hash: cf3167cf1e969b17671a4d3d956d22718a8ceb85 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.17-0.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: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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
