Re: [linuxtv-media:master 483/499] m88ds3103.c:undefined reference to `i2c_del_mux_adapter'
Em Sat, 21 Dec 2013 10:27:44 +0800 kbuild test robot fengguang...@intel.com escreveu: tree: git://linuxtv.org/media_tree.git master head: c57f87e62368c33ebda11a4993380c8e5a19a5c5 commit: 44b9055b4b058d7b02bf0380158627f9be79b9e5 [483/499] [media] m88ds3103: use I2C mux for tuner I2C adapter config: i386-randconfig-x0-12210941 (attached as .config) All error/warnings: warning: (VIDEO_EM28XX_DVB) selects DVB_M88DS3103 which has unmet direct dependencies (MEDIA_SUPPORT DVB_CORE I2C I2C_MUX) drivers/built-in.o: In function `m88ds3103_release': m88ds3103.c:(.text+0x1ab1af): undefined reference to `i2c_del_mux_adapter' drivers/built-in.o: In function `m88ds3103_attach': (.text+0x1ab342): undefined reference to `i2c_add_mux_adapter' --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation Not sure what's the best fix for this. I can see 3 alternatives: 1) make em28xx dependent on I2C_MUX. That sounds wrong, as the em28xx bridge doesn't have i2c muxes on it, and just one frontend has. Well, we may eventually convert all i2c gate stuff into i2c mux support, with makes sense, but it takes time and lots of effort. 2) we may make MEDIA_SUBDRV_AUTOSELECT dependent of I2C and I2C_MUX. That means that users will need to manually enable I2C_MUX on some distributions. Not sure about others, but, on Fedora, this option is disabled. So, we'll end by receiving a number of complains from users, until all distros that ship media start adding I2C_MUX. 3) if MEDIA_SUBDRV_AUTOSELECT is selected, it will select I2C and I2C_MUX. Of course, MEDIA_SUBDRV_AUTOSELECT will need to inherit all dependencies that I2C and I2C_MUX have (only HAS_IOMEM). The disadvantage is that, if new dependencies are added on I2C, they'll also need to be added here. As the hole idea of autoselect is to let the user not bother about whatever frontend/tuner is used by a driver, IMHO, (3) is the better solution. Patch for (3) is enclosed. -- Cheers, Mauro From: Mauro Carvalho Chehab m.che...@samsung.com Date: Sat, 21 Dec 2013 05:42:11 -0200 Subject: [PATCH] [media] subdev autoselect only works if I2C and I2C_MUX is selected As reported by the kbuild test robot fengguang...@intel.com: warning: (VIDEO_EM28XX_DVB) selects DVB_M88DS3103 which has unmet direct dependencies (MEDIA_SUPPORT DVB_CORE I2C I2C_MUX) drivers/built-in.o: In function `m88ds3103_release': m88ds3103.c:(.text+0x1ab1af): undefined reference to `i2c_del_mux_adapter' drivers/built-in.o: In function `m88ds3103_attach': (.text+0x1ab342): undefined reference to `i2c_add_mux_adapter' Reported-by: kbuild test robot fengguang...@intel.com Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8270388e2a0d..1d0758aeb8e4 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -172,6 +172,9 @@ comment Media ancillary drivers (tuners, sensors, i2c, frontends) config MEDIA_SUBDRV_AUTOSELECT bool Autoselect ancillary drivers (tuners, sensors, i2c, frontends) depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || MEDIA_CAMERA_SUPPORT + depends on HAS_IOMEM + select I2C + select I2C_MUX default y help By default, a media driver auto-selects all possible ancillary -- 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: [linuxtv-media:master 483/499] m88ds3103.c:undefined reference to `i2c_del_mux_adapter'
Em Sat, 21 Dec 2013 08:50:48 -0200 Mauro Carvalho Chehab m.che...@samsung.com escreveu: From: Mauro Carvalho Chehab m.che...@samsung.com Date: Sat, 21 Dec 2013 05:42:11 -0200 Subject: [PATCH] [media] subdev autoselect only works if I2C and I2C_MUX is selected As reported by the kbuild test robot fengguang...@intel.com: warning: (VIDEO_EM28XX_DVB) selects DVB_M88DS3103 which has unmet direct dependencies (MEDIA_SUPPORT DVB_CORE I2C I2C_MUX) drivers/built-in.o: In function `m88ds3103_release': m88ds3103.c:(.text+0x1ab1af): undefined reference to `i2c_del_mux_adapter' drivers/built-in.o: In function `m88ds3103_attach': (.text+0x1ab342): undefined reference to `i2c_add_mux_adapter' Reported-by: kbuild test robot fengguang...@intel.com Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com It is the Christmas week. I don't think we'll have enough reviews for this, as most are preparing themselves to properly celebrate the birth of our Lord, or to just rest during Seasons. Due to that, I'll likely just apply this patch with a better description, as I intend to merge the pending patches at -next during this weekend, and I don't want to spread compilation breakages there. If we latter agree with some other solution, reverting this one while applying other changes should be trivial. Happy Seasons! Mauro diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8270388e2a0d..1d0758aeb8e4 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -172,6 +172,9 @@ comment Media ancillary drivers (tuners, sensors, i2c, frontends) config MEDIA_SUBDRV_AUTOSELECT bool Autoselect ancillary drivers (tuners, sensors, i2c, frontends) depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || MEDIA_CAMERA_SUPPORT + depends on HAS_IOMEM + select I2C + select I2C_MUX default y help By default, a media driver auto-selects all possible ancillary -- -- 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] subdev autoselect only works if I2C and I2C_MUX is selected
As reported by the kbuild test robot fengguang...@intel.com: warning: (VIDEO_EM28XX_DVB) selects DVB_M88DS3103 which has unmet direct dependencies (MEDIA_SUPPORT DVB_CORE I2C I2C_MUX) drivers/built-in.o: In function `m88ds3103_release': m88ds3103.c:(.text+0x1ab1af): undefined reference to `i2c_del_mux_adapter' drivers/built-in.o: In function `m88ds3103_attach': (.text+0x1ab342): undefined reference to `i2c_add_mux_adapter' There are 3 possible ways to fix it: 1) make em28xx dependent on I2C_MUX. That sounds wrong, as the em28xx bridge doesn't have i2c muxes on it, and just one frontend has. Well, subdevs could eventually be converted to, instead of using dvb i2c gate control, to use i2c mux support. That makes sense, but it takes time and lots of effort. Not sure if this will happen anytime soon. 2) MEDIA_SUBDRV_AUTOSELECT can be dependent of I2C and I2C_MUX. That means that users will need to manually enable I2C_MUX on some distributions. Not sure about others, but, on Fedora, this option is disabled. So, it can end by generating a number of complains from users that their devices suddenly stopped working after a Kernel upgrade, at least until all distros that ship Kernels with I2C_MUX enabled. 3) if MEDIA_SUBDRV_AUTOSELECT is selected, it will select I2C and I2C_MUX. Of course, MEDIA_SUBDRV_AUTOSELECT will need to inherit all dependencies that I2C and I2C_MUX have (only HAS_IOMEM). The disadvantage is that, if new dependencies are added on I2C, they'll also need to be added here. As the hole idea of autoselect is to let the user not bother about whatever frontend/tuner is used by a driver, IMHO, (3) is the better solution. Reported-by: kbuild test robot fengguang...@intel.com Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8270388e2a0d..1d0758aeb8e4 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -172,6 +172,9 @@ comment Media ancillary drivers (tuners, sensors, i2c, frontends) config MEDIA_SUBDRV_AUTOSELECT bool Autoselect ancillary drivers (tuners, sensors, i2c, frontends) depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || MEDIA_CAMERA_SUPPORT + depends on HAS_IOMEM + select I2C + select I2C_MUX default y help By default, a media driver auto-selects all possible ancillary -- 1.8.3.1 -- 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
[GIT PULL] exynos4-is runtime PM related cleanups
The following changes since commit c57f87e62368c33ebda11a4993380c8e5a19a5c5: [media] anysee: fix non-working E30 Combo Plus DVB-T (2013-12-20 14:24:20 -0200) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git v3.14-exynos4-is-pm-rework Sylwester Nawrocki (6): exynos4-is: Leave FIMC clocks enabled when runtime PM is disabled exynos4-is: Activate mipi-csis in probe() if runtime PM is disabled exynos4-is: Enable FIMC-LITE clock if runtime PM is not used exynos4-is: Correct clean up sequence on error path in fimc_is_probe() exynos4-is: Enable fimc-is clocks in probe() if runtime PM is disabled exynos4-is: Remove dependency on PM_RUNTIME from Kconfig drivers/media/platform/exynos4-is/Kconfig |2 +- drivers/media/platform/exynos4-is/fimc-core.c | 29 +--- drivers/media/platform/exynos4-is/fimc-is.c | 29 +++-- drivers/media/platform/exynos4-is/fimc-lite.c | 24 +++- drivers/media/platform/exynos4-is/mipi-csis.c | 11 - 5 files changed, 62 insertions(+), 33 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
[GIT PULL] exynos4-is driver updates
The following changes since commit c57f87e62368c33ebda11a4993380c8e5a19a5c5: [media] anysee: fix non-working E30 Combo Plus DVB-T (2013-12-20 14:24:20 -0200) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git v3.14-exynos4-is Sylwester Nawrocki (3): exynos4-is: Add clock provider for the external clocks exynos4-is: Add support for asynchronous subdevices registration exynos4-is: Add the FIMC-IS ISP capture DMA driver drivers/media/platform/exynos4-is/Kconfig |9 + drivers/media/platform/exynos4-is/Makefile |4 + drivers/media/platform/exynos4-is/fimc-is-param.c |2 +- drivers/media/platform/exynos4-is/fimc-is-param.h |5 + drivers/media/platform/exynos4-is/fimc-is-regs.c | 14 + drivers/media/platform/exynos4-is/fimc-is-regs.h |1 + drivers/media/platform/exynos4-is/fimc-is.c|3 + drivers/media/platform/exynos4-is/fimc-is.h|5 + drivers/media/platform/exynos4-is/fimc-isp-video.c | 660 drivers/media/platform/exynos4-is/fimc-isp-video.h | 44 ++ drivers/media/platform/exynos4-is/fimc-isp.c | 29 +- drivers/media/platform/exynos4-is/fimc-isp.h | 27 +- drivers/media/platform/exynos4-is/media-dev.c | 350 --- drivers/media/platform/exynos4-is/media-dev.h | 31 +- 14 files changed, 1079 insertions(+), 105 deletions(-) create mode 100644 drivers/media/platform/exynos4-is/fimc-isp-video.c create mode 100644 drivers/media/platform/exynos4-is/fimc-isp-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: [PATCH RFC v5 09/12] DocBook: fix wait.c location
Hi Antti, This is already fixed in the mainline kernel, but not yet merged back into our repository. Anyway, you can drop this patch. Regards, Hans On 12/20/2013 06:49 AM, Antti Palosaari wrote: Documentation did not compile as wait.c location was wrong. Signed-off-by: Antti Palosaari cr...@iki.fi --- Documentation/DocBook/device-drivers.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 6c9d9d3..f517008 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -58,7 +58,7 @@ /sect1 sect1titleWait queues and Wake events/title !Iinclude/linux/wait.h -!Ekernel/wait.c +!Ekernel/sched/wait.c /sect1 sect1titleHigh-resolution timers/title !Iinclude/linux/ktime.h ZZ -- 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 RFC v5 10/12] DocBook: document 1 Hz flag
Some small nits: On 12/20/2013 06:49 AM, Antti Palosaari wrote: Update documention to reflect 1 Hz frequency step flag. Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Antti Palosaari cr...@iki.fi --- .../DocBook/media/v4l/vidioc-enum-freq-bands.xml | 8 +--- Documentation/DocBook/media/v4l/vidioc-g-frequency.xml| 3 ++- Documentation/DocBook/media/v4l/vidioc-g-modulator.xml| 6 -- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml| 15 --- Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml | 8 ++-- 5 files changed, 29 insertions(+), 11 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml index 6541ba0..e2e866c 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -100,7 +100,7 @@ See xref linkend=v4l2-tuner-type //entry entrystructfieldcapability/structfield/entry entry spanname=hspanThe tuner/modulator capability flags for this frequency band, see xref linkend=tuner-capability /. The constantV4L2_TUNER_CAP_LOW/constant -capability must be the same for all frequency bands of the selected tuner/modulator. +or constantV4L2_TUNER_CAP_1HZ/constant capability must be the same for all frequency bands of the selected tuner/modulator. So either all bands have that capability set, or none of them have that capability./entry /row row @@ -109,7 +109,8 @@ So either all bands have that capability set, or none of them have that capabili entry spanname=hspanThe lowest tunable frequency in units of 62.5 kHz, or if the structfieldcapability/structfield flag constantV4L2_TUNER_CAP_LOW/constant is set, in units of 62.5 -Hz, for this frequency band./entry +Hz, for this frequency band. 1 Hz unit is used when capabilities flag Replace 'capabilities' by 'structfieldcapability/structfield'. +constantV4L2_TUNER_CAP_1HZ/constant is set./entry /row row entry__u32/entry @@ -117,7 +118,8 @@ Hz, for this frequency band./entry entry spanname=hspanThe highest tunable frequency in units of 62.5 kHz, or if the structfieldcapability/structfield flag constantV4L2_TUNER_CAP_LOW/constant is set, in units of 62.5 -Hz, for this frequency band./entry +Hz, for this frequency band. 1 Hz unit is used when capabilities flag +constantV4L2_TUNER_CAP_1HZ/constant is set./entry Ditto. /row row entry__u32/entry diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml index c7a1c46..c7bd925 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml @@ -111,7 +111,8 @@ See xref linkend=v4l2-tuner-type //entry entryTuning frequency in units of 62.5 kHz, or if the v4l2-tuner; or v4l2-modulator; structfieldcapabilities/structfield flag 'capabilities' should be 'capability'. Nobody noticed that the wrong field name was used here :-) constantV4L2_TUNER_CAP_LOW/constant is set, in units of 62.5 -Hz./entry +Hz. 1 Hz unit is used when capabilities flag +constantV4L2_TUNER_CAP_1HZ/constant is set./entry Replace 'capabilities' by 'structfieldcapability/structfield'. /row row entry__u32/entry diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml index 7f4ac7e..afee56a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml @@ -113,7 +113,8 @@ change for example with the current video standard./entry entryThe lowest tunable frequency in units of 62.5 KHz, or if the structfieldcapability/structfield flag constantV4L2_TUNER_CAP_LOW/constant is set, in units of 62.5 -Hz./entry +Hz, or if the structfieldcapability/structfield flag +constantV4L2_TUNER_CAP_1HZ/constant is set, in unit of 1 Hz./entry s/unit/units/ /row row entry__u32/entry @@ -121,7 +122,8 @@ Hz./entry entryThe highest tunable frequency in units of 62.5 KHz, or if the structfieldcapability/structfield flag constantV4L2_TUNER_CAP_LOW/constant is set, in units of 62.5 -Hz./entry +Hz, or if the structfieldcapability/structfield flag +constantV4L2_TUNER_CAP_1HZ/constant is set, in unit of 1 Hz./entry Ditto. /row row entry__u32/entry diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 6cc8201..6a43719 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -134,7 +134,9 @@ the structure refers to a radio tuner the
Re: [PATCH RFC v5 11/12] DocBook: Software Defined Radio Interface
More nits... On 12/20/2013 06:49 AM, Antti Palosaari wrote: Document V4L2 SDR interface. Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Antti Palosaari cr...@iki.fi --- Documentation/DocBook/media/v4l/compat.xml | 10 +++ Documentation/DocBook/media/v4l/dev-sdr.xml | 99 Documentation/DocBook/media/v4l/io.xml | 6 ++ Documentation/DocBook/media/v4l/v4l2.xml | 1 + Documentation/DocBook/media/v4l/vidioc-g-fmt.xml | 6 ++ 5 files changed, 122 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/dev-sdr.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 0c7195e..85fb864 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2523,6 +2523,16 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.14/title + orderedlist +listitem + paraAdded Software Defined Radio (SDR) Interface. + /para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml b/Documentation/DocBook/media/v4l/dev-sdr.xml new file mode 100644 index 000..3caf44d --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-sdr.xml @@ -0,0 +1,99 @@ + titleSoftware Defined Radio Interface (SDR)/title + + para +SDR is an abbreviation of Software Defined Radio, the radio device +which uses application software for modulation or demodulation. That interface s/That/This/ +is intended for controlling and data streaming of such devices. + /para + + para +SDR devices are accessed through character device special files named +filename/dev/swradio0/filename to filename/dev/swradio255/filename +with major number 81 and dynamically allocated minor numbers 0 to 255. + /para + + section +titleQuerying Capabilities/title + +para +Devices supporting the SDR receiver interface set the +constantV4L2_CAP_SDR_CAPTURE/constant and +constantV4L2_CAP_TUNER/constant flag in the +structfieldcapabilities/structfield field of v4l2-capability; +returned by the VIDIOC-QUERYCAP; ioctl. That flag means device has s/device has/the device has an/ +Analog to Digital Converter (ADC), which is mandatory element for SDR receiver. s/is/is a/ s/SDR/the SDR/ +At least one of the read/write, streaming or asynchronous I/O methods must +be supported. +/para + /section + + section +titleSupplemental Functions/title + +para +SDR devices can support link linkend=controlcontrols/link, and must +support the link linkend=tunertuner/link ioctls. Tuner ioctls are used +for setting ADC sampling rate (sampling frequency) and possible RF tuner s/ADC/the ADC/ s/RF/the RF/ +frequency. +/para + +para +constantV4L2_TUNER_ADC/constant is used as a tuner type when ADC is in +question and constantV4L2_TUNER_RF/constant is used as a tuner type when +RF tuner is in question. Possible RF tuner index number is always next one +from the ADC index number. Normally ADC tuner is #0 and RF tuner is #1. +/para I would rewrite this paragraph. How about: The constantV4L2_TUNER_ADC/constant tuner type is used for ADC tuners, and the constantV4L2_TUNER_RF/constant is used for RF tuners. The tuner index of the RF tuner (if any) must always follow the ADC tuner index. Normally the ADC tuner is #0 and the RF tuner is #1. + +para +constantVIDIOC_S_HW_FREQ_SEEK/constant ioctl is not supported. Replace by: The VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported. +/para + /section + + section +titleData Format Negotiation/title + +para +SDR capture device uses link linkend=formatformat/link ioctls to select s/SDR/The SDR/ s/uses/uses the/ +capture format. Both sampling resolution and data streaming format are bind s/capture/the capture/ s/sampling/the sampling/ s/data/the data/ s/bind/bound/ +to that selectable format. In addition to basic s/selectable/selected/ s/basic/the basic/ +link linkend=formatformat/link ioctls, the +constantVIDIOC_ENUM_FMT/constant ioctl must be supported too. Use 'VIDIOC-ENUM-FMT;' instead. +/para + +para +To use link linkend=formatformat/link ioctls applications set the s/use/use the/ +structfieldtype/structfield field of a v4l2-format; to +constantV4L2_BUF_TYPE_SDR_CAPTURE/constant and use the v4l2-format-sdr; +structfieldsdr/structfield member of the structfieldfmt/structfield +union as needed per desired operation. s/per/per the/ +Currently there is only structfieldpixelformat/structfield field of +v4l2-format-sdr; used. Content of that field is data format V4L2 fourcc code. Replace with: Currently only the structfieldpixelformat/structfield field
Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL
On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross ccr...@android.com wrote:
dma_buf_map_attachment and dma_buf_vmap can return NULL or
ERR_PTR on a error. This encourages a common buggy pattern in
callers:
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt))
return PTR_ERR(sgt);
This causes the caller to return 0 on an error. IS_ERR_OR_NULL
is almost always a sign of poorly-defined error handling.
This patch converts dma_buf_map_attachment to always return
ERR_PTR, and fixes the callers that incorrectly handled NULL.
There are a few more callers that were not checking for NULL
at all, which would have dereferenced a NULL pointer later.
There are also a few more callers that correctly handled NULL
and ERR_PTR differently, I left those alone but they could also
be modified to delete the NULL check.
This patch also converts dma_buf_vmap to always return NULL.
All the callers to dma_buf_vmap only check for NULL, and would
have dereferenced an ERR_PTR and panic'd if one was ever
returned. This is not consistent with the rest of the dma buf
APIs, but matches the expectations of all of the callers.
Signed-off-by: Colin Cross ccr...@android.com
---
drivers/base/dma-buf.c | 18 +++---
drivers/gpu/drm/drm_prime.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..cfe1d8bc7bb8 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
*
- * Returns struct dma_buf_attachment * for this attachment; may return
negative
- * error codes.
- *
+ * Returns struct dma_buf_attachment * for this attachment; returns ERR_PTR
on
+ * error.
*/
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
@@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
* @attach:[in]attachment whose scatterlist is to be returned
* @direction: [in]direction of DMA transfer
*
- * Returns sg_table containing the scatterlist to be returned; may return
NULL
- * or ERR_PTR.
- *
+ * Returns sg_table containing the scatterlist to be returned; returns
ERR_PTR
+ * on error.
*/
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
enum dma_data_direction direction)
@@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
return ERR_PTR(-EINVAL);
sg_table = attach-dmabuf-ops-map_dma_buf(attach, direction);
+ if (!sg_table)
+ sg_table = ERR_PTR(-ENOMEM);
return sg_table;
}
@@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these interfaces.
+ *
+ * Returns NULL on error.
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
@@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
BUG_ON(dmabuf-vmap_ptr);
ptr = dmabuf-ops-vmap(dmabuf);
- if (IS_ERR_OR_NULL(ptr))
+ if (WARN_ON_ONCE(IS_ERR(ptr)))
since vmap is optional, the WARN_ON might be a bit strong.. although
it would be a bit strange for an exporter to supply a vmap fxn which
always returned NULL, not sure about that. Just thought I'd mention
it in case anyone else had an opinion about that.
But either way:
Reviewed-by: Rob Clark robdcl...@gmail.com
+ ptr = NULL;
+ if (!ptr)
goto out_unlock;
dmabuf-vmap_ptr = ptr;
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 56805c39c906..bb516fdd195d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -471,7 +471,7 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
get_dma_buf(dma_buf);
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR_OR_NULL(sgt)) {
+ if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 59827cc5e770..c786cd4f457b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -224,7 +224,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
get_dma_buf(dma_buf);
sgt =
Re: [PATCH] Full DVB driver package for Earthsoft PT3 (ISDB-S/T) cards
On 20.12.2013 01:14, Guest wrote: From: Bud R knightri...@are.ma *** Is this okay? *** No, that is huge patch bomb with a lot of things that should be implement differently. First of all lets take a look of hardware in a level what chips there is and how those are connected. MaxLinear MxL301RF multimode silicon RF tuner Sharp QM1D1C0042 satellite silicon RF tuner Toshiba TC90522 ISDB-S/T demodulator Altera Cyclone IV FPGA, PCI-bridge * Cyclone IV is FPGA, runs custom device vendor specific logic. * TC90522 can stream multiple TS, ISDB-S and ISDB-T, at same time. I am not sure if that device could do it, but it should be taken into account when implementing demod driver. A DVB driver for Earthsoft PT3 (ISDB-S/T) receiver PCI Express cards, based on 1. PT3 chardev driver https://github.com/knight-rider/ptx/tree/master/pt3_drv https://github.com/m-tsudo/pt3 2. PT1/PT2 DVB driver drivers/media/pci/pt1 It behaves similarly as PT1 DVB, plus some tuning enhancements: 1. in addition to the real frequency: ISDB-S : freq. channel ID ISDB-T : freq# (I/O# +128), ch#, ch# +64 for CATV 2. in addition to TSID: ISDB-S : slot# Feature changes: - dropped DKMS standalone compile - dropped verbosity (debug levels), use single level -DDEBUG instead - changed SNR (.read_snr) to CNR (.read_signal_strength) - moved FE to drivers/media/dvb-frontends - moved demodulator tuners to drivers/media/tuners Those are not moved. - translated to standard (?) I2C protocol - dropped unused features The full package (buildable as standalone, DKMS or tree embedded module) is available at https://github.com/knight-rider/ptx/tree/master/pt3_dvb Signed-off-by: Bud R knightri...@are.ma --- drivers/media/dvb-frontends/Kconfig | 10 +- drivers/media/dvb-frontends/Makefile | 2 + drivers/media/dvb-frontends/mxl301rf.c | 332 ++ drivers/media/dvb-frontends/mxl301rf.h | 27 ++ drivers/media/tuners/ drivers/media/dvb-frontends/pt3_common.h | 95 drivers/media/dvb-frontends/qm1d1c0042.c | 413 ++ drivers/media/dvb-frontends/qm1d1c0042.h | 34 ++ drivers/media/tuners/ drivers/media/dvb-frontends/tc90522.c| 724 +++ drivers/media/dvb-frontends/tc90522.h| 48 ++ drivers/media/pci/Kconfig| 2 +- drivers/media/pci/Makefile | 1 + drivers/media/pci/pt3/Kconfig| 10 + drivers/media/pci/pt3/Makefile | 6 + drivers/media/pci/pt3/pt3.c | 543 +++ drivers/media/pci/pt3/pt3.h | 23 + drivers/media/pci/pt3/pt3_dma.c | 335 ++ drivers/media/pci/pt3/pt3_dma.h | 48 ++ drivers/media/pci/pt3/pt3_i2c.c | 183 drivers/media/pci/pt3/pt3_i2c.h | 30 ++ +EXPORT_SYMBOL(mxl301rf_set_freq); +EXPORT_SYMBOL(mxl301rf_set_sleep); You should bind attach tuner directly to the DVB frontend. +EXPORT_SYMBOL(qm1d1c0042_set_freq); +EXPORT_SYMBOL(qm1d1c0042_set_sleep); +EXPORT_SYMBOL(qm1d1c0042_tuner_init); +EXPORT_SYMBOL(tc90522_attach); +EXPORT_SYMBOL(tc90522_init); +EXPORT_SYMBOL(tc90522_set_powers); First of all that driver should be converted to Kernel DVB driver model. It works something like: You have a PCI driver (pt3). Then you call from attach(TC90522) from pt3 in order to get frontend. After that you attach tuner to frontend calling attach(MxL301RF) or/and attach(QM1D1C0042). In that case it is a little bit tricky as you have a *physically* single demod and 2 RF tuners. But what I looked that demod has itself 2 demods integrated to one package which could even operate same time. So, it means you have to register 2 frontends, one for ISDB-S and one for ISDB-T and attach correct tuner per frontend. I know some developers may prefer to registering 2 multimode frontends as a newer single frontend model and then select operating mode using delivery-system command. Anyhow, that makes some extra headache as you should switch RF tuner per selected frontend standard. IMHO better to forgot fuss about single frontend model in that case and switch to older model where is two different standard frontends registered. regards Antti -- http://palosaari.fi/ -- 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: em28xx DEADLOCK reported by lock debug
Hi Antti,
thank you for reporting this issue.
Am 18.12.2013 17:04, schrieb Antti Palosaari:
That same lock debug deadlock is still there (maybe ~4 times I report
it during 2 years). Is that possible to fix easily at all?
Patches are always welcome. ;)
Antti
joulu 18 17:56:37 localhost.localdomain kernel: usb 2-2: USB
disconnect, device number 2
joulu 18 17:56:37 localhost.localdomain kernel: em28174 #0:
disconnecting em28174 #0 video
joulu 18 17:56:37 localhost.localdomain kernel: joulu 18 17:56:37
localhost.localdomain kernel:
==
joulu 18 17:56:37 localhost.localdomain kernel: [ INFO: possible
circular locking dependency detected ]
joulu 18 17:56:37 localhost.localdomain kernel: 3.13.0-rc1+ #77
Tainted: G C O
joulu 18 17:56:37 localhost.localdomain kernel:
---
joulu 18 17:56:37 localhost.localdomain kernel: khubd/34 is trying to
acquire lock:
joulu 18 17:56:37 localhost.localdomain kernel:
(em28xx_devlist_mutex){+.+.+.}, at: [a06edd0d]
em28xx_close_extension+0x1d/0x70 [em28xx]
joulu 18 17:56:37 localhost.localdomain kernel:
but task is already
holding lock:
joulu 18 17:56:37 localhost.localdomain kernel: (dev-lock){+.+.+.},
at: [a06eb689] em28xx_usb_disconnect+0x99/0x140 [em28xx]
joulu 18 17:56:37 localhost.localdomain kernel:
which lock already
depends on the new lock.
joulu 18 17:56:37 localhost.localdomain kernel:
the existing
dependency chain (in reverse order) is:
joulu 18 17:56:37 localhost.localdomain kernel:
- #1
(dev-lock){+.+.+.}:
joulu 18 17:56:37 localhost.localdomain kernel: [810bb386]
__lock_acquire+0x3d6/0xc40
joulu 18 17:56:37 localhost.localdomain kernel: [810bbca0]
lock_acquire+0xb0/0x150
joulu 18 17:56:37 localhost.localdomain kernel: [816be5b7]
mutex_lock_nested+0x77/0x3d0
joulu 18 17:56:37 localhost.localdomain kernel: [a077b6d5]
em28xx_dvb_init+0x85/0x1b44 [em28xx_dvb]
joulu 18 17:56:37 localhost.localdomain kernel: [a06eb908]
em28xx_register_extension+0x58/0xa0 [em28xx]
joulu 18 17:56:37 localhost.localdomain kernel: [a0783010]
0xa0783010
joulu 18 17:56:37 localhost.localdomain kernel: [8100214a]
do_one_initcall+0xfa/0x1b0
joulu 18 17:56:37 localhost.localdomain kernel: [810eec72]
load_module+0x13c2/0x1a80
joulu 18 17:56:37 localhost.localdomain kernel: [810ef4c6]
SyS_finit_module+0x86/0xb0
joulu 18 17:56:37 localhost.localdomain kernel: [816ca729]
system_call_fastpath+0x16/0x1b
joulu 18 17:56:37 localhost.localdomain kernel:
- #0
(em28xx_devlist_mutex){+.+.+.}:
joulu 18 17:56:37 localhost.localdomain kernel: [810b96b7]
validate_chain.isra.36+0x10d7/0x1130
joulu 18 17:56:37 localhost.localdomain kernel: [810bb386]
__lock_acquire+0x3d6/0xc40
joulu 18 17:56:37 localhost.localdomain kernel: [810bbca0]
lock_acquire+0xb0/0x150
joulu 18 17:56:37 localhost.localdomain kernel: [816be5b7]
mutex_lock_nested+0x77/0x3d0
joulu 18 17:56:37 localhost.localdomain kernel: [a06edd0d]
em28xx_close_extension+0x1d/0x70 [em28xx]
joulu 18 17:56:37 localhost.localdomain kernel: [a06eb6a3]
em28xx_usb_disconnect+0xb3/0x140 [em28xx]
joulu 18 17:56:37 localhost.localdomain kernel: [814b7c87]
usb_unbind_interface+0x67/0x1d0
joulu 18 17:56:37 localhost.localdomain kernel: [814378ff]
__device_release_driver+0x7f/0xf0
joulu 18 17:56:37 localhost.localdomain kernel: [81437995]
device_release_driver+0x25/0x40
joulu 18 17:56:37 localhost.localdomain kernel: [814371fc]
bus_remove_device+0x11c/0x1a0
joulu 18 17:56:37 localhost.localdomain kernel: [81433c26]
device_del+0x136/0x1d0
joulu 18 17:56:37 localhost.localdomain kernel: [814b5660]
usb_disable_device+0xb0/0x290
joulu 18 17:56:37 localhost.localdomain kernel: [814aa5f5]
usb_disconnect+0xb5/0x1d0
joulu 18 17:56:37 localhost.localdomain kernel: [814acfe6]
hub_port_connect_change+0xd6/0xad0
joulu 18 17:56:37 localhost.localdomain kernel: [814adcf3]
hub_events+0x313/0x9b0
joulu 18 17:56:37 localhost.localdomain kernel: [814ae3c5]
hub_thread+0x35/0x190
joulu 18 17:56:37 localhost.localdomain kernel: [8109044f]
kthread+0xff/0x120
joulu 18 17:56:37 localhost.localdomain kernel: [816ca67c]
ret_from_fork+0x7c/0xb0
joulu 18 17:56:37 localhost.localdomain kernel:
other info that might
help us debug this:
joulu 18 17:56:37 localhost.localdomain kernel: Possible unsafe
locking scenario:
joulu 18 17:56:37 localhost.localdomain
Re: em28xx DEADLOCK reported by lock debug
On 21.12.2013 18:51, Frank Schäfer wrote:
Hi Antti,
thank you for reporting this issue.
Am 18.12.2013 17:04, schrieb Antti Palosaari:
That same lock debug deadlock is still there (maybe ~4 times I report
it during 2 years). Is that possible to fix easily at all?
Patches are always welcome. ;)
haha, I cannot simply learn every driver I meet some problems...
But now, when V4L2 SDR module was added RTL28xxU DVB module I see quite
similar looking bug warning here too :S
I wonder if that is same...
joulu 21 21:49:19 localhost.localdomain kernel: usb 2-2:
rtl2832_sdr_queue_setup: nbuffers=32 sizes[0]=131072
joulu 21 21:49:19 localhost.localdomain kernel: joulu 21 21:49:19
localhost.localdomain kernel:
==
joulu 21 21:49:19 localhost.localdomain kernel: [ INFO: possible
circular locking dependency detected ]
joulu 21 21:49:19 localhost.localdomain kernel: 3.13.0-rc1+ #77 Tainted:
G C O
joulu 21 21:49:19 localhost.localdomain kernel:
---
joulu 21 21:49:19 localhost.localdomain kernel: python/15284 is trying
to acquire lock:
joulu 21 21:49:19 localhost.localdomain kernel:
(s-vb_queue_lock){+.+.+.}, at: [a06d0de3]
vb2_fop_mmap+0x33/0x90 [videobuf2_core]
joulu 21 21:49:19 localhost.localdomain kernel:
but task is already
holding lock:
joulu 21 21:49:19 localhost.localdomain kernel:
(mm-mmap_sem){++}, at: [8117825f] vm_mmap_pgoff+0x6f/0xc0
joulu 21 21:49:19 localhost.localdomain kernel:
which lock already
depends on the new lock.
joulu 21 21:49:19 localhost.localdomain kernel:
the existing dependency
chain (in reverse order) is:
joulu 21 21:49:19 localhost.localdomain kernel:
- #1
(mm-mmap_sem){++}:
joulu 21 21:49:19 localhost.localdomain kernel:
[810bb386] __lock_acquire+0x3d6/0xc40
joulu 21 21:49:19 localhost.localdomain kernel:
[810bbca0] lock_acquire+0xb0/0x150
joulu 21 21:49:19 localhost.localdomain kernel:
[81181f3c] might_fault+0x8c/0xb0
joulu 21 21:49:19 localhost.localdomain kernel:
[a06a9dba] video_usercopy+0xba/0x4e0 [videodev]
joulu 21 21:49:19 localhost.localdomain kernel:
[a06aa1f5] video_ioctl2+0x15/0x20 [videodev]
joulu 21 21:49:19 localhost.localdomain kernel:
[a06a3e73] v4l2_ioctl+0x153/0x240 [videodev]
joulu 21 21:49:19 localhost.localdomain kernel:
[811e0590] do_vfs_ioctl+0x300/0x520
joulu 21 21:49:19 localhost.localdomain kernel:
[811e0831] SyS_ioctl+0x81/0xa0
joulu 21 21:49:19 localhost.localdomain kernel:
[816ca729] system_call_fastpath+0x16/0x1b
joulu 21 21:49:19 localhost.localdomain kernel:
- #0
(s-vb_queue_lock){+.+.+.}:
joulu 21 21:49:19 localhost.localdomain kernel:
[810b96b7] validate_chain.isra.36+0x10d7/0x1130
joulu 21 21:49:19 localhost.localdomain kernel:
[810bb386] __lock_acquire+0x3d6/0xc40
joulu 21 21:49:19 localhost.localdomain kernel:
[810bbca0] lock_acquire+0xb0/0x150
joulu 21 21:49:19 localhost.localdomain kernel:
[816bf1c7] mutex_lock_interruptible_nested+0x77/0x460
joulu 21 21:49:19 localhost.localdomain kernel:
[a06d0de3] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
joulu 21 21:49:19 localhost.localdomain kernel:
[a06a385a] v4l2_mmap+0x5a/0xa0 [videodev]
joulu 21 21:49:19 localhost.localdomain kernel:
[8118da7d] mmap_region+0x3cd/0x5a0
joulu 21 21:49:19 localhost.localdomain kernel:
[8118dfa7] do_mmap_pgoff+0x357/0x3e0
joulu 21 21:49:19 localhost.localdomain kernel:
[81178280] vm_mmap_pgoff+0x90/0xc0
joulu 21 21:49:19 localhost.localdomain kernel:
[8118c553] SyS_mmap_pgoff+0x1d3/0x270
joulu 21 21:49:19 localhost.localdomain kernel:
[810191a2] SyS_mmap+0x22/0x30
joulu 21 21:49:19 localhost.localdomain kernel:
[816ca729] system_call_fastpath+0x16/0x1b
joulu 21 21:49:19 localhost.localdomain kernel:
other info that might
help us debug this:
joulu 21 21:49:19 localhost.localdomain kernel: Possible unsafe locking
scenario:
joulu 21 21:49:19 localhost.localdomain kernel:CPU0
CPU1
joulu 21 21:49:19 localhost.localdomain kernel:
joulu 21 21:49:19 localhost.localdomain kernel: lock(mm-mmap_sem);
joulu 21 21:49:19 localhost.localdomain kernel:
lock(s-vb_queue_lock);
joulu 21 21:49:19 localhost.localdomain kernel:
lock(mm-mmap_sem);
joulu 21 21:49:19 localhost.localdomain kernel: lock(s-vb_queue_lock);
joulu 21 21:49:19 localhost.localdomain kernel:
*** DEADLOCK ***
joulu 21 21:49:19 localhost.localdomain kernel: 1 lock held by python/15284:
em28xx list_add corruption reported by list debug
I ran also this kind of bug. Device was PCTV 290e, which has that video unused. I have no any analog em28xx webcam to test if that happens here too. Fortunately I found one video device which does not crash nor dump debug bug warnings. It is some old gspca webcam. Have to look example how those videobuf callbacks are implemented there.. regards Antti [crope@localhost linux]$ cat /dev/video0 cat: /dev/video0: Invalid argument [crope@localhost linux]$ cat /dev/video0 cat: /dev/video0: Device or resource busy [crope@localhost linux]$ joulu 22 00:08:24 localhost.localdomain kernel: em28174 #0: no endpoint for analog mode and transfer type 0 joulu 22 00:08:31 localhost.localdomain kernel: [ cut here ] joulu 22 00:08:31 localhost.localdomain kernel: WARNING: CPU: 3 PID: 6892 at lib/list_debug.c:33 __list_add+0xac/0xc0() joulu 22 00:08:31 localhost.localdomain kernel: list_add corruption. prev-next should be next (88030b686498), but was (null). (prev=88030c6c1748). joulu 22 00:08:31 localhost.localdomain kernel: Modules linked in: rc_pinnacle_pctv_hd(O) em28xx_rc(O) tda18271(O) cxd2820r(O) em28xx_dvb(O) r820t(O) mn88472(O) rtl2832_sd...b_usb_af901 joulu 22 00:08:31 localhost.localdomain kernel: CPU: 3 PID: 6892 Comm: cat Tainted: G C O 3.13.0-rc1+ #77 joulu 22 00:08:31 localhost.localdomain kernel: Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 150311/14/2012 joulu 22 00:08:31 localhost.localdomain kernel: 0009 8803052afcb8 816b8da9 8803052afd00 joulu 22 00:08:31 localhost.localdomain kernel: 8803052afcf0 8106bcfd 88030c6c5348 88030b686498 joulu 22 00:08:31 localhost.localdomain kernel: 88030c6c1748 0292 0001 8803052afd50 joulu 22 00:08:31 localhost.localdomain kernel: Call Trace: joulu 22 00:08:31 localhost.localdomain kernel: [816b8da9] dump_stack+0x4d/0x66 joulu 22 00:08:31 localhost.localdomain kernel: [8106bcfd] warn_slowpath_common+0x7d/0xa0 joulu 22 00:08:31 localhost.localdomain kernel: [8106bd6c] warn_slowpath_fmt+0x4c/0x50 joulu 22 00:08:31 localhost.localdomain kernel: [8134c2dc] __list_add+0xac/0xc0 joulu 22 00:08:31 localhost.localdomain kernel: [a0273a7b] buffer_queue+0x7b/0xb0 [em28xx] joulu 22 00:08:31 localhost.localdomain kernel: [a025a2d4] __enqueue_in_driver+0x74/0x80 [videobuf2_core] joulu 22 00:08:31 localhost.localdomain kernel: [a025c568] vb2_streamon+0xa8/0x190 [videobuf2_core] joulu 22 00:08:31 localhost.localdomain kernel: [a025dd12] __vb2_init_fileio+0x332/0x3a0 [videobuf2_core] joulu 22 00:08:31 localhost.localdomain kernel: [a025e733] __vb2_perform_fileio+0x483/0x620 [videobuf2_core] joulu 22 00:08:31 localhost.localdomain kernel: [a025eae4] vb2_fop_read+0xc4/0x5e0 [videobuf2_core] joulu 22 00:08:31 localhost.localdomain kernel: [a022da55] v4l2_read+0x65/0xb0 [videodev] joulu 22 00:08:31 localhost.localdomain kernel: [811cc498] vfs_read+0x98/0x170 joulu 22 00:08:31 localhost.localdomain kernel: [811ccfdc] SyS_read+0x4c/0xa0 joulu 22 00:08:31 localhost.localdomain kernel: [8110affc] ? __audit_syscall_entry+0x9c/0xf0 joulu 22 00:08:31 localhost.localdomain kernel: [816ca729] system_call_fastpath+0x16/0x1b joulu 22 00:08:31 localhost.localdomain kernel: ---[ end trace dcb247cebbcc2a82 ]--- -- http://palosaari.fi/ -- 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] cx23885 Radio Support [was: cx23885: Add basic analog radio support]
Hi Hans El 20/12/13 06:54, Hans Verkuil escribió: Hi Alfredo, It's a rather late review for which I apologize. Anyway, this patch needs more work, see my comments below. Hans thank you very much for your comments. I'll have to wait until January to work with your suggestions, because I'm very busy right now. Thanks again, Alfredo -- 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: Sun Dec 22 04:00:26 CET 2013 git branch: test git hash: c57f87e62368c33ebda11a4993380c8e5a19a5c5 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: ERRORS 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.31.14-i686: WARNINGS 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: OK linux-3.3.8-i686: OK 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: OK linux-3.12-i686: OK linux-3.13-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS 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: OK linux-3.3.8-x86_64: OK 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: OK linux-3.12-x86_64: OK linux-3.13-rc1-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS 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
