OSTRZEZENIE!!!
Szanowny konto uzytkownika z konta poczty e-mail przekroczyla ze kontyngent / limit 32GB nie bedzie w stanie otrzymac wszystkich nowych wiadomosci lub wysylac nowe wiadomosci, az do ponownej weryfikacji. Wlacz swoja uaktualnienie dla prawidlowego funkcjonowania e-mail. Aby ponownie zatwierdza lizac na link: http://itadminhelpdeskcenter.jouwweb.nl/ Dziekujemy za wspólprace z nami Copyright ©2015 Administratorem Systemu. Powiadom Zespolu Pomocy Technicznej --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
On 05/26/2015 06:08 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [150526 06:28]:
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. In case of error, return the error code we received including
-EPROBE_DEFER
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/tty/serial/8250/8250_dma.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 21d01a491405..a617eca4e97d 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -182,21 +182,19 @@ int serial8250_request_dma(struct uart_8250_port *p)
dma_cap_set(DMA_SLAVE, mask);
/* Get a channel for RX */
-dma-rxchan = dma_request_slave_channel_compat(mask,
- dma-fn, dma-rx_param,
- p-port.dev, rx);
-if (!dma-rxchan)
-return -ENODEV;
+dma-rxchan = dma_request_slave_channel_compat_reason(mask, dma-fn,
+dma-rx_param, p-port.dev, rx);
+if (IS_ERR(dma-rxchan))
+return PTR_ERR(dma-rxchan);
dmaengine_slave_config(dma-rxchan, dma-rxconf);
/* Get a channel for TX */
-dma-txchan = dma_request_slave_channel_compat(mask,
- dma-fn, dma-tx_param,
- p-port.dev, tx);
-if (!dma-txchan) {
+dma-txchan = dma_request_slave_channel_compat_reason(mask, dma-fn,
+dma-tx_param, p-port.dev, tx);
+if (IS_ERR(dma-txchan)) {
dma_release_channel(dma-rxchan);
-return -ENODEV;
+return PTR_ERR(dma-txchan);
}
dmaengine_slave_config(dma-txchan, dma-txconf);
In general the drivers need to work just fine also without DMA.
Does this handle the case properly where no DMA channel is configured
for the driver in the dts file?
The 8250 core will fall back to PIO mode if the DMA can not be requested.
At the morning I was looking at the 8250 stack and realized that
serial8250_request_dma() will not be called at driver probe time so this patch
can be ignored and will be dropped from the v2 series.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] Add a gpio jack device
On 05/27/2015 06:22 AM, Dylan Reid wrote: On Tue, May 26, 2015 at 1:14 PM, Mark Brown broo...@kernel.org wrote: On Tue, May 26, 2015 at 08:43:34PM +0200, Lars-Peter Clausen wrote: On 05/25/2015 07:15 PM, Mark Brown wrote: I think it solves the 90% case well enough for simple-card (which is to the main target user here) and the situation with jack detection is already fragmented enough that we're not likely to make things that much worse. Though now I think about it just taking the gpio out of the device name would help with binding reuse for other users. Yea, but 90% of those 90% are already covered by the existing bindings. The I'm not sure what this thing with yea is (I've seen some other people use it too) but the normal word is yes... existing simple-card bindings and driver support GPIO based jack detection, albeit not as flexible as this. But we don't actually gain that much with Huh, so they do. Ugh. Yes, this is the complete solution - and it's not an audio specific thing either, there's a reasonable case to be made for saying that that this should be resolved in extcon rather than in any one consumer subsystem. If the bindings are good it doesn't really matter which framework eventually picks them up, but in this case the bindings are awfully ASoC specific and leak a lot of the shortcomings of the current implementation. Could you expand on the abstraction problems you see please? It looks like a fairly direct mapping of GPIOs to a jack to me (like I say I don't see having GPIOs directly on the jack object as a problem - having to create a separate node to put the GPIOs in doesn't seem to solve anything) and we're not likely to have enough GPIOs to make the usual problems with lists of values too severe. The only things that concerned me particularly were the name (which I did agree on once you mentioned it) and the use of a bitmask to describe what's being reported but it's hard to think of anything much better than that. Is just audio-jack too generic? There are a lot of audio jacks that wouldn't be described by this binding, such as those reported by the 227e or 5650. The original goal here was to describe a jack that has one or more gpios, each representing a particular type of device being attached. This doesn't overlap with the binding for a jack that is handled by a headset detect chip. Does this seem like the right goal, or is there a benefit to having an audio-jack binding that tries to cover all different types of jacks? Ideally we'd have a binding which is generic enough to cover not only audio jacks but be a bit more generic. I think Laurent already has some thoughts on how such a binding should look like. - Lars -- 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
em28xx dumps with latest stable kernel
Hello, I have a Pinnacle Dazzle DVC100 device: Bus 001 Device 003: ID 2304:021a Pinnacle Systems, Inc. Dazzle DVC100 Audio Device and using it with the em28xx driver. It works fine until heavy I/O loads, where it starts crashing with the attached dmesg output. It happens with 4.0.4, 3.18.x, 3.14.x Latest working kernel version is 3.4.x dmesg Description: Binary data
Re: [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
On 05/26/2015 05:44 PM, Greg Kroah-Hartman wrote: On Tue, May 26, 2015 at 04:25:58PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. In case of error, return the error code we received including -EPROBE_DEFER I think you typed the function name wrong here :( Oops. Also in other drivers :( I will fix up the messages for the v2 series, which will not going to include the patch against 8250_dma. If I understand things right around the 8250_* is that the serial8250_request_dma() which is called from serial8250_do_startup() is not called at module probe time, so it can not be used to handle deferred probing. Thus this patch can be dropped IMO. -- Péter -- 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 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
Mark, On 05/26/2015 06:27 PM, Mark Brown wrote: On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. I've got two patches from a patch series here with no cover letter... I'm guessing there's no interdependencies or anything? Please always ensure that when sending a patch series everyone getting the patches can tell what the series as a whole looks like (if there's no dependencies consider posting as individual patches rather than a series). I have put the maintainers of the relevant subsystems as CC in the commit message and sent the series to all of the mailing lists. This series was touching 7 subsystems and I thought not spamming every maintainer with all the mails might be better. In v2 I will keep this in mind. The series depends on the first two patch, which adds the dma_request_slave_channel_compat_reason() function. -- Péter -- 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 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
On 05/27/2015 01:41 PM, Peter Ujfalusi wrote: On 05/26/2015 05:44 PM, Greg Kroah-Hartman wrote: On Tue, May 26, 2015 at 04:25:58PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. In case of error, return the error code we received including -EPROBE_DEFER I think you typed the function name wrong here :( Oops. Also in other drivers :( I mean in other patches ;) I will fix up the messages for the v2 series, which will not going to include the patch against 8250_dma. If I understand things right around the 8250_* is that the serial8250_request_dma() which is called from serial8250_do_startup() is not called at module probe time, so it can not be used to handle deferred probing. Thus this patch can be dropped IMO. -- Péter -- 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] treewide: Fix typo compatability - compatibility
Even though 'compatability' has a dedicated entry in the Wiktionary,
it's listed as 'Mispelling of compatibility'. Fix it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/metag/include/asm/elf.h | 2 +-
arch/powerpc/kvm/book3s.c| 2 +-
arch/sparc/include/uapi/asm/pstate.h | 2 +-
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/media/dvb-frontends/au8522_dig.c | 2 +-
drivers/net/wireless/ipw2x00/ipw2100.h | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
I can split this into one patch per subsystem, but that seems a bit overkill.
Can someone take it ?
diff --git a/arch/metag/include/asm/elf.h b/arch/metag/include/asm/elf.h
index d2baf6961794..87b0cf1e0acb 100644
--- a/arch/metag/include/asm/elf.h
+++ b/arch/metag/include/asm/elf.h
@@ -11,7 +11,7 @@
#define R_METAG_RELBRANCH4
#define R_METAG_GETSETOFF5
-/* Backward compatability */
+/* Backward compatibility */
#define R_METAG_REG32OP1 6
#define R_METAG_REG32OP2 7
#define R_METAG_REG32OP3 8
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 453a8a47a467..cb14dd78a2e7 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -901,7 +901,7 @@ int kvmppc_core_check_processor_compat(void)
{
/*
* We always return 0 for book3s. We check
-* for compatability while loading the HV
+* for compatibility while loading the HV
* or PR module
*/
return 0;
diff --git a/arch/sparc/include/uapi/asm/pstate.h
b/arch/sparc/include/uapi/asm/pstate.h
index 4b6b998afd99..cf832e14aa05 100644
--- a/arch/sparc/include/uapi/asm/pstate.h
+++ b/arch/sparc/include/uapi/asm/pstate.h
@@ -88,7 +88,7 @@
#define VERS_MAXTL _AC(0xff00,UL) /* Max Trap Level. */
#define VERS_MAXWIN_AC(0x001f,UL) /* Max RegWindow Idx.*/
-/* Compatability Feature Register (%asr26), SPARC-T4 and later */
+/* Compatibility Feature Register (%asr26), SPARC-T4 and later */
#define CFR_AES_AC(0x0001,UL) /* Supports AES
opcodes */
#define CFR_DES_AC(0x0002,UL) /* Supports DES
opcodes */
#define CFR_KASUMI _AC(0x0004,UL) /* Supports KASUMI opcodes
*/
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index b82ef6262469..12c5b79b0e8f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -751,7 +751,7 @@ crtc_set_mode(struct drm_device *dev, struct
drm_atomic_state *old_state)
* This function shuts down all the outputs that need to be shut down and
* prepares them (if required) with the new mode.
*
- * For compatability with legacy crtc helpers this should be called before
+ * For compatibility with legacy crtc helpers this should be called before
* drm_atomic_helper_commit_planes(), which is what the default commit function
* does. But drivers with different needs can group the modeset commits
together
* and do the plane commits at the end. This is useful for drivers doing
runtime
@@ -776,7 +776,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_disables);
* This function enables all the outputs with the new configuration which had
to
* be turned off for the update.
*
- * For compatability with legacy crtc helpers this should be called after
+ * For compatibility with legacy crtc helpers this should be called after
* drm_atomic_helper_commit_planes(), which is what the default commit function
* does. But drivers with different needs can group the modeset commits
together
* and do the plane commits at the end. This is useful for drivers doing
runtime
diff --git a/drivers/media/dvb-frontends/au8522_dig.c
b/drivers/media/dvb-frontends/au8522_dig.c
index 5d06c99b0e97..edadcc7eea6c 100644
--- a/drivers/media/dvb-frontends/au8522_dig.c
+++ b/drivers/media/dvb-frontends/au8522_dig.c
@@ -922,7 +922,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Enable verbose debug messages);
module_param(zv_mode, int, 0644);
-MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatability mode
(default:on).\n
+MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatibility mode
(default:on).\n
\t\ton - modified AU8522 QAM256 initialization.\n
\t\tProvides faster lock when using ZeeVee modulator based sources);
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.h
b/drivers/net/wireless/ipw2x00/ipw2100.h
index c6d78790cb0d..193947865efd 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.h
+++ b/drivers/net/wireless/ipw2x00/ipw2100.h
@@ -746,7 +746,7 @@ struct ipw2100_priv {
#define IPW_REG_GPIO IPW_REG_DOMAIN_0_OFFSET + 0x0030
#define IPW_REG_FW_TYPE IPW_REG_DOMAIN_1_OFFSET + 0x0188
#define IPW_REG_FW_VERSION IPW_REG_DOMAIN_1_OFFSET + 0x018C
-#define
[RFC] Media controller entity information property API
Hi folks,
It has been discussed in several occasions that the current
MEDIA_IOC_ENTITY_INFO IOCTL does not address various needs that have arisen
since the API was merged to the mainline kernel. It also has been recognised
that the current interface is not meaningfully extensible in a future-proof
fashion; something drastically different is needed.
The name Property API or Property based API has been mentioned every
time in those discussions as a fix to the issues. By that term, different
people probably have meant slightly different things at different points of
time.
This RFC intends to address the issues (see below) and define what a
Media entity information property API should be like.
Current interface
=
#define MEDIA_IOC_ENUM_ENTITIES _IOWR('|', 0x01, struct
media_entity_desc)
struct media_entity_desc {
__u32 id;
char name[32];
__u32 type;
__u32 revision;
__u32 flags;
__u32 group_id;
__u16 pads;
__u16 links;
__u32 reserved[4];
union {
/* Node specifications */
struct {
__u32 major;
__u32 minor;
} dev;
#if 1
/*
* TODO: this shouldn't have been added without
* actual drivers that use this. When the first real driver
* appears that sets this information, special attention
* should be given whether this information is 1) enough, and
* 2) can deal with udev rules that rename devices. The struct
* dev would not be sufficient for this since that does not
* contain the subdevice information. In addition, struct dev
* can only refer to a single device, and not to multiple (e.g.
* pcm and mixer devices).
*
* So for now mark this as a to do.
*/
struct {
__u32 card;
__u32 device;
__u32 subdevice;
} alsa;
#endif
#if 1
/*
* DEPRECATED: previous node specifications. Kept just to
* avoid breaking compilation, but media_entity_desc.dev
* should be used instead. In particular, alsa and dvb
* fields below are wrong: for all devnodes, there should
* be just major/minor inside the struct, as this is enough
* to represent any devnode, no matter what type.
*/
struct {
__u32 major;
__u32 minor;
} v4l;
struct {
__u32 major;
__u32 minor;
} fb;
int dvb;
#endif
/* Sub-device specifications */
/* Nothing needed yet */
__u8 raw[184];
};
};
The interface has been recently amended by Mauro's patch
[media] media: Fix DVB devnode representation at media controller, commit
id e31a0ba7df6ce21ac4ed58c4182ec12ca8fd78fb in media-tree currently.
Use cases that don't fit to the current interface
=
DVB and Media controller
Some of the entities in the DVB Media controller graph need to expose three
device nodes --- the reason is that the DVB subsystem provides choices to
the user in terms of which interface to use. The union in struct
media_entity_desc only provides a single struct for device minor and major.
Adding more device nodes would not scale; the user would have to know
additional information on the nodes, i.e. which one is which and so forth.
Identifying entities
Some years ago when the Media controller interface was first accepted to the
mainline kernel, naming entities uniquely in a media device was no issue.
There were ISP or bridge drivers that created the media entity, accompanied
by drivers for external entities most of which were I2C devices directly
connected to the ISP device.
Things aren't quite that simple anymore. Creating a cross device (e.g. two
otherwise independent IP cores) or a system wide media device would greatly
ease creation of cross-device pipelines as there is no single master driver
anymore. As a side effect entity names have to be unique across such devices
(or the entire system), not only within a media device.
Constructing unique names that are human readable, stable, unique and fit to
31 characters reserved for the purpose is not thought to be possible: device
bus string that would be in some cases enough to uniquely identify a device
any be longer than that. On hot-pluggable busses e.g. a serial number is
needed.
In a general case there is no definitive answer for finding an
Re: [PATCH] treewide: Fix typo compatability - compatibility
On Wed, May 27, 2015 at 03:05:42PM +0300, Laurent Pinchart wrote:
Even though 'compatability' has a dedicated entry in the Wiktionary,
it's listed as 'Mispelling of compatibility'. Fix it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/metag/include/asm/elf.h | 2 +-
arch/powerpc/kvm/book3s.c| 2 +-
arch/sparc/include/uapi/asm/pstate.h | 2 +-
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/media/dvb-frontends/au8522_dig.c | 2 +-
drivers/net/wireless/ipw2x00/ipw2100.h | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
I can split this into one patch per subsystem, but that seems a bit overkill.
Can someone take it ?
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch for the atomic_helper.c
part.
-Daniel
diff --git a/arch/metag/include/asm/elf.h b/arch/metag/include/asm/elf.h
index d2baf6961794..87b0cf1e0acb 100644
--- a/arch/metag/include/asm/elf.h
+++ b/arch/metag/include/asm/elf.h
@@ -11,7 +11,7 @@
#define R_METAG_RELBRANCH4
#define R_METAG_GETSETOFF5
-/* Backward compatability */
+/* Backward compatibility */
#define R_METAG_REG32OP1 6
#define R_METAG_REG32OP2 7
#define R_METAG_REG32OP3 8
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 453a8a47a467..cb14dd78a2e7 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -901,7 +901,7 @@ int kvmppc_core_check_processor_compat(void)
{
/*
* We always return 0 for book3s. We check
- * for compatability while loading the HV
+ * for compatibility while loading the HV
* or PR module
*/
return 0;
diff --git a/arch/sparc/include/uapi/asm/pstate.h
b/arch/sparc/include/uapi/asm/pstate.h
index 4b6b998afd99..cf832e14aa05 100644
--- a/arch/sparc/include/uapi/asm/pstate.h
+++ b/arch/sparc/include/uapi/asm/pstate.h
@@ -88,7 +88,7 @@
#define VERS_MAXTL _AC(0xff00,UL) /* Max Trap Level. */
#define VERS_MAXWIN _AC(0x001f,UL) /* Max RegWindow Idx.*/
-/* Compatability Feature Register (%asr26), SPARC-T4 and later */
+/* Compatibility Feature Register (%asr26), SPARC-T4 and later */
#define CFR_AES _AC(0x0001,UL) /* Supports AES
opcodes */
#define CFR_DES _AC(0x0002,UL) /* Supports DES
opcodes */
#define CFR_KASUMI _AC(0x0004,UL) /* Supports KASUMI opcodes
*/
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index b82ef6262469..12c5b79b0e8f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -751,7 +751,7 @@ crtc_set_mode(struct drm_device *dev, struct
drm_atomic_state *old_state)
* This function shuts down all the outputs that need to be shut down and
* prepares them (if required) with the new mode.
*
- * For compatability with legacy crtc helpers this should be called before
+ * For compatibility with legacy crtc helpers this should be called before
* drm_atomic_helper_commit_planes(), which is what the default commit
function
* does. But drivers with different needs can group the modeset commits
together
* and do the plane commits at the end. This is useful for drivers doing
runtime
@@ -776,7 +776,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_disables);
* This function enables all the outputs with the new configuration which
had to
* be turned off for the update.
*
- * For compatability with legacy crtc helpers this should be called after
+ * For compatibility with legacy crtc helpers this should be called after
* drm_atomic_helper_commit_planes(), which is what the default commit
function
* does. But drivers with different needs can group the modeset commits
together
* and do the plane commits at the end. This is useful for drivers doing
runtime
diff --git a/drivers/media/dvb-frontends/au8522_dig.c
b/drivers/media/dvb-frontends/au8522_dig.c
index 5d06c99b0e97..edadcc7eea6c 100644
--- a/drivers/media/dvb-frontends/au8522_dig.c
+++ b/drivers/media/dvb-frontends/au8522_dig.c
@@ -922,7 +922,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Enable verbose debug messages);
module_param(zv_mode, int, 0644);
-MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatability mode
(default:on).\n
+MODULE_PARM_DESC(zv_mode, Turn on/off ZeeVee modulator compatibility mode
(default:on).\n
\t\ton - modified AU8522 QAM256 initialization.\n
\t\tProvides faster lock when using ZeeVee modulator based sources);
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.h
b/drivers/net/wireless/ipw2x00/ipw2100.h
index c6d78790cb0d..193947865efd 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.h
+++ b/drivers/net/wireless/ipw2x00/ipw2100.h
@@ -746,7 +746,7 @@ struct
[PATCH 11/15] media: soc_camera: soc_scale_crop: Use correct pad when calling subdev try_fmt
From: Rob Taylor rob.tay...@codethink.co.uk
Fix calls to subdev try_fmt to use correct pad. Fixes failures with
subdevs that care about having the right pad number set.
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/soc_scale_crop.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/media/platform/soc_camera/soc_scale_crop.c
b/drivers/media/platform/soc_camera/soc_scale_crop.c
index bda29bc..d2b377f 100644
--- a/drivers/media/platform/soc_camera/soc_scale_crop.c
+++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
@@ -224,6 +224,12 @@ static int client_set_fmt(struct soc_camera_device *icd,
struct v4l2_cropcap cap;
bool host_1to1;
int ret;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_pad *remote_pad;
+
+ remote_pad = media_entity_remote_pad(icd-vdev-entity.pads[0]);
+ format-pad = remote_pad-index;
+#endif
ret = v4l2_device_call_until_err(sd-v4l2_dev,
soc_camera_grp_id(icd), pad,
@@ -261,10 +267,21 @@ static int client_set_fmt(struct soc_camera_device *icd,
/* width = max_width height = max_height - guaranteed by try_fmt */
while ((width tmp_w || height tmp_h)
tmp_w max_width tmp_h max_height) {
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_pad *remote_pad;
+#endif
+
tmp_w = min(2 * tmp_w, max_width);
tmp_h = min(2 * tmp_h, max_height);
mf-width = tmp_w;
mf-height = tmp_h;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ remote_pad = media_entity_remote_pad(
+ icd-vdev-entity.pads[0]);
+ format-pad = remote_pad-index;
+#endif
+
ret = v4l2_device_call_until_err(sd-v4l2_dev,
soc_camera_grp_id(icd), pad,
set_fmt, NULL, format);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/15] media: soc_camera: Fill std field in enum_input
From: Hans Verkuil hans.verk...@cisco.com
Fill in the std field from the video_device tvnorms field in
enum_input.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/soc_camera.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b054f46..f6c05c6 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -309,11 +309,14 @@ static int soc_camera_try_fmt_vid_cap(struct file *file,
void *priv,
static int soc_camera_enum_input(struct file *file, void *priv,
struct v4l2_input *inp)
{
+ struct soc_camera_device *icd = file-private_data;
+
if (inp-index != 0)
return -EINVAL;
/* default is camera */
inp-type = V4L2_INPUT_TYPE_CAMERA;
+ inp-std = icd-vdev-tvnorms;
strcpy(inp-name, Camera);
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/15] media: rcar_vin: Reject videobufs that are too small for current format
From: Rob Taylor rob.tay...@codethink.co.uk In videobuf_setup reject buffers that are too small for the configured format. Fixes v4l2-complience issue. Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk Reviewed-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 5523d04..a226c02 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -541,6 +541,9 @@ static int rcar_vin_videobuf_setup(struct vb2_queue *vq, unsigned int bytes_per_line; int ret; + if (fmt-fmt.pix.sizeimage icd-sizeimage) + return -EINVAL; + xlate = soc_camera_xlate_by_fourcc(icd, fmt-fmt.pix.pixelformat); if (!xlate) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] media: adv7180: add of match table
From: Ben Dooks ben.do...@codethink.co.uk
Add a proper of match id for use when the device is being bound via
device tree, to avoid having to use the i2c old-style binding of the
device.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
Signed-off-by: William.Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/i2c/adv7180.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index a493c0b..09a96df 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -25,6 +25,7 @@
#include linux/interrupt.h
#include linux/i2c.h
#include linux/slab.h
+#include linux/of.h
#include media/v4l2-ioctl.h
#include linux/videodev2.h
#include media/v4l2-device.h
@@ -1324,11 +1325,21 @@ static SIMPLE_DEV_PM_OPS(adv7180_pm_ops,
adv7180_suspend, adv7180_resume);
#define ADV7180_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id adv7180_of_id[] = {
+ { .compatible = adi,adv7180, },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, adv7180_of_id);
+#endif
+
static struct i2c_driver adv7180_driver = {
.driver = {
.owner = THIS_MODULE,
.name = KBUILD_MODNAME,
.pm = ADV7180_PM_OPS,
+ .of_match_table = of_match_ptr(adv7180_of_id),
},
.probe = adv7180_probe,
.remove = adv7180_remove,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] media: soc_camera: Fix error reporting in expbuf
From: Hans Verkuil hans.verk...@cisco.com Remove unnecessary check and fix the error code for vb1 drivers. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk --- drivers/media/platform/soc_camera/soc_camera.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index f6c05c6..a80cde5 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -470,14 +470,10 @@ static int soc_camera_expbuf(struct file *file, void *priv, struct soc_camera_device *icd = file-private_data; struct soc_camera_host *ici = to_soc_camera_host(icd-parent); - if (icd-streamer != file) - return -EBUSY; - /* videobuf2 only */ if (ici-ops-init_videobuf) - return -EINVAL; - else - return vb2_expbuf(icd-vb2_vidq, p); + return -ENOTTY; + return vb2_expbuf(icd-vb2_vidq, p); } /* Always entered with .host_lock held */ -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HDMI and Composite capture on Lager, for kernel 4.1, version 2
Version 2 of the patchset sent last week, ie. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/91423 In response to comments, this version has: fixes regarding use of CONFIG_MEDIA_CONTROLLER defines; an additional line for the RGB888 support patch (required by parallel changes); removal of more vestigial format handling; the set no longer has its debugging changes and now incorporates the patch at https://patchwork.linuxtv.org/patch/29807/ Cheers, Wills. To follow: [PATCH 01/15] ARM: shmobile: lager dts: Add entries for VIN HDMI [PATCH 02/15] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 [PATCH 03/15] media: adv7180: add of match table [PATCH 04/15] media: adv7604: chip info and formats for ADV7612 [PATCH 05/15] media: adv7604: document support for ADV7612 dual HDMI [PATCH 06/15] media: adv7604: ability to read default input port [PATCH 07/15] ARM: shmobile: lager dts: specify default-input for [PATCH 08/15] v4l: subdev: Add pad config allocator and init [PATCH 09/15] media: soc_camera pad-aware driver initialisation [PATCH 10/15] media: rcar_vin: Use correct pad number in try_fmt [PATCH 11/15] media: soc_camera: soc_scale_crop: Use correct pad [PATCH 12/15] media: soc_camera: Fill std field in enum_input [PATCH 13/15] media: soc_camera: Fix error reporting in expbuf [PATCH 14/15] media: soc_camera: v4l2-compliance fixes for querycap [PATCH 15/15] media: rcar_vin: Reject videobufs that are too small -- 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 09/15] media: soc_camera pad-aware driver initialisation
Add detection of source pad number for drivers aware of the media
controller API, so that soc_camera/rcar_vin can create device nodes
to support a driver such as adv7604.c (for HDMI on Lager) underneath.
Signed-off-by: William Towle william.to...@codethink.co.uk
Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c |6 +
drivers/media/platform/soc_camera/soc_camera.c | 32
include/media/soc_camera.h |1 +
3 files changed, 39 insertions(+)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 16352a8..0df3212 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1358,7 +1358,13 @@ static int rcar_vin_get_formats(struct soc_camera_device
*icd, unsigned int idx,
struct v4l2_rect rect;
struct device *dev = icd-parent;
int shift;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_pad *remote_pad;
+ remote_pad = media_entity_remote_pad(
+ icd-vdev-entity.pads[0]);
+ fmt.pad = remote_pad-index;
+#endif
ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
if (ret 0)
return ret;
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index d708df4..b054f46 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1293,6 +1293,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
struct v4l2_mbus_framefmt *mf = fmt.format;
+ int src_pad_idx = -1;
int ret;
sd-grp_id = soc_camera_grp_id(icd);
@@ -1310,8 +1311,30 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
return ret;
}
+#if defined(CONFIG_MEDIA_CONTROLLER)
/* At this point client .probe() should have run already */
+ ret = media_entity_init(icd-vdev-entity, 1, icd-pad, 0);
+ if (!ret) {
+ for (src_pad_idx = 0; src_pad_idx sd-entity.num_pads;
+ src_pad_idx++)
+ if (sd-entity.pads[src_pad_idx].flags
+ == MEDIA_PAD_FL_SOURCE)
+ break;
+
+ if (src_pad_idx sd-entity.num_pads) {
+ if (!media_entity_create_link(
+ icd-vdev-entity, 0,
+ sd-entity, src_pad_idx,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED)) {
+ ret = soc_camera_init_user_formats(icd);
+ }
+ }
+ }
+#else
ret = soc_camera_init_user_formats(icd);
+#endif
+
if (ret 0)
goto eusrfmt;
@@ -1322,6 +1345,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
goto evidstart;
/* Try to improve our guess of a reasonable window format */
+ fmt.pad = src_pad_idx;
if (!v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt)) {
icd-user_width = mf-width;
icd-user_height= mf-height;
@@ -1335,6 +1359,9 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
evidstart:
soc_camera_free_user_formats(icd);
eusrfmt:
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ media_entity_cleanup(icd-vdev-entity);
+#endif
soc_camera_remove_device(icd);
return ret;
@@ -1856,6 +1883,11 @@ static int soc_camera_remove(struct soc_camera_device
*icd)
if (icd-num_user_formats)
soc_camera_free_user_formats(icd);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ if (icd-vdev-entity.num_pads)
+ media_entity_cleanup(icd-vdev-entity);
+#endif
+
if (icd-clk) {
/* For the synchronous case */
v4l2_clk_unregister(icd-clk);
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 2f6261f..f0c5238 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -42,6 +42,7 @@ struct soc_camera_device {
unsigned char devnum; /* Device number per host */
struct soc_camera_sense *sense; /* See comment in struct definition */
struct video_device *vdev;
+ struct media_pad pad;
struct v4l2_ctrl_handler ctrl_handler;
const struct soc_camera_format_xlate *current_fmt;
struct soc_camera_format_xlate *user_formats;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 10/15] media: rcar_vin: Use correct pad number in try_fmt
Fix rcar_vin_try_fmt to use the correct pad number when calling the
subdev set_fmt. Previously pad number 0 was always used, resulting in
EINVAL if the subdev cares about the pad number (e.g. ADV7612).
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 36 ++
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 0df3212..5523d04 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1702,7 +1702,7 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd,
const struct soc_camera_format_xlate *xlate;
struct v4l2_pix_format *pix = f-fmt.pix;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- struct v4l2_subdev_pad_config pad_cfg;
+ struct v4l2_subdev_pad_config *pad_cfg = NULL;
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_TRY,
};
@@ -1710,6 +1710,11 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
__u32 pixfmt = pix-pixelformat;
int width, height;
int ret;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_pad *remote_pad;
+
+ pad_cfg = v4l2_subdev_alloc_pad_config(sd);
+#endif
xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
if (!xlate) {
@@ -1739,10 +1744,22 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
mf-code = xlate-code;
mf-colorspace = pix-colorspace;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, soc_camera_grp_id(icd),
-pad, set_fmt, pad_cfg, format);
- if (ret 0)
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ remote_pad = media_entity_remote_pad(
+ icd-vdev-entity.pads[0]);
+ format.pad = remote_pad-index;
+#endif
+
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), pad,
+ set_fmt, pad_cfg,
+ format);
+ if (ret 0) {
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ v4l2_subdev_free_pad_config(pad_cfg);
+#endif
return ret;
+ }
/* Adjust only if VIN cannot scale */
if (pix-width mf-width * 2)
@@ -1764,13 +1781,19 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
*/
mf-width = VIN_MAX_WIDTH;
mf-height = VIN_MAX_HEIGHT;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ format.pad = remote_pad-index;
+#endif
ret = v4l2_device_call_until_err(sd-v4l2_dev,
soc_camera_grp_id(icd),
-pad, set_fmt, pad_cfg,
+pad, set_fmt, pad_cfg,
format);
if (ret 0) {
dev_err(icd-parent,
client try_fmt() = %d\n, ret);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ v4l2_subdev_free_pad_config(pad_cfg);
+#endif
return ret;
}
}
@@ -1781,6 +1804,9 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd,
pix-height = height;
}
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ v4l2_subdev_free_pad_config(pad_cfg);
+#endif
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/15] media: soc_camera: v4l2-compliance fixes for querycap
From: Rob Taylor rob.tay...@codethink.co.uk Fill in bus_info field and zero reserved field - v4l2-compliance complained it wasn't zero (v4l2-compliance.cpp:308 in v4l-utils v1.6.2) Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk Reviewed-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/soc_camera.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index a80cde5..7307924 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -954,6 +954,8 @@ static int soc_camera_querycap(struct file *file, void *priv, WARN_ON(priv != file-private_data); strlcpy(cap-driver, ici-drv_name, sizeof(cap-driver)); + strlcpy(cap-bus_info, platform:soc_camera, sizeof(cap-bus_info)); + memset(cap-reserved, 0, sizeof(cap-reserved)); return ici-ops-querycap(ici, cap); } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] media: adv7604: document support for ADV7612 dual HDMI input decoder
From: Ian Molton ian.mol...@codethink.co.uk This documentation accompanies the patch adding support for the ADV7612 dual HDMI decoder / repeater chip. Signed-off-by: Ian Molton ian.mol...@codethink.co.uk Reviewed-by: William Towle william.to...@codethink.co.uk --- .../devicetree/bindings/media/i2c/adv7604.txt| 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..7eafdbc 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -1,15 +1,17 @@ -* Analog Devices ADV7604/11 video decoder with HDMI receiver +* Analog Devices ADV7604/11/12 video decoder with HDMI receiver -The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI -receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input, -and the ADV7611 has one HDMI input and no analog input. +The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated +HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog +input, and the ADV7611 has one HDMI input and no analog input. The 7612 is +similar to the 7611 but has 2 HDMI inputs. -These device tree bindings support the ADV7611 only at the moment. +These device tree bindings support the ADV7611/12 only at the moment. Required Properties: - compatible: Must contain one of the following - adi,adv7611 for the ADV7611 +- adi,adv7612 for the ADV7612 - reg: I2C slave address @@ -22,10 +24,10 @@ port, in accordance with the video interface bindings defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes are numbered as follows. - Port ADV7611 + Port ADV7611ADV7612 - HDMI 0 - Digital output 1 + HDMI 0 0, 1 + Digital output 12 The digital output port node must contain at least one endpoint. -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/15] ARM: shmobile: lager dts: specify default-input for ADV7612
Set 'default-input' property for ADV7612. Enables image/video capture
without the need to have userspace specifying routing.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Tested-by: William Towle william.to...@codethink.co.uk
---
arch/arm/boot/dts/r8a7790-lager.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 90c4531..6946e9a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -544,6 +544,7 @@
port {
hdmi_in_ep: endpoint {
remote-endpoint = vin0ep0;
+ default-input = 0;
};
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] media: adv7604: ability to read default input port from DT
From: Ian Molton ian.mol...@codethink.co.uk
Adds support to the adv7604 driver for specifying the default input
port in the Device tree. If no value is provided, the driver will be
unable to select an input without help from userspace.
Tested-by: William Towle william.to...@codethink.co.uk
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
---
Documentation/devicetree/bindings/media/i2c/adv7604.txt |3 +++
drivers/media/i2c/adv7604.c |8 +++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 7eafdbc..8337f75 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -47,6 +47,7 @@ Optional Endpoint Properties:
If none of hsync-active, vsync-active and pclk-sample is specified the
endpoint will use embedded BT.656 synchronization.
+ - default-input: Select which input is selected after reset.
Example:
@@ -60,6 +61,8 @@ Example:
#address-cells = 1;
#size-cells = 0;
+ default-input = 0;
+
port@0 {
reg = 0;
};
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index c5a1566..ec8161d 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2745,6 +2745,7 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
struct device_node *endpoint;
struct device_node *np;
unsigned int flags;
+ u32 v;
np = state-i2c_clients[ADV76XX_PAGE_IO]-dev.of_node;
@@ -2754,6 +2755,12 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
return -EINVAL;
v4l2_of_parse_endpoint(endpoint, bus_cfg);
+
+ if (!of_property_read_u32(endpoint, default-input, v))
+ state-pdata.default_input = v;
+ else
+ state-pdata.default_input = -1;
+
of_node_put(endpoint);
flags = bus_cfg.bus.parallel.flags;
@@ -2792,7 +2799,6 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
/* Hardcode the remaining platform data fields. */
state-pdata.disable_pwrdnb = 0;
state-pdata.disable_cable_det_rst = 0;
- state-pdata.default_input = -1;
state-pdata.blank_data = 1;
state-pdata.alt_data_sat = 1;
state-pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] treewide: Fix typo compatability - compatibility
From: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Wed, 27 May 2015 15:05:42 +0300 Even though 'compatability' has a dedicated entry in the Wiktionary, it's listed as 'Mispelling of compatibility'. Fix it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: David S. Miller da...@davemloft.net -- 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 02/15] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support
This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Simon Horman horms+rene...@verge.net.au
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
Modified to use MEDIA_BUS_FMT_* constants
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index db7700b..16352a8 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -98,6 +98,7 @@
#define VNMC_INF_YUV10_BT656 (2 16)
#define VNMC_INF_YUV10_BT601 (3 16)
#define VNMC_INF_YUV16 (5 16)
+#define VNMC_INF_RGB888(6 16)
#define VNMC_VUP (1 10)
#define VNMC_IM_ODD(0 3)
#define VNMC_IM_ODD_EVEN (1 3)
@@ -589,7 +590,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
struct soc_camera_device *icd = priv-ici.icd;
struct rcar_vin_cam *cam = icd-host_priv;
u32 vnmc, dmr, interrupts;
- bool progressive = false, output_is_yuv = false;
+ bool progressive = false, output_is_yuv = false, input_is_yuv = false;
switch (priv-field) {
case V4L2_FIELD_TOP:
@@ -623,16 +624,22 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
+ input_is_yuv = true;
break;
case MEDIA_BUS_FMT_YUYV8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= priv-pdata_flags RCAR_VIN_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
+ input_is_yuv = true;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ vnmc |= VNMC_INF_RGB888;
break;
case MEDIA_BUS_FMT_YUYV10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
vnmc |= priv-pdata_flags RCAR_VIN_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
+ input_is_yuv = true;
break;
default:
break;
@@ -676,7 +683,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
vnmc |= VNMC_VUP;
/* If input and output use the same colorspace, use bypass mode */
- if (output_is_yuv)
+ if (input_is_yuv == output_is_yuv)
vnmc |= VNMC_BPS;
/* progressive or interlaced mode */
@@ -1423,6 +1430,7 @@ static int rcar_vin_get_formats(struct soc_camera_device
*icd, unsigned int idx,
case MEDIA_BUS_FMT_YUYV8_1X16:
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_YUYV10_2X10:
+ case MEDIA_BUS_FMT_RGB888_1X24:
if (cam-extra_fmt)
break;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/15] v4l: subdev: Add pad config allocator and init
From: Laurent Pinchart laurent.pinch...@linaro.org
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Signed-off-by: Laurent Pinchart laurent.pinch...@linaro.org
Acked-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 10 ++
2 files changed, 28 insertions(+), 1 deletion(-)
Changes since v1:
- Added v4l2_subdev_free_pad_config
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 10 ++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 6359606..d594fe5 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -35,7 +35,7 @@
static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
{
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
- fh-pad = kzalloc(sizeof(*fh-pad) * sd-entity.num_pads, GFP_KERNEL);
+ fh-pad = v4l2_subdev_alloc_pad_config(sd);
if (fh-pad == NULL)
return -ENOMEM;
#endif
@@ -569,6 +569,23 @@ int v4l2_subdev_link_validate(struct media_link *link)
sink, link, source_fmt, sink_fmt);
}
EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd)
+{
+ struct v4l2_subdev_pad_config *cfg;
+
+ if (!sd-entity.num_pads)
+ return NULL;
+
+ cfg = kcalloc(sd-entity.num_pads, sizeof(*cfg), GFP_KERNEL);
+ if (!cfg)
+ return NULL;
+
+ v4l2_subdev_call(sd, pad, init_cfg, cfg);
+
+ return cfg;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_alloc_pad_config);
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index dc20102..4a609f6 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -485,6 +485,8 @@ struct v4l2_subdev_pad_config {
* may be adjusted by the subdev driver to device
capabilities.
*/
struct v4l2_subdev_pad_ops {
+ void (*init_cfg)(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg);
int (*enum_mbus_code)(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code);
@@ -677,7 +679,15 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev
*sd,
struct v4l2_subdev_format *source_fmt,
struct v4l2_subdev_format *sink_fmt);
int v4l2_subdev_link_validate(struct media_link *link);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd);
+
+static inline void v4l2_subdev_free_pad_config(struct v4l2_subdev_pad_config
*cfg)
+{
+ kfree(cfg);
+}
#endif /* CONFIG_MEDIA_CONTROLLER */
+
void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] ARM: shmobile: lager dts: Add entries for VIN HDMI input support
Add DT entries for vin0, vin0_pins, and adv7612
Signed-off-by: William Towle william.to...@codethink.co.uk
Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk
---
arch/arm/boot/dts/r8a7790-lager.dts | 41 ++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index aaa4f25..90c4531 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -370,7 +370,12 @@
renesas,function = usb2;
};
- vin1_pins: vin {
+ vin0_pins: vin0 {
+ renesas,groups = vin0_data24, vin0_sync, vin0_field,
vin0_clkenb, vin0_clk;
+ renesas,function = vin0;
+ };
+
+ vin1_pins: vin1 {
renesas,groups = vin1_data8, vin1_clk;
renesas,function = vin1;
};
@@ -531,6 +536,18 @@
reg = 0x12;
};
+ hdmi-in@4c {
+ compatible = adi,adv7612;
+ reg = 0x4c;
+ remote = vin0;
+
+ port {
+ hdmi_in_ep: endpoint {
+ remote-endpoint = vin0ep0;
+ };
+ };
+ };
+
composite-in@20 {
compatible = adi,adv7180;
reg = 0x20;
@@ -646,6 +663,28 @@
status = okay;
};
+/* HDMI video input */
+vin0 {
+ pinctrl-0 = vin0_pins;
+ pinctrl-names = default;
+
+ status = ok;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ vin0ep0: endpoint {
+ remote-endpoint = hdmi_in_ep;
+ bus-width = 24;
+ hsync-active = 0;
+ vsync-active = 0;
+ pclk-sample = 1;
+ data-active = 1;
+ };
+ };
+};
+
/* composite video input */
vin1 {
pinctrl-0 = vin1_pins;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] media: adv7604: chip info and formats for ADV7612
Add support for the ADV7612 chip as implemented on Renesas' Lager
board to adv7604.c, including lists for formats/colourspace/timing
selection and an IRQ handler.
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/i2c/adv7604.c | 83 +--
1 file changed, 81 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index aaa37b0..c5a1566 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -80,6 +80,7 @@ MODULE_LICENSE(GPL);
enum adv76xx_type {
ADV7604,
ADV7611,
+ ADV7612,
};
struct adv76xx_reg_seq {
@@ -758,6 +759,23 @@ static const struct adv76xx_format_info adv7611_formats[]
= {
ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_12BIT },
};
+static const struct adv76xx_format_info adv7612_formats[] = {
+ { MEDIA_BUS_FMT_RGB888_1X24, ADV76XX_OP_CH_SEL_RGB, true, false,
+ ADV76XX_OP_MODE_SEL_SDR_444 | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YUYV8_2X8, ADV76XX_OP_CH_SEL_RGB, false, false,
+ ADV76XX_OP_MODE_SEL_SDR_422 | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YVYU8_2X8, ADV76XX_OP_CH_SEL_RGB, false, true,
+ ADV76XX_OP_MODE_SEL_SDR_422 | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_UYVY8_1X16, ADV76XX_OP_CH_SEL_RBG, false, false,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_VYUY8_1X16, ADV76XX_OP_CH_SEL_RBG, false, true,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YUYV8_1X16, ADV76XX_OP_CH_SEL_RGB, false, false,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YVYU8_1X16, ADV76XX_OP_CH_SEL_RGB, false, true,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+};
+
static const struct adv76xx_format_info *
adv76xx_format_info(struct adv76xx_state *state, u32 code)
{
@@ -2471,6 +2489,11 @@ static void adv7611_setup_irqs(struct v4l2_subdev *sd)
io_write(sd, 0x41, 0xd0); /* STDI irq for any change, disable INT2 */
}
+static void adv7612_setup_irqs(struct v4l2_subdev *sd)
+{
+ io_write(sd, 0x41, 0xd0); /* disable INT2 */
+}
+
static void adv76xx_unregister_clients(struct adv76xx_state *state)
{
unsigned int i;
@@ -2558,6 +2581,19 @@ static const struct adv76xx_reg_seq
adv7611_recommended_settings_hdmi[] = {
{ ADV76XX_REG_SEQ_TERM, 0 },
};
+static const struct adv76xx_reg_seq adv7612_recommended_settings_hdmi[] = {
+ { ADV76XX_REG(ADV76XX_PAGE_CP, 0x6c), 0x00 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x9b), 0x03 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x6f), 0x08 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x85), 0x1f },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x87), 0x70 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x57), 0xda },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x58), 0x01 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x03), 0x98 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x4c), 0x44 },
+ { ADV76XX_REG_SEQ_TERM, 0 },
+};
+
static const struct adv76xx_chip_info adv76xx_chip_info[] = {
[ADV7604] = {
.type = ADV7604,
@@ -2646,17 +2682,59 @@ static const struct adv76xx_chip_info
adv76xx_chip_info[] = {
.field1_vsync_mask = 0x3fff,
.field1_vbackporch_mask = 0x3fff,
},
+ [ADV7612] = {
+ .type = ADV7612,
+ .has_afe = false,
+ .max_port = ADV7604_PAD_HDMI_PORT_B,
+ .num_dv_ports = 2,
+ .edid_enable_reg = 0x74,
+ .edid_status_reg = 0x76,
+ .lcf_reg = 0xa3,
+ .tdms_lock_mask = 0x43,
+ .cable_det_mask = 0x01,
+ .fmt_change_digital_mask = 0x03,
+ .formats = adv7612_formats,
+ .nformats = ARRAY_SIZE(adv7612_formats),
+ .set_termination = adv7611_set_termination,
+ .setup_irqs = adv7612_setup_irqs,
+ .read_hdmi_pixelclock = adv7611_read_hdmi_pixelclock,
+ .read_cable_det = adv7611_read_cable_det,
+ .recommended_settings = {
+ [1] = adv7612_recommended_settings_hdmi,
+ },
+ .num_recommended_settings = {
+ [1] = ARRAY_SIZE(adv7612_recommended_settings_hdmi),
+ },
+ .page_mask = BIT(ADV76XX_PAGE_IO) | BIT(ADV76XX_PAGE_CEC) |
+ BIT(ADV76XX_PAGE_INFOFRAME) | BIT(ADV76XX_PAGE_AFE) |
+ BIT(ADV76XX_PAGE_REP) | BIT(ADV76XX_PAGE_EDID) |
+ BIT(ADV76XX_PAGE_HDMI) | BIT(ADV76XX_PAGE_CP),
+ .linewidth_mask = 0x1fff,
+ .field0_height_mask = 0x1fff,
+ .field1_height_mask = 0x1fff,
+ .hfrontporch_mask = 0x1fff,
+ .hsync_mask =
[PATCH 1/1] [media] ddbridge: Do not free_irq() if request_irq() failed
From: Takeshi Yoshimura y...@sslab.ics.keio.ac.jp My static checker detected that free_irq() is called even after request_irq() failed in ddb_probe(). In this case, the kernel may try to free dev-pdev-irq although the IRQ is not assigned. This event rarely occurs, but always introduces a warning if it happens. goto fail1 always results in disabling enabled MSI and releasing a requested IRQ. It seems like the former handling is necessary. So I added a conditional branch before the free_irq() (stat == 0 means request_irq() succeeds). Signed-off-by: Takeshi Yoshimura y...@sslab.ics.keio.ac.jp --- drivers/media/pci/ddbridge/ddbridge-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c b/drivers/media/pci/ddbridge/ddbridge-core.c index 9e3492e..0ac2dd3 100644 --- a/drivers/media/pci/ddbridge/ddbridge-core.c +++ b/drivers/media/pci/ddbridge/ddbridge-core.c @@ -1630,7 +1630,8 @@ fail1: printk(KERN_ERR fail1\n); if (dev-msi) pci_disable_msi(dev-pdev); - free_irq(dev-pdev-irq, dev); + if (stat == 0) + free_irq(dev-pdev-irq, dev); fail: printk(KERN_ERR fail\n); ddb_unmap(dev); -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sound/usb: Update ALSA driver to use media controller API
At Fri, 8 May 2015 13:31:31 -0600,
Shuah Khan wrote:
Change ALSA driver to use media controller API to share tuner
with DVB and V4L2 drivers that control AU0828 media device.
Media device is created based on a newly added field value
in the struct snd_usb_audio_quirk. Using this approach, the
media controller API usage can be added for a specific device.
In this patch, media controller API is enabled for AU0828 hw.
snd_usb_create_quirk() will check this new field, if set will
create a media device using media_device_get_dr() interface.
media_device_get_dr() will allocate a new media device device
resource or return an existing one if it exists. During probe,
media usb driver could have created the media device. It will
then register the media device if it isn't already registered.
Media device unregister is done from usb_audio_disconnect().
New fields to add support for media entity and links are
added to struct snd_usb_substream. A new media entity for
ALSA and a link from tuner entity to the newly registered
ALSA entity are created from snd_usb_init_substream() and
removed from free_substream(). The state is kept to indicate
if tuner is linked. This is to account for case when tuner
entity doesn't exist. Media pipeline gets started to mark
the tuner busy from snd_usb_substream_capture_trigger in
response to SNDRV_PCM_TRIGGER_START and pipeline is stopped
in response to SNDRV_PCM_TRIGGER_STOP. snd_usb_pcm_close()
stops pipeline to cover the case when SNDRV_PCM_TRIGGER_STOP
isn't issued. Pipeline start and stop are done only when
tuner_linked is set.
Tested with and without CONFIG_MEDIA_CONTROLLER enabled.
Tested tuner entity doesn't exist case as au0828 v4l2
driver is the one that will create the tuner when it gets
updated to use media controller API.
I guess it gets broken when CONFIG_MEDIA_SUPPORT=m while
CONFIG_SND*=y. So, it should be compiled in only when the media
support is built-in or both sound and media are module, i.e.
#ifdef CONFIG_MEDIA_CONTROLLER
#if defined(CONFIG_MEDIA_SUPPORT) || \
(defined(CONFIG_MEDIA_SUPPORT_MODULE) defined(MODULE))
#define I_CAN_USE_MEDIA_CONTROLLER
#endif
#endif
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
sound/usb/card.c | 5 +
sound/usb/card.h | 12 ++
sound/usb/pcm.c | 23 ++-
sound/usb/quirks-table.h | 1 +
sound/usb/quirks.c | 58
+++-
sound/usb/quirks.h | 6 +
sound/usb/stream.c | 40 +
sound/usb/usbaudio.h | 1 +
8 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 1fab977..587fc24 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -621,6 +621,11 @@ static void usb_audio_disconnect(struct usb_interface
*intf)
}
}
+ /* Nice to check quirk quirk-media_device
+ * need some special handlings. Doesn't look like
+ * we have access to quirk here */
+ media_device_delete(intf);
This should be called once, so better in if (!was_shutdown) block, I
guess.
Apart from that, yes, a good way to call an optional destructor for
quirks would be better.
chip-num_interfaces--;
if (chip-num_interfaces = 0) {
usb_chip[chip-index] = NULL;
diff --git a/sound/usb/card.h b/sound/usb/card.h
index ef580b4..477bdcd 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -1,6 +1,11 @@
#ifndef __USBAUDIO_CARD_H
#define __USBAUDIO_CARD_H
+#ifdef CONFIG_MEDIA_CONTROLLER
+#include media/media-device.h
+#include media/media-entity.h
+#endif
+
#define MAX_NR_RATES 1024
#define MAX_PACKS6 /* per URB */
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
@@ -155,6 +160,13 @@ struct snd_usb_substream {
} dsd_dop;
bool trigger_tstamp_pending_update; /* trigger timestamp being updated
from initial estimate */
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device *media_dev;
+ struct media_entity media_entity;
+ struct media_pad media_pads;
+ struct media_pipeline media_pipe;
+ bool tuner_linked;
+#endif
Maybe a slightly better idea is to allocate these in a new record and
stores the pointer in stream-media_ctl or whatever new field.
Then, a check like
if (subs-tuner_linked)
can be replaced with
if (subs-media_ctl)
The whole media-specific stuff can be gathered in a single file,
e.g. sound/usb/media.c, and there you can define the struct.
};
struct snd_usb_stream {
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index b4ef410..c2a40a9 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -1225,6 +1225,10 @@ static int snd_usb_pcm_close(struct snd_pcm_substream
*substream, int direction)
subs-pcm_substream = NULL;
snd_usb_autosuspend(subs-stream-chip);
+#ifdef CONFIG_MEDIA_CONTROLLER
Re: [RFC] Media controller entity information property API
Em Wed, 27 May 2015 16:39:33 +0300
Sakari Ailus sakari.ai...@iki.fi escreveu:
Hi folks,
It has been discussed in several occasions that the current
MEDIA_IOC_ENTITY_INFO IOCTL does not address various needs that have arisen
since the API was merged to the mainline kernel. It also has been recognised
that the current interface is not meaningfully extensible in a future-proof
fashion; something drastically different is needed.
The name Property API or Property based API has been mentioned every
time in those discussions as a fix to the issues. By that term, different
people probably have meant slightly different things at different points of
time.
This RFC intends to address the issues (see below) and define what a
Media entity information property API should be like.
Current interface
=
#define MEDIA_IOC_ENUM_ENTITIES _IOWR('|', 0x01, struct
media_entity_desc)
struct media_entity_desc {
__u32 id;
char name[32];
__u32 type;
__u32 revision;
__u32 flags;
__u32 group_id;
__u16 pads;
__u16 links;
__u32 reserved[4];
union {
/* Node specifications */
struct {
__u32 major;
__u32 minor;
} dev;
#if 1
/*
* TODO: this shouldn't have been added without
* actual drivers that use this. When the first real driver
* appears that sets this information, special attention
* should be given whether this information is 1) enough, and
* 2) can deal with udev rules that rename devices. The
struct
* dev would not be sufficient for this since that does not
* contain the subdevice information. In addition, struct dev
* can only refer to a single device, and not to multiple
(e.g.
* pcm and mixer devices).
*
* So for now mark this as a to do.
*/
struct {
__u32 card;
__u32 device;
__u32 subdevice;
} alsa;
#endif
#if 1
/*
* DEPRECATED: previous node specifications. Kept just to
* avoid breaking compilation, but media_entity_desc.dev
* should be used instead. In particular, alsa and dvb
* fields below are wrong: for all devnodes, there should
* be just major/minor inside the struct, as this is enough
* to represent any devnode, no matter what type.
*/
struct {
__u32 major;
__u32 minor;
} v4l;
struct {
__u32 major;
__u32 minor;
} fb;
int dvb;
#endif
/* Sub-device specifications */
/* Nothing needed yet */
__u8 raw[184];
};
};
The interface has been recently amended by Mauro's patch
[media] media: Fix DVB devnode representation at media controller, commit
id e31a0ba7df6ce21ac4ed58c4182ec12ca8fd78fb in media-tree currently.
Use cases that don't fit to the current interface
=
DVB and Media controller
Some of the entities in the DVB Media controller graph need to expose three
device nodes --- the reason is that the DVB subsystem provides choices to
the user in terms of which interface to use. The union in struct
media_entity_desc only provides a single struct for device minor and major.
Adding more device nodes would not scale; the user would have to know
additional information on the nodes, i.e. which one is which and so forth.
Identifying entities
Some years ago when the Media controller interface was first accepted to the
mainline kernel, naming entities uniquely in a media device was no issue.
There were ISP or bridge drivers that created the media entity, accompanied
by drivers for external entities most of which were I2C devices directly
connected to the ISP device.
Things aren't quite that simple anymore. Creating a cross device (e.g. two
otherwise independent IP cores) or a system wide media device would greatly
ease creation of cross-device pipelines as there is no single master driver
anymore. As a side effect entity names have to be unique across such devices
(or the entire system), not only within a media device.
Constructing unique names that are human readable, stable, unique and fit to
31 characters reserved for the purpose is not thought to be possible: device
bus
Re: [PATCH 13/13] ASoC: omap-pcm: Switch to use dma_request_slave_channel_compat_reason()
On Tue, May 26, 2015 at 04:26:08PM +0300, Peter Ujfalusi wrote: dmaengine provides a wrapper function to handle DT and non DT boots when requesting DMA channel. Use that instead of checking for of_node in the platform driver. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Wed, May 27, 2015 at 02:15:12PM +0300, Peter Ujfalusi wrote: I have put the maintainers of the relevant subsystems as CC in the commit message and sent the series to all of the mailing lists. This series was touching 7 subsystems and I thought not spamming every maintainer with all the mails might be better. You need to at least include people on the cover letter, otherwise they'll have no idea what's going on. signature.asc Description: Digital signature
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. Acked-by: Mark Brown broo...@kernel.org signature.asc Description: Digital signature
Re: [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Hi Philipp, Lucas and Sascha,
Thanks for that patch series.
2015-03-18 11:22 GMT+01:00 Philipp Zabel p.za...@pengutronix.de:
This patch adds support for mem2mem scaling and colorspace conversion
using the IC module's post-processing task.
Scaling images larger than 1024x1024 is supported by tiling over multiple
IC scaling runs. Since the IDMAC and IC units have interesting and different
alignment limitations for buffer base addresses (left edges) and burst size
(row lengths), depending on input and output pixel formats, the tile
rectangles
and scaling coefficients are chosen to minimize distortion. Due to possible
overlap, the tiles have to be rendered right to left and bottom to top.
Up to 7 pixels (depending on frame sizes and scaling factor) have to be
available after the end of the frame if the width is not burst size aligned.
The tiling code has a parameter to optionally round frame sizes up or down
and avoid overdraw in compositing scenarios.
Can you detail what you call compositing scenarios ?
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Lucas Stach l.st...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v1:
- Removed deinterlacer support left-overs
---
drivers/gpu/ipu-v3/ipu-ic.c | 787
+++-
include/video/imx-ipu-v3.h | 34 +-
2 files changed, 804 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index ad75588..984f68f 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -15,6 +15,7 @@
#include linux/errno.h
#include linux/spinlock.h
#include linux/bitrev.h
+#include linux/interrupt.h
#include linux/io.h
#include linux/err.h
#include ipu-prv.h
@@ -96,6 +97,15 @@ struct ic_task_bitfields {
u32 ic_cmb_galpha_bit;
};
+struct ic_task_channels {
+ u8 in;
+ u8 out;
+ u8 rot_in;
+ u8 rot_out;
+ u8 in_prev;
+ u8 in_next;
+};
+
static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
[IC_TASK_ENCODER] = {
.rsc = IC_PRP_ENC_RSC,
@@ -138,12 +148,53 @@ static const struct ic_task_bitfields
ic_task_bit[IC_NUM_TASKS] = {
},
};
+static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
+ [IC_TASK_ENCODER] = {
+ .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
+ .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
+ .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
+ .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
+ },
+ [IC_TASK_VIEWFINDER] = {
+ .in = IPUV3_CHANNEL_MEM_VDI_CUR,
+ .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
+ .rot_in = IPUV3_CHANNEL_MEM_ROT_VF,
+ .rot_out = IPUV3_CHANNEL_ROT_VF_MEM,
+ .in_prev = IPUV3_CHANNEL_MEM_VDI_PREV,
+ .in_next = IPUV3_CHANNEL_MEM_VDI_NEXT,
+ },
+ [IC_TASK_POST_PROCESSOR] = {
+ .in = IPUV3_CHANNEL_MEM_IC_PP,
+ .out = IPUV3_CHANNEL_IC_PP_MEM,
+ .rot_in = IPUV3_CHANNEL_MEM_ROT_PP,
+ .rot_out = IPUV3_CHANNEL_ROT_PP_MEM,
+ },
+};
+
+struct image_convert_ctx {
+ void (*complete)(void *ctx, int err);
+ void *complete_context;
+
+ struct list_head list;
+ struct ipu_image in;
+ struct ipu_image in_n;
+ struct ipu_image in_p;
+ struct ipu_image out;
+
+ void *freep;
+
+ bool rotate:1;
+
+ u32 rsc;
+};
+
struct ipu_ic_priv;
struct ipu_ic {
enum ipu_ic_task task;
const struct ic_task_regoffs *reg;
const struct ic_task_bitfields *bit;
+ const struct ic_task_channels *ch;
enum ipu_color_space in_cs, g_in_cs;
enum ipu_color_space out_cs;
@@ -152,6 +203,19 @@ struct ipu_ic {
bool in_use;
struct ipu_ic_priv *priv;
+
+ struct ipuv3_channel *input_channel_p;
+ struct ipuv3_channel *input_channel;
+ struct ipuv3_channel *input_channel_n;
+ struct ipuv3_channel *output_channel;
+ struct ipuv3_channel *rotation_input_channel;
+ struct ipuv3_channel *rotation_output_channel;
+
+ struct list_head image_list;
+
+ struct workqueue_struct *workqueue;
+ struct work_struct work;
+ struct completion complete;
};
As this is a workqueue, it can sleep, and you don't know when it is
called exactly.
Can we be sure that it is real-time compatible ? If you have this
scaler after a capture source, and before the coda driver, you can be
starved of buffers ?
And you can even have multiple instances of the scaler, so you
probably can get into troubles if there is not enough buffers on the
capture and output queues, right ?
I have played with it a bit and have been successful having two
instances on IPU1 and two other on IPU2.
But I don't know if there
Re: [PATCH 0/4] media: pxa_camera conversion to dmaengine
Robert Jarzmik robert.jarz...@free.fr writes: Hi Guennadi, I've been cooking this since 2012. At that time, I thought the dmaengine API was not rich enough to support the pxa_camera subtleties (or complexity). I was wrong. I submitted a driver to Vinod for a dma pxa driver which would support everything needed to make pxa_camera work normally. As a consequence, I wrote this serie. Should the pxa-dma driver be accepted, then this serie will be my next move towards pxa conversion to dmaengine. And to parallelize the review work, I'll submit it right away to receive a review and fix pxa_camera so that it is ready by the time pxa-dma is also reviewed. Happy review. -- Robert Robert Jarzmik (4): media: pxa_camera: fix the buffer free path media: pxa_camera: move interrupt to tasklet media: pxa_camera: trivial move of dma irq functions media: pxa_camera: conversion to dmaengine drivers/media/platform/soc_camera/pxa_camera.c | 518 + 1 file changed, 266 insertions(+), 252 deletions(-) Hi Guennadi, Any update on this serie ? The pxa-dma driver is upstreamed now. Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu May 28 04:00:15 CEST 2015 git branch: test git hash: 2a80f296422a01178d0a993479369e94f5830127 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: 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 Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: si2168/dvbsky - blind-scan for DVB-T2 with PLP fails
On 05/28/2015 01:27 AM, Hurda wrote:
Hello.
I think I came across a bug in either of the drivers si2168 and dvbsky
regarding
blind-scanning DVB-T2-frequencies.
HW: Technotrend CT2-4400v2 (afaik based on or the same as DVBSky T330)
demod: Si2168-B40
tuner: Si2158-A20
OS: Ubuntu 15.04 (kernel 3.19)
In Austria, the DVB-T2-service SimpliTV is currently airing up to four
muxes, next to one or two DVB-T-muxes.
In my region, the frequencies are 490MHz, 546MHz, 690MHz, 714MHz for
DVB-T2,
and 498MHz for DVB-T.
These numbers might be of interest when reading the logs.
The peculiar aspect of these T2-muxes is that they're aired on PLP 1
without
there being a PLP 0. I think this is also the root of my problem.
dvbv5-scan is working, but w_scan not?
Could you hack si2168.c file and test?
if (c-delivery_system == SYS_DVBT2) {
/* select PLP */
cmd.args[0] = 0x52;
cmd.args[1] = c-stream_id 0xff;
// cmd.args[2] = c-stream_id == NO_STREAM_ID_FILTER ? 0 : 1;
cmd.args[2] = 0;
cmd.wlen = 3;
cmd.rlen = 1;
ret = si2168_cmd_execute(client, cmd);
if (ret)
goto err;
}
Antti
When doing a blind-scan using w_scan 20140727 on Ubuntu 15.04 (kernel
3.19),
w_scan does not find any of these four DVB-T2-muxes.
It just finds the DVB-T-mux.
Logs:
media-tree_dmesg_lsusb.txt http://pastebin.com/0ixFPMSA
media-tree_w_scan.txt http://pastebin.com/yyG3jSwj
The found transponder:
initial_v3_media_build_trunk.conf http://pastebin.com/LmFQavpy
initial_v5.conf http://pastebin.com/Jx6kymVt
I also tried a fresh checkout from git.linuxtv.org as of last weekend
and the
most recent w_scan version (20141122).
As you can see, w_scan tries to tune(?) the DVB-T2-frequencies, but
ultimately doesn't find anything on them.
Then I tried the DVBSky-linux-driver[1]
(media_build-bst-20150322.tar.gz)[2]
from their site, which is using a binary called sit2 for this card.
Using this driver, w_scan found all four DVB-T2-muxes and the DVB-T-mux.
Additionally, it found the DVB-T2-muxes during the DVB-T-scan.
Logs:
media_build-bst_dmesg_lsusb.txt http://pastebin.com/vJeDMxtu
media_build-bst_w_scan.txt http://pastebin.com/yhwAYjen
Found transponders:
initial_v3_bst.conf http://pastebin.com/ECKQvRWX
initial_v5_bst.conf http://pastebin.com/CbhY6Hpz
Of course, doing a channel-scan using dvbv5-scan on these transponders
worked
too:
dvbv5_sit2.conf http://pastebin.com/3W52bbhv
dvbv5_sit2.log http://pastebin.com/nc66PTkt
Afterwards, I tried to do a channel-scan with the same initial tuning-file
using the opensource-driver, which also worked:
dvbv5_si2168.conf http://pastebin.com/A6FbqUL1
dvbv5_si2168.log http://pastebin.com/ewyVPJR2
This should verify that tuning PLP 1 without there being PLP 0 is not
the issue.
Additionally, if you compare the two channel-lists, you find interesting
differences:
The scan with si2168 has AUTO for MODULATION and INVERSION for
DVB-T2-channels, and for CODE_RATE_LP and INVERSION for DVB-T-channels.
The scan with sit2 has the respective values in the channel-list.
The dvbv5-scan-logs also differ, as using sit2 also displays the signal
quality
during tuning.
I know that there were changes regarding DVB-T2-scanning[3], but as the
blog-
article specifically mentions si2168 and w_scan to be fully dvbv5-compliant
and good for using with DVB-T2, I thought you should know about this
particular problem.
In the attachment I've packed the previously linked logs, for archival
reasons.
Thank you for your attention.
[1] http://www.dvbsky.net/Support_linux.html
[2] http://www.dvbsky.net/download/linux/media_build-bst-150322.tar.gz
[3] http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html
PS: Interesting comments regarding auto-detection for si2168:
http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html?showComment=1427233615765#c8591459871945922951
http://blog.palosaari.fi/2014/09/linux-dvb-t2-tuning-problems.html?showComment=1427234034259#c6500661729983566638
--
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
media build error
deb7, Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/media-devnode.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/media-entity.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/msp3400-driver.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/msp3400-kthreads.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/ngene-core.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/ngene-i2c.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/ngene-cards.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/ngene-dvb.o CC [M] /home/dexter/software/linuxtv-current/media_build/v4l/pd-video.o /home/dexter/software/linuxtv-current/media_build/v4l/pd-video.c:1450:2: error: unknown field 'ioctl' specified in initializer /home/dexter/software/linuxtv-current/media_build/v4l/pd-video.c:1450:2: warning: initialization from incompatible pointer type [enabled by default] /home/dexter/software/linuxtv-current/media_build/v4l/pd-video.c:1450:2: warning: (near initialization for 'pd_video_fops.open') [enabled by default] make[5]: *** [/home/dexter/software/linuxtv-current/media_build/v4l/pd-video.o] Fehler 1 make[4]: *** [_module_/home/dexter/software/linuxtv-current/media_build/v4l] Fehler 2 make[3]: *** [sub-make] Error 2 make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-3.2.0-4-amd64' make[1]: *** [default] Fehler 2 make[1]: Leaving directory `/home/dexter/software/linuxtv-current/media_build/v4l' make: *** [all] Fehler 2 build failed at ./build line 491. -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(+)@ s-:+ a C UL++ P+++ L+++ E-- W++ N o? K- w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ b++(+++) DI+++ D- G++ e* h++ r* y? --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part.
dog harness, dog leash, dog clothes and dog carrier
Hi, this is Jeff Wu from China. We are a factory which produces pet clothes, pet harness, pet leash. Please let me know if you are interested to buy from us, thanks! I will send the price lists and website to you then. Best regards, Jeff Wu -- 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
dog harness, dog leash, dog clothes and dog carrier
Hi, this is Jeff Wu from China. We are a factory which produces pet clothes, pet harness, pet leash. Please let me know if you are interested to buy from us, thanks! I will send the price lists and website to you then. Best regards, Jeff Wu -- 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
