[RFC] Initial scan files troubles and brainstorming
Hello list, I was talking to someone over at tvheadend and was told that the linux-media initial scan files tend to be often very out dated. Also when newer files are submitted, requests to merge them are simply being ignored. Obviously I have zero proof to back those claims. True or not, they have decided to keep a local copy and try to keep that up to date as possible. One of the reasons to take this approach, is because major distro's also do it in this way. This obviously results in a duplication of work and since it's factual data really wasted resources, no central repository of said factual data, but spread and makes it confusing on top of that for users of this data. Now I don't know the proper solution or if it really is a problem. Well it appears to be so I guess ;) Something that comes to mind, is to split off the initial scan files from the dvb-apps package and have a seperate git tree for it, like for example the firmware git tree. I feel this has several advantages over the current setup. One could have /usr/share/dvb/ as a git tree and simply pull to have an up to date tree. Initialscan file 'users (as in developers)' can more easily clone it and do pull requests. Possibly more lenient commit access, e.g. allow a 'trusted' developer of a dvb project to have commit rights, without much risk of breaking any source code. Other things I haven't thought of yet. Since there really isn't a 'stable' release, current trunk can be considered the go to release, unverified changes could live in a branch? Again, if everybody can firmly claim there is no problem and that the initial scanfiles are updated nearly when an actually change takes place, then we should try convince downstream maintainers of course. Anyway, this is just something that was on my mind and wanted some feedback on. Oliver -- 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] Add Fujitsu Siemens Amilo Pi 2530 to gspca upside down table
Hello,
I've got an webcam upside down report for the following system:
System Information
Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Pi 2530
Version:
Serial Number:
UUID: removed
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Base Board Information
Manufacturer: FUJITSU SIEMENS
Product Name: F42
Version: 00030D01
Serial Number: removed
Currently an entry in the gspca/m5602 quirk table is missing. Please add
the attached patch to the DVB kernel tree.
Thanks,
Gregor
From 82b684714f9cee10c7b5c4c7873cd8e65a937aa3 Mon Sep 17 00:00:00 2001
From: Gregor Jasny gja...@googlemail.com
Date: Thu, 18 Oct 2012 13:20:47 +0200
Subject: [PATCH] Add Fujitsu Siemens Amilo Pi 2530 to gspca upside down table.
The DMI information for this system:
System Information
Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Pi 2530
Version:
Serial Number:
UUID: removed
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: FUJITSU SIEMENS
Product Name: F42
Version: 00030D01
Serial Number: removed
Signed-off-by: Gregor Jasny gja...@googlemail.com
---
drivers/media/usb/gspca/m5602/m5602_s5k4aa.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/media/usb/gspca/m5602/m5602_s5k4aa.c
b/drivers/media/usb/gspca/m5602/m5602_s5k4aa.c
index cc8ec3f..c8e1572 100644
--- a/drivers/media/usb/gspca/m5602/m5602_s5k4aa.c
+++ b/drivers/media/usb/gspca/m5602/m5602_s5k4aa.c
@@ -74,6 +74,12 @@ static
DMI_MATCH(DMI_PRODUCT_NAME, AMILO Pa 2548)
}
}, {
+ .ident = Fujitsu-Siemens Amilo Pi 2530,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, FUJITSU SIEMENS),
+ DMI_MATCH(DMI_PRODUCT_NAME, AMILO Pi 2530)
+ }
+ }, {
.ident = MSI GX700,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, Micro-Star International),
--
1.7.2.5
[PATCH] smiapp-pll: Add missing trailing newlines to warning messages
Two warning messages are missing a trailing newline. Fix it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/smiapp-pll.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c
index a577614..169f305 100644
--- a/drivers/media/i2c/smiapp-pll.c
+++ b/drivers/media/i2c/smiapp-pll.c
@@ -194,7 +194,7 @@ int smiapp_pll_calculate(struct device *dev, struct
smiapp_pll_limits *limits,
if (more_mul_min more_mul_max) {
dev_warn(dev,
-unable to compute more_mul_min and more_mul_max);
+unable to compute more_mul_min and more_mul_max\n);
return -EINVAL;
}
@@ -209,7 +209,7 @@ int smiapp_pll_calculate(struct device *dev, struct
smiapp_pll_limits *limits,
dev_dbg(dev, final more_mul: %d\n, i);
if (i more_mul_max) {
- dev_warn(dev, final more_mul is bad, max %d, more_mul_max);
+ dev_warn(dev, final more_mul is bad, max %d\n, more_mul_max);
return -EINVAL;
}
--
1.7.8.6
--
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 v5 0/3] OMAP 3 CSI-2 configuration
Hi Tony, On Tuesday 16 October 2012 16:51:40 Laurent Pinchart wrote: Hi Sakari, Thanks for the patches. For the whole series, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Tony, do you want to take patch 1/3 in your tree, or can I push the whole series through mine ? Ping ? On Sunday 14 October 2012 13:31:22 Sakari Ailus wrote: Hi all, This is an update to an old patchset for CSI-2 configuration for OMAP 3430 and 3630. The patches have been tested on the 3630 only so far, and I don't plan to test them on 3430 in the near future. I've made changes according to Laurent's suggestions to the patches, with the exception of alignment of a certain line. I think it's exactly as it should be. :-) I'm not quite certain about the comment regarding the control register state dependency to the CORE power domain, and why exactly this isn't an issue. We know the MPU must stay powered since the ISP can't wake up MPU, but how is this related to CORE? In the end it seems to work. If you think this should be changed and you also know how, please provide me the text. :-) /* * The PHY configuration is lost in off mode, that's not an * issue since the MPU power domain is forced on whilst the * ISP is in use. */ Comments, questions and other kind of feedback is very welcome. Kind regards, -- 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 1/8] [media] s5p-fimc: Use clk_prepare_enable and clk_disable_unprepare
On 17 October 2012 21:27, Sylwester Nawrocki s.nawro...@samsung.com wrote:
On 10/17/2012 05:35 PM, Sachin Kamat wrote:
Most of the s5p-* drivers have already added support for clk_(un)prepare.
Thus most of your changes in this patch are not needed. I seem to have only
missed fimc-mdevice.c, other modules are already reworked
I did not find these changes in your tree. Please let me know the
branch where these changes are available.
Are in Linus' tree, for quite long already, commits:
11a37c709797cc56f48905e68a3099b79cf08850
[media] s5p-g2d: Added support for clk_prepare
bd7de99d67f778f4ee272346322c0b9cb378
[media] s5p-fimc: convert to clk_prepare()/clk_unprepare()
eb732518e0db585376f95256b18b2149240e3ad3
[media] s5p-mfc: Added support for clk_prepare
Oh I see.. I dunno how i missed to notice this..
Please note there was the media drivers reorganization recently, e.g.
drivers/media/video/s5p-* changed to drivers/media/platform/s5p-*.
Right. I am aware of that.
$ git grep -5 clk_prepare -- drivers/media/platform/s5p-fimc
drivers/media/platform/s5p-fimc/fimc-core.c-
drivers/media/platform/s5p-fimc/fimc-core.c-for (i = 0; i
MAX_FIMC_CLOCKS; i++) {
drivers/media/platform/s5p-fimc/fimc-core.c-fimc-clock[i] =
clk_get(fimc-pdev-dev, fimc_clocks[i]);
drivers/media/platform/s5p-fimc/fimc-core.c-if
(IS_ERR(fimc-clock[i]))
I would prefer you have added the required changes at fimc_md_get_clocks()
and fimc_md_put_clocks() functions.
Ok. I will check this.
Thanks.
--
Regards,
Sylwester
Thanks Sylwester.
--
With warm regards,
Sachin
--
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 V2] drivers/media/v4l2-core/videobuf2-core.c: fix error return code
This patch fixes a NULL pointer dereference bug at __vb2_init_fileio().
The NULL pointer deference happens at videobuf2-core.c:
static size_t __vb2_perform_fileio(struct vb2_queue *q, char __user *data,
size_t count,
loff_t *ppos, int nonblock, int read)
{
...
if (!q-fileio) {
ret = __vb2_init_fileio(q, read);
dprintk(3, file io: vb2_init_fileio result: %d\n, ret);
if (ret)
return ret;
}
fileio = q-fileio; // NULL pointer deference here
...
}
It was tested with vivi driver and qv4l2 for selecting read() as capture method.
The OOPS happened when I've artificially forced the error by commenting the
line:
if (fileio-bufs[i].vaddr == NULL)
But it was fixed after applying this patch.
[ 9002.451154] BUG: unable to handle kernel NULL pointer dereference at
0370
[ 9002.451266] IP: [a038c429] __vb2_perform_fileio+0x69/0x620
[videobuf2_core]
[ 9002.451365] PGD 1df491067 PUD 196d12067 PMD 0
[ 9002.451431] Oops: [#1] SMP
[ 9002.451481] Modules linked in: vivi(O) v4l2_common videobuf2_core(O)
videobuf2_vmalloc(O) videobuf2_memops(O) videodev hidp fuse ebtable_nat
ebtables snd_hda_codec_hdmi snd_hda_codec_realtek ipt_MASQUERADE iptable_nat
nf_nat xt_CHECKSUM iptable_mangle lockd sunrpc bridge stp llc rfcomm bnep btusb
bluetooth pl2303 ip6t_REJECT snd_usb_audio nf_conntrack_ipv6 nf_defrag_ipv6
snd_usbmidi_lib snd_rawmidi ip6table_filter nf_conntrack_ipv4 ip6_tables
nf_defrag_ipv4 xt_state nf_conntrack be2iscsi iscsi_boot_sysfs bnx2i cnic uio
cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm
ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp \
libiscsi scsi_transport_iscsi iTCO_wdt iTCO_vendor_support arc4 binfmt_misc
media iwldvm mac80211 coretemp snd_hda_intel snd_hda_codec crc32c_intel
snd_hwdep ghash_clmulni_intel snd_seq snd_seq_device microcode snd_pcm cdc_ncm
usbnet mii cdc_wdm cdc_acm i915 snd_page_alloc i2c_algo_bit drm_kms_helper
iwlwifi lpc_ich snd_timer sdhci_pci mfd_core drm toshiba_acpi sdhci snd
sparse_keymap e1000e mmc_core cfg80211 i2c_core soundcore mei rfkill wmi video
toshiba_bluetooth vhost_net tun macvtap macvlan kvm_intel kvm uinput [last
unloaded: videobuf2_memops]
[ 9002.453105] CPU 1
[ 9002.453136] Pid: 13830, comm: qv4l2 Tainted: G O
3.6.1-1.local.fc17.x86_64 #1 TOSHIBA PORTEGE R830/Portable PC
[ 9002.453251] RIP: 0010:[a038c429] [a038c429]
__vb2_perform_fileio+0x69/0x620 [videobuf2_core]
[ 9002.453368] RSP: 0018:8801ed37fdf8 EFLAGS: 00010246
[ 9002.453427] RAX: RBX: RCX: 00011b55
[ 9002.453502] RDX: 00011b54 RSI: 88024e256f68 RDI: 88023fdc9c00
[ 9002.453576] RBP: 8801ed37fe58 R08: 00016aa0 R09: 0001
[ 9002.453651] R10: 0075 R11: 0800 R12: 8801bcde0580
[ 9002.453726] R13: 8801bcde0608 R14: 000e1000 R15: 024f0ee0
[ 9002.453801] FS: 7f19308f17c0() GS:88024e24()
knlGS:
[ 9002.453886] CS: 0010 DS: ES: CR0: 80050033
[ 9002.453948] CR2: 0370 CR3: 0001df7df000 CR4: 000407e0
[ 9002.454023] DR0: DR1: DR2:
[ 9002.454098] DR3: DR6: 0ff0 DR7: 0400
[ 9002.454175] Process qv4l2 (pid: 13830, threadinfo 8801ed37e000, task
8801f24b9710)
[ 9002.454260] Stack:
[ 9002.454284] 0800
0001
[ 9002.454379] 8801ed37ff50 88023d56c610
8801bcde0108
[ 9002.454473] 8801bcde0580 000e1000 8801ed37ff50
88023d56c600
[ 9002.454566] Call Trace:
[ 9002.454604] [a038cb54] vb2_read+0x14/0x20 [videobuf2_core]
[ 9002.454676] [a038cc07] vb2_fop_read+0xa7/0x4a0 [videobuf2_core]
[ 9002.454757] [a03dc5e0] v4l2_read+0xf0/0x140 [videodev]
[ 9002.454853] [8118e911] ? rw_verify_area+0x61/0xf0
[ 9002.454918] [8118eda9] vfs_read+0xa9/0x180
[ 9002.454976] [8118eeca] sys_read+0x4a/0x90
[ 9002.455035] [816226e9] system_call_fastpath+0x16/0x1b
[ 9002.455100] Code: 4d 85 ff 48 c7 c0 ea ff ff ff 0f 84 b1 00 00 00 49 8b 9d
f8 01 00 00 48 85 db 0f 84 32 04 00 00 49 c7 85 f8 01 00 00 00 00 00 00 8b 83
70 03 00 00 4c 63 c0 89 45 cc 4b 8d 04 40 4c 8d 64 c3 70
[ 9002.455605] RIP [a038c429] __vb2_perform_fileio+0x69/0x620
[videobuf2_core]
[ 9002.455697] RSP 8801ed37fdf8
[ 9002.455746] CR2: 0370
[ 9002.485830] ---[ end trace e865b84b28e31f5b ]---
This was found when looking for functions that return non-negative
values on error. A simplified version of the semantic match that
finds this problem is as follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
Re: [PATCH V2] drivers/media/v4l2-core/videobuf2-core.c: fix error return code
On Thu, Oct 18, 2012 at 11:47 AM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
This patch fixes a NULL pointer dereference bug at __vb2_init_fileio().
The NULL pointer deference happens at videobuf2-core.c:
static size_t __vb2_perform_fileio(struct vb2_queue *q, char __user *data,
size_t count,
loff_t *ppos, int nonblock, int read)
{
...
if (!q-fileio) {
ret = __vb2_init_fileio(q, read);
dprintk(3, file io: vb2_init_fileio result: %d\n, ret);
if (ret)
return ret;
}
fileio = q-fileio; // NULL pointer deference here
...
}
It was tested with vivi driver and qv4l2 for selecting read() as capture
method.
The OOPS happened when I've artificially forced the error by commenting the
line:
if (fileio-bufs[i].vaddr == NULL)
... but if you manually changed the original source, how
can this be a real BUG?
Or am I missing something here ?
Ezequiel
--
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 v5 0/3] OMAP 3 CSI-2 configuration
* Laurent Pinchart laurent.pinch...@ideasonboard.com [121018 06:46]: Hi Tony, On Tuesday 16 October 2012 16:51:40 Laurent Pinchart wrote: Hi Sakari, Thanks for the patches. For the whole series, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Tony, do you want to take patch 1/3 in your tree, or can I push the whole series through mine ? Ping ? Oops sorry for the delay. Please take the whole series as it's unlikely to conflict with the other omap changes. Regards, Tony -- 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] drivers/media/v4l2-core/videobuf2-core.c: fix error return code
On Thu, Oct 18, 2012 at 5:28 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
On Thu, Oct 18, 2012 at 11:47 AM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
This patch fixes a NULL pointer dereference bug at __vb2_init_fileio().
The NULL pointer deference happens at videobuf2-core.c:
static size_t __vb2_perform_fileio(struct vb2_queue *q, char __user *data,
size_t count,
loff_t *ppos, int nonblock, int read)
{
...
if (!q-fileio) {
ret = __vb2_init_fileio(q, read);
dprintk(3, file io: vb2_init_fileio result: %d\n, ret);
if (ret)
return ret;
}
fileio = q-fileio; // NULL pointer deference here
...
}
It was tested with vivi driver and qv4l2 for selecting read() as capture
method.
The OOPS happened when I've artificially forced the error by commenting the
line:
if (fileio-bufs[i].vaddr == NULL)
... but if you manually changed the original source, how
can this be a real BUG?
It is supposed that under some circumstances, (fileio-bufs[i].vaddr
== NULL) can be true. 'While testing', my change forced the scenario
in which (fileio-bufs[i].vaddr == NULL) is true...
Or am I missing something here ?
Ezequiel
--
Peter
--
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] drivers/media/v4l2-core/videobuf2-core.c: fix error return code
On 10/18/2012 05:28 PM, Ezequiel Garcia wrote:
On Thu, Oct 18, 2012 at 11:47 AM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
This patch fixes a NULL pointer dereference bug at __vb2_init_fileio().
The NULL pointer deference happens at videobuf2-core.c:
static size_t __vb2_perform_fileio(struct vb2_queue *q, char __user *data,
size_t count,
loff_t *ppos, int nonblock, int read)
{
...
if (!q-fileio) {
ret = __vb2_init_fileio(q, read);
dprintk(3, file io: vb2_init_fileio result: %d\n, ret);
if (ret)
return ret;
}
fileio = q-fileio; // NULL pointer deference here
...
}
It was tested with vivi driver and qv4l2 for selecting read() as capture
method.
The OOPS happened when I've artificially forced the error by commenting the
line:
if (fileio-bufs[i].vaddr == NULL)
... but if you manually changed the original source, how
can this be a real BUG?
Or am I missing something here ?
He just commented out this line to trigger the bug, i.e. to simulate
a situation where fileio-bufs[i].vaddr is NULL. Which is now not
handled properly.
--
Thanks,
Sylwester
--
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] Add Fujitsu Siemens Amilo Pi 2530 to gspca upside down table
2012/10/18 Gregor Jasny gja...@googlemail.com: Hello, I've got an webcam upside down report for the following system: System Information Manufacturer: FUJITSU SIEMENS Product Name: AMILO Pi 2530 Version: Serial Number: UUID: removed Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified Base Board Information Manufacturer: FUJITSU SIEMENS Product Name: F42 Version: 00030D01 Serial Number: removed Currently an entry in the gspca/m5602 quirk table is missing. Please add the attached patch to the DVB kernel tree. Thanks, Gregor Acked-by: Erik Andrén erik.and...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: 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:Thu Oct 18 19:00:14 CEST 2012 git hash:ff30d37083096acb56fb6edc0209d7ba36731a55 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS linux-3.5-i686: ERRORS linux-3.6-i686: ERRORS linux-3.7-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: ERRORS linux-3.6-x86_64: ERRORS linux-3.7-rc1-x86_64: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification 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
[PATCH] [media] s5p-tv: don't include linux/version.h in mixer_video.c
The header is not needed, so remove it. Signed-off-by: Jesper Juhl j...@chaosbits.net --- drivers/media/platform/s5p-tv/mixer_video.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/platform/s5p-tv/mixer_video.c b/drivers/media/platform/s5p-tv/mixer_video.c index 0c1cd89..9b52f3a 100644 --- a/drivers/media/platform/s5p-tv/mixer_video.c +++ b/drivers/media/platform/s5p-tv/mixer_video.c @@ -19,7 +19,6 @@ #include linux/videodev2.h #include linux/mm.h #include linux/module.h -#include linux/version.h #include linux/timer.h #include media/videobuf2-dma-contig.h -- 1.7.1 -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Looks like the iommu framework does not have generic functions
exported for all the needs yet. The hardware specific functions
are defined in files like intel-iommu.h and amd-iommu.h. Follow
the same standard for omap-iommu.h.
This is needed because we are removing plat and mach includes
for ARM common zImage support. Further work should continue
in the iommu framework context as only pure platform data will
be communicated from arch/arm/*omap*/* code to the iommu
framework.
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Ido Yariv i...@wizery.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/iommu2.c |1
arch/arm/plat-omap/include/plat/iommu.h| 10 +--
arch/arm/plat-omap/include/plat/iovmm.h| 89
drivers/iommu/omap-iommu-debug.c |2 -
drivers/iommu/omap-iommu.c |1
drivers/iommu/omap-iovmm.c | 46 ++
drivers/media/platform/omap3isp/isp.c |1
drivers/media/platform/omap3isp/isp.h |2 -
drivers/media/platform/omap3isp/ispccdc.c |1
drivers/media/platform/omap3isp/ispstat.c |1
drivers/media/platform/omap3isp/ispvideo.c |2 -
include/linux/omap-iommu.h | 47 +++
12 files changed, 101 insertions(+), 102 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
create mode 100644 include/linux/omap-iommu.h
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..77cbf2f 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/slab.h
#include linux/stringify.h
+#include linux/omap-iommu.h
#include plat/iommu.h
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 7e8c7b6..a4b71b1 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -216,13 +216,10 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define MMU_RAM_PADDR_SHIFT12
#define MMU_RAM_PADDR_MASK \
((~0UL MMU_RAM_PADDR_SHIFT) MMU_RAM_PADDR_SHIFT)
-#define MMU_RAM_ENDIAN_SHIFT 9
+
#define MMU_RAM_ENDIAN_MASK(1 MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_BIG (1 MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_LITTLE (0 MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ELSZ_SHIFT 7
#define MMU_RAM_ELSZ_MASK (3 MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_8 (0 MMU_RAM_ELSZ_SHIFT)
+
#define MMU_RAM_ELSZ_16(1 MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_32(2 MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_NONE (3 MMU_RAM_ELSZ_SHIFT)
@@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
void *priv),
void *isr_priv);
-extern void omap_iommu_save_ctx(struct device *dev);
-extern void omap_iommu_restore_ctx(struct device *dev);
-
extern int omap_install_iommu_arch(const struct iommu_functions *ops);
extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/arch/arm/plat-omap/include/plat/iovmm.h
deleted file mode 100644
index 498e57c..000
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * omap iommu: simple virtual address space management
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __IOMMU_MMAP_H
-#define __IOMMU_MMAP_H
-
-#include linux/iommu.h
-
-struct iovm_struct {
- struct omap_iommu *iommu; /* iommu object which this belongs to */
- u32 da_start; /* area definition */
- u32 da_end;
- u32 flags; /* IOVMF_: see below */
- struct list_headlist; /* linked in ascending order */
- const struct sg_table *sgt; /* keep 'page' - 'da' mapping */
- void*va; /* mpu side mapped address */
-};
-
-/*
- * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
- *
- * lower 16 bit is used for h/w and upper 16 bit is for s/w.
- */
-#define IOVMF_SW_SHIFT 16
-
-/*
- * iovma: h/w flags derived from cam and ram attribute
- */
-#define IOVMF_CAM_MASK (~((1 10) - 1))
-#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
-
-#define IOVMF_PGSZ_MASK(3 0)
-#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
-#define IOVMF_PGSZ_64K
[PATCH 4/6] ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c
This file should not be in arch/arm. Move it to drivers/iommu
to allow making most of the header local to drivers/iommu.
This is needed as we are removing plat and mach includes
from drivers for ARM common zImage support.
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Ido Yariv i...@wizery.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Omar Ramirez Luna omar.l...@linaro.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile|2
arch/arm/plat-omap/include/plat/iommu.h | 272 ++-
drivers/iommu/Makefile |1
drivers/iommu/omap-iommu-debug.c|1
drivers/iommu/omap-iommu.c | 19 ++
drivers/iommu/omap-iommu.h | 255 +
drivers/iommu/omap-iommu2.c |2
drivers/iommu/omap-iopgtable.h | 22 ---
drivers/iommu/omap-iovmm.c |1
9 files changed, 293 insertions(+), 282 deletions(-)
create mode 100644 drivers/iommu/omap-iommu.h
rename arch/arm/mach-omap2/iommu2.c = drivers/iommu/omap-iommu2.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..d6721a7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -184,8 +184,6 @@ obj-$(CONFIG_HW_PERF_EVENTS)+= pmu.o
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
-obj-$(CONFIG_OMAP_IOMMU) += iommu2.o
-
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index a4b71b1..c677b9f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -10,103 +10,21 @@
* published by the Free Software Foundation.
*/
-#ifndef __MACH_IOMMU_H
-#define __MACH_IOMMU_H
-
-#include linux/io.h
-
-#if defined(CONFIG_ARCH_OMAP1)
-#error iommu for this processor not implemented yet
-#endif
-
-struct iotlb_entry {
- u32 da;
- u32 pa;
- u32 pgsz, prsvd, valid;
- union {
- u16 ap;
- struct {
- u32 endian, elsz, mixed;
- };
- };
-};
-
-struct omap_iommu {
- const char *name;
- struct module *owner;
- struct clk *clk;
- void __iomem*regbase;
- struct device *dev;
- void*isr_priv;
- struct iommu_domain *domain;
-
- unsigned intrefcount;
- spinlock_t iommu_lock; /* global for this whole object */
-
- /*
-* We don't change iopgd for a situation like pgd for a task,
-* but share it globally for each iommu.
-*/
- u32 *iopgd;
- spinlock_t page_table_lock; /* protect iopgd */
-
- int nr_tlb_entries;
-
- struct list_headmmap;
- struct mutexmmap_lock; /* protect mmap */
-
- void *ctx; /* iommu context: registres saved area */
- u32 da_start;
- u32 da_end;
-};
-
-struct cr_regs {
- union {
- struct {
- u16 cam_l;
- u16 cam_h;
- };
- u32 cam;
- };
- union {
- struct {
- u16 ram_l;
- u16 ram_h;
- };
- u32 ram;
- };
-};
-
-struct iotlb_lock {
- short base;
- short vict;
-};
-
-/* architecture specific functions */
-struct iommu_functions {
- unsigned long version;
-
- int (*enable)(struct omap_iommu *obj);
- void (*disable)(struct omap_iommu *obj);
- void (*set_twl)(struct omap_iommu *obj, bool on);
- u32 (*fault_isr)(struct omap_iommu *obj, u32 *ra);
-
- void (*tlb_read_cr)(struct omap_iommu *obj, struct cr_regs *cr);
- void (*tlb_load_cr)(struct omap_iommu *obj, struct cr_regs *cr);
-
- struct cr_regs *(*alloc_cr)(struct omap_iommu *obj,
- struct iotlb_entry *e);
- int (*cr_valid)(struct cr_regs *cr);
- u32 (*cr_to_virt)(struct cr_regs *cr);
- void (*cr_to_e)(struct cr_regs *cr, struct iotlb_entry *e);
- ssize_t (*dump_cr)(struct omap_iommu *obj, struct cr_regs *cr,
- char *buf);
-
- u32 (*get_pte_attr)(struct iotlb_entry *e);
+#define MMU_REG_SIZE 256
- void (*save_ctx)(struct omap_iommu *obj);
- void (*restore_ctx)(struct omap_iommu *obj);
- ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
+/**
+ * struct iommu_arch_data - omap iommu private data
+ * @name: name of
Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Tony, Em Thu, 18 Oct 2012 13:28:42 -0700 Tony Lindgren t...@atomide.com escreveu: Looks like the iommu framework does not have generic functions exported for all the needs yet. The hardware specific functions are defined in files like intel-iommu.h and amd-iommu.h. Follow the same standard for omap-iommu.h. This is needed because we are removing plat and mach includes for ARM common zImage support. Further work should continue in the iommu framework context as only pure platform data will be communicated from arch/arm/*omap*/* code to the iommu framework. Cc: Joerg Roedel joerg.roe...@amd.com Cc: Ohad Ben-Cohen o...@wizery.com Cc: Ido Yariv i...@wizery.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Omar Ramirez Luna omar.l...@linaro.org Cc: linux-media@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/iommu2.c |1 arch/arm/plat-omap/include/plat/iommu.h| 10 +-- arch/arm/plat-omap/include/plat/iovmm.h| 89 drivers/iommu/omap-iommu-debug.c |2 - drivers/iommu/omap-iommu.c |1 drivers/iommu/omap-iovmm.c | 46 ++ drivers/media/platform/omap3isp/isp.c |1 drivers/media/platform/omap3isp/isp.h |2 - drivers/media/platform/omap3isp/ispccdc.c |1 drivers/media/platform/omap3isp/ispstat.c |1 drivers/media/platform/omap3isp/ispvideo.c |2 - Acked-by: Mauro Carvalho Chehab mche...@redhat.com It is better if you send this entire series through the ARM tree, keeping this hole series altogether (and avoiding the risk of breaking bisectability if it goes through separate trees). So, you can add my ack for those header moves for drivers/media/platform/*. Regards, Mauro -- 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: [PATCH] rc-core: add separate defines for protocol bitmaps and numbers
On Wed, Oct 17, 2012 at 05:18:56PM +0100, Sean Young wrote: On Fri, Oct 12, 2012 at 01:11:54AM +0200, David Härdeman wrote: The RC_TYPE_* defines are currently used both where a single protocol is expected and where a bitmap of protocols is expected. This patch tries to separate the two in preparation for the following patches. I'm not sure why this is needed. I'm not sure I can explain it much better. Something like rc_keydown() or functions which add/remove entries to the keytable want a single protocol. Future userspace APIs would also benefit from numeric protocols (rather than bitmap ones). Keytables are smaller if they can use a small(ish) integer rather than a bitmap. Other functions or struct members (e.g. allowed_protos, enabled_protocols, etc) accept multiple protocols and need a bitmap. Using different types reduces the risk of programmer error. Using a protocol enum whereever possible also makes for a more future-proof user-space API as we don't need to worry about a sufficient number of bits being available (e.g. in structs used for ioctl() calls). The use of both a number and a corresponding bit is dalso one in e.g. the input subsystem as well (see all the references to set/clear bit when changing keytables for example). The intended use is also clearer to anyone reading the code. Where a single protocol is expected, enum rc_type is used, where one or more protocol(s) are expected, something like u64 is used. Having two sets of #define and enums for the same information is not necessarily clearer. Not only two set of define and enum, two different data types. To me it helps a lot to be able to tell from a function declaration whether it expects *a* protocol or protocols. I don't like the name RC_BIT_* either; how about RC_PROTO_*? I have no strong opinions here Sean The patch has been rewritten so that the format of the sysfs protocols file is no longer altered (at the loss of some detail). The file itself should probably be deprecated in the future though. I missed some drivers when creating the last version of the patch because some weren't enabled in my .config. This patch passes an allmodyes build. Signed-off-by: David Härdeman da...@hardeman.nu -- 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] winbond-cir: do not rename input name
On Wed, Oct 17, 2012 at 04:38:21PM +0100, Sean Young wrote:
54fd321 [media] winbond: remove space from driver name inadvertently
renamed the input device name.
Signed-off-by: Sean Young s...@mess.org
Acked-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/winbond-cir.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index de48a79..ce3ffc5 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -184,7 +184,7 @@ enum wbcir_txstate {
};
/* Misc */
-#define WBCIR_NAMEwinbond-cir
+#define WBCIR_NAMEWinbond CIR
#define WBCIR_ID_FAMILY 0xF1 /* Family ID for the WPCD376I */
#define WBCIR_ID_CHIP0x04 /* Chip ID for the WPCD376I
*/
#define INVALID_SCANCODE 0x7FFF /* Invalid with all protos */
@@ -987,7 +987,7 @@ wbcir_probe(struct pnp_dev *device, const struct
pnp_device_id *dev_id)
}
data-dev-driver_type = RC_DRIVER_IR_RAW;
- data-dev-driver_name = WBCIR_NAME;
+ data-dev-driver_name = DRVNAME;
data-dev-input_name = WBCIR_NAME;
data-dev-input_phys = wbcir/cir0;
data-dev-input_id.bustype = BUS_HOST;
--
1.7.11.7
--
David Härdeman
--
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/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Mauro Carvalho Chehab mche...@redhat.com [121018 13:58]: Tony, Em Thu, 18 Oct 2012 13:28:42 -0700 Tony Lindgren t...@atomide.com escreveu: Looks like the iommu framework does not have generic functions exported for all the needs yet. The hardware specific functions are defined in files like intel-iommu.h and amd-iommu.h. Follow the same standard for omap-iommu.h. This is needed because we are removing plat and mach includes for ARM common zImage support. Further work should continue in the iommu framework context as only pure platform data will be communicated from arch/arm/*omap*/* code to the iommu framework. Cc: Joerg Roedel joerg.roe...@amd.com Cc: Ohad Ben-Cohen o...@wizery.com Cc: Ido Yariv i...@wizery.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Omar Ramirez Luna omar.l...@linaro.org Cc: linux-media@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/iommu2.c |1 arch/arm/plat-omap/include/plat/iommu.h| 10 +-- arch/arm/plat-omap/include/plat/iovmm.h| 89 drivers/iommu/omap-iommu-debug.c |2 - drivers/iommu/omap-iommu.c |1 drivers/iommu/omap-iovmm.c | 46 ++ drivers/media/platform/omap3isp/isp.c |1 drivers/media/platform/omap3isp/isp.h |2 - drivers/media/platform/omap3isp/ispccdc.c |1 drivers/media/platform/omap3isp/ispstat.c |1 drivers/media/platform/omap3isp/ispvideo.c |2 - Acked-by: Mauro Carvalho Chehab mche...@redhat.com It is better if you send this entire series through the ARM tree, keeping this hole series altogether (and avoiding the risk of breaking bisectability if it goes through separate trees). So, you can add my ack for those header moves for drivers/media/platform/*. Yes thanks. Once people are happy with these, I will push just these patches on v3.7-rc1 alone into omap-for-v3.8/cleanup-headers-iommu so both media and iommu tree can merge them in too as needed. Regards, Tony -- 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
Fw: [GIT PULL for v3.7-rc1] media fixes
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
v4l_for_linus
For:
- one Kconfig fix patch;
- one patch fixing DocBook breakage due to the drivers/media UAPI
changes;
- the remaining UAPI media changes (DVB API).
I'm aware that is is a little late for the UAPI renames for the DVB API, but
IMHO,
it is better to merge it for 3.7, due to two reasons:
1) There is a major rename at 3.7 (not only uapi changes, but also the
entire media drivers were reorganized on 3.7, in order to simplify
the Kconfig logic, and easy drivers selection, especially for hybrid
devices). By confining all those renames there at 3.7 it will cause
all the harm at for media developers on just one shot. Stable
backports
upstream and at distros will likely welcome it as well, as they
won't need to check what changed on 3.7 and what was postponed for
on 3.8.
2) The V4L2 DocBook Makefile creates a cross-reference between the media
API headers and the specs. This helps us _a_lot_ to be sure that all
API improvements are properly documented. Every time a header
changes from
one place to another, DocBook/media/Makefile needs to be patched.
Currently, the DocBook breakage patch depends on the DVB UAPI.
Of course, if you prefer to not merge this as-is, it is not a big deal to break
the
DocBook fixup into two parts, one for 3.7 and another one for 3.8. Just let me
know
and I'll revert those two patches and make another pull request one without the
DVB
UAPI patch.
Thank you!
Mauro
-
Latest commit at the branch:
2c76a12ae9f5e6e2afc400bfbdd8b326e7d36b2a [media] Kconfig: Fix dependencies for
driver autoselect options
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
v4l_for_linus
for you to fetch changes up to 2c76a12ae9f5e6e2afc400bfbdd8b326e7d36b2a:
[media] Kconfig: Fix dependencies for driver autoselect options (2012-10-17
16:45:56 -0300)
David Howells (1):
UAPI: (Scripted) Disintegrate include/linux/dvb
Mauro Carvalho Chehab (3):
Merge tag 'v3.7-rc1' into staging/for_v3.8
DocBook/media/Makefile: Fix build due to uapi breakage
[media] Kconfig: Fix dependencies for driver autoselect options
Documentation/DocBook/media/Makefile| 76 -
drivers/media/Kconfig | 18 ++-
include/linux/dvb/Kbuild| 8 -
include/linux/dvb/dmx.h | 130 +--
include/linux/dvb/video.h | 249 +
include/uapi/linux/dvb/Kbuild | 8 +
include/{ = uapi}/linux/dvb/audio.h| 0
include/{ = uapi}/linux/dvb/ca.h | 0
include/uapi/linux/dvb/dmx.h| 155 ++
include/{ = uapi}/linux/dvb/frontend.h | 0
include/{ = uapi}/linux/dvb/net.h | 0
include/{ = uapi}/linux/dvb/osd.h | 0
include/{ = uapi}/linux/dvb/version.h | 0
include/uapi/linux/dvb/video.h | 274
14 files changed, 487 insertions(+), 431 deletions(-)
rename include/{ = uapi}/linux/dvb/audio.h (100%)
rename include/{ = uapi}/linux/dvb/ca.h (100%)
create mode 100644 include/uapi/linux/dvb/dmx.h
rename include/{ = uapi}/linux/dvb/frontend.h (100%)
rename include/{ = uapi}/linux/dvb/net.h (100%)
rename include/{ = uapi}/linux/dvb/osd.h (100%)
rename include/{ = uapi}/linux/dvb/version.h (100%)
create mode 100644 include/uapi/linux/dvb/video.h
--
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: cron job: media_tree daily build: ERRORS
Em Thu, 18 Oct 2012 19:25:50 +0200 (CEST) Hans Verkuil hverk...@xs4all.nl escreveu: 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:Thu Oct 18 19:00:14 CEST 2012 git hash:ff30d37083096acb56fb6edc0209d7ba36731a55 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS ... ...ERRORS I fixed today part of the issues by correcting the linux/Makefile. Now, the tarball generated at linuxtv.org site will have everything needed. However: The UABI patches deadly-broke our out-of-tree building system. One of the premises there is that there will be just one file with the same inside the entire media tree. It was never a problem before to do it, as it is not allowed to have two drivers for the same thing. The UABI patches did something weird, though: for some files, there are now _two_versions_ of the same API file, e. g. (from linux/Makefile): # Both Kernelspace and Userspace API TARDIR += include/linux/dvb/include/uapi/linux/dvb/ TARFILES += include/linux/usb/video.h include/uapi/linux/dvb/video.h TARFILES += include/media/v4l2-subdev.h include/uapi/linux/v4l2-subdev.h TARFILES += include/media/v4l2-common.h include/uapi/linux/v4l2-common.h TARFILES += include/media/v4l2-mediabus.h include/uapi/linux/v4l2-mediabus.h Basically, all headers that used to have if __KERNEL__ inside were now converted into two files, one with the kernel header, and another one with the pure userspace version. That violates the previous rule imposed by the out-of-tree building system. Fixing it is not a trivial task, as it requires to replace this part of v4l/Makefile to something more smart: links:: @echo creating symbolic links... @find ../linux/drivers/media -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. @find ../linux/sound -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. @find ../linux/drivers/staging -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. @find ../linux/drivers/misc -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. So that would, for example, detect those duplicated files and select just the Kernel one, and add a -I ../linux/include, in order to allow those includes to get the *uapi/* one. Another alternative would be to not create links for *.h at all. The build system logic could also be completely replaced by one that works with subdirs. Not sure what's the better one (and probably won't have any time to actually write such patches anytime soon). So, suggestions, patches, etc are very welcome. Hans, If we're unable to fix it soon, I suggest to disable the daily build report, or to remove the compilations from the media-build.git tree, as they'll all show ERRORS. 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: cron job: media_tree daily build: ERRORS
Em Fri, 19 Oct 2012 00:11:47 -0300 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Thu, 18 Oct 2012 19:25:50 +0200 (CEST) Hans Verkuil hverk...@xs4all.nl escreveu: 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:Thu Oct 18 19:00:14 CEST 2012 git hash:ff30d37083096acb56fb6edc0209d7ba36731a55 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS ... ...ERRORS I fixed today part of the issues by correcting the linux/Makefile. Now, the tarball generated at linuxtv.org site will have everything needed. However: The UABI patches deadly-broke our out-of-tree building system. One of the premises there is that there will be just one file with the same inside the entire media tree. It was never a problem before to do it, as it is not allowed to have two drivers for the same thing. The UABI patches did something weird, though: for some files, there are now _two_versions_ of the same API file, e. g. (from linux/Makefile): # Both Kernelspace and Userspace API TARDIR += include/linux/dvb/ include/uapi/linux/dvb/ TARFILES += include/linux/usb/video.h include/uapi/linux/dvb/video.h TARFILES += include/media/v4l2-subdev.h include/uapi/linux/v4l2-subdev.h TARFILES += include/media/v4l2-common.h include/uapi/linux/v4l2-common.h TARFILES += include/media/v4l2-mediabus.h include/uapi/linux/v4l2-mediabus.h Basically, all headers that used to have if __KERNEL__ inside were now converted into two files, one with the kernel header, and another one with the pure userspace version. That violates the previous rule imposed by the out-of-tree building system. Fixing it is not a trivial task, as it requires to replace this part of v4l/Makefile to something more smart: links:: @echo creating symbolic links... @find ../linux/drivers/media -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. @find ../linux/sound -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. @find ../linux/drivers/staging -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. @find ../linux/drivers/misc -name '*.[ch]' -type f -print0 | xargs -0n 255 ln -sf --target-directory=. So that would, for example, detect those duplicated files and select just the Kernel one, and add a -I ../linux/include, in order to allow those includes to get the *uapi/* one. Another alternative would be to not create links for *.h at all. The build system logic could also be completely replaced by one that works with subdirs. Forget about the above Mental note to myself: don't try to fix anything late night after an stressing day ;) The reason for the breakage is right; the diagnosis is wrong. The files at linux/include aren't c/c to v4l/ dir; they're linked with -I. Yet, compiling here are giving several errors: /home/v4l/media_build/v4l/dvb_frontend.c: In function 'dvb_frontend_clear_cache': /home/v4l/media_build/v4l/dvb_frontend.c:952:17: error: 'NO_STREAM_ID_FILTER' undeclared (first use in this function) /home/v4l/media_build/v4l/dvb_frontend.c:952:17: note: each undeclared identifier is reported only once for each function it appears in /home/v4l/media_build/v4l/dvb_frontend.c:969:11: error: 'LNA_AUTO' undeclared (first use in this function) /home/v4l/media_build/v4l/dvb_frontend.c: At top level: /home/v4l/media_build/v4l/dvb_frontend.c:1025:3: error: 'DTV_STREAM_ID' undeclared here (not in a function) /home/v4l/media_build/v4l/dvb_frontend.c:1025:2: error: array index in initializer not of integer type /home/v4l/media_build/v4l/dvb_frontend.c:1025:2: error: (near initialization for 'dtv_cmds') /home/v4l/media_build/v4l/dvb_frontend.c:1026:3: error: 'DTV_DVBT2_PLP_ID_LEGACY' undeclared here (not in a function) /home/v4l/media_build/v4l/dvb_frontend.c:1026:2: error: array index in initializer not of integer type /home/v4l/media_build/v4l/dvb_frontend.c:1026:2: error: (near initialization for 'dtv_cmds') /home/v4l/media_build/v4l/dvb_frontend.c:1027:3: error: 'DTV_LNA' undeclared here (not in a function) /home/v4l/media_build/v4l/dvb_frontend.c:1027:2: error: array index in initializer not of integer type /home/v4l/media_build/v4l/dvb_frontend.c:1027:2: error: (near initialization for 'dtv_cmds') /home/v4l/media_build/v4l/dvb_frontend.c:1060:2: error: array index in initializer not of integer type /home/v4l/media_build/v4l/dvb_frontend.c:1060:2: error: (near initialization for 'dtv_cmds') Very likely becase gcc is using the DVB uapi under /usr/include, instead of the one at the building system. Maybe that's because of the very large number of include dirs added by our
