Re: [PATCH 21/66] rtl2830: implement own I2C locking
On 02/02/2015 09:33 PM, Wolfram Sang wrote: Ok, this may eventually work ok for now, but a further change at the I2C core could easily break it. So, we need to double check about such patch with the I2C maintainer. Jean, Are you ok with such patch? If so, please ack. Jean handed over I2C to me in late 2012 :) Basic problem here is that I2C-mux itself is controlled by same I2C device which implements I2C adapter for tuner. Here is what connections looks like: ___ | USB IF | | demod| |tuner | |---| || || | |--I2C--|-/ -|--I2C--|| |I2C master | | I2C mux | | I2C slave | |___| || || So when tuner is called via I2C, it needs recursively call same I2C adapter which is already locked. More elegant solution would be indeed nice. So, AFAIU this is the same problem that I2C based mux devices have (like drivers/i2c/muxes/i2c-mux-pca954x.c)? They also use the unlocked transfers... But those are all called with the lock for the adapter being held. I'm not convinced this is the same for this patch. This patch seems to add a device mutex which protects against concurrent access to the bus with the device itself, but not against concurrent access with other devices on the same bus. -- 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: Re: Vivid test device: adding YU12
On 01/29/2015 03:44 AM, Miguel Casas-Sanchez wrote: Hi folks, I've been trying to add a triplanar format to those that vivid can generate, and didn't quite manage :( So, I tried adding code for it like in the patch (with some dprintk() as well) to clarify what I wanted to do. Module is insmod'ed like insmod vivid.ko n_devs=1 node_types=0x1 multiplanar=2 vivid_debug=1 You are confusing something: PIX_FMT_YUV420 is single-planar, not multi-planar. That is, all image data is contained in one buffer. PIX_FMT_YUV420M is multi-planar, however. So you need to think which one you actually want to support. Another problem is that for the chroma part you need to average the values over four pixels. So the TPG needs to be aware of the previous line. This makes the TPG more complicated, and of course it is the reason why I didn't implement 4:2:0 formats :-) I would implement YUV420 first, and (if needed) YUV420M and/or NV12 can easily be added later. Regards, Hans So, we could call YUV420 (YU12) a tightly packed planar format :) because it has several planes, rigurously speaking, but they are laid out back-to-back in memory. Correct? I was interested here precisely in using the MPLANE API, so I'd rather go for YUV420M directly; perhaps cheating a bit on the TPG calculation in the first implementation: I/we could just simplify the Chroma calculation to grabbing the upper-left pixel value, ignoring the other three. Not perfect, but for a first patch of a test device it should do. WDYT? With the patch, vivid: - seems to enumerate the new triplanar format all right - vid_s_fmt_vid_cap() works as intended too, apparently - when arriving to vid_cap_queue_setup(), the size of the different sub-arrays does not look quite ok. - Generated video is, visually, all green. I added as well a capture output dmesgs. Not much of interest here, the first few lines configure the queue -- with my few added dprintk it can be seen that the queue sizes are seemingly incorrect. If and when this part is up and running, I wanted to use Vivid to test dma-buf based capture. Big thanks! -- 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 21/66] rtl2830: implement own I2C locking
Em Tue, 23 Dec 2014 22:49:14 +0200
Antti Palosaari cr...@iki.fi escreveu:
Own I2C locking is needed due to two special reasons:
1) Chips uses multiple register pages/banks on single I2C slave.
Page is changed via I2C register access.
2) Chip offers muxed/gated I2C adapter for tuner. Gate/mux is
controlled by I2C register access.
Due to these reasons, I2C locking did not fit very well.
I don't like the idea of calling __i2c_transfer() without calling first
i2c_lock_adapter(). This can be dangerous, as the I2C core itself uses
the lock for its own usage.
Ok, this may eventually work ok for now, but a further change at the I2C
core could easily break it. So, we need to double check about such
patch with the I2C maintainer.
Jean,
Are you ok with such patch? If so, please ack.
Regards,
Mauro
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2830.c | 45
+-
drivers/media/dvb-frontends/rtl2830_priv.h | 1 +
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2830.c
b/drivers/media/dvb-frontends/rtl2830.c
index 8abaca6..3a9e4e9 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -43,7 +43,7 @@ static int rtl2830_wr(struct i2c_client *client, u8 reg,
const u8 *val, int len)
buf[0] = reg;
memcpy(buf[1], val, len);
- ret = i2c_transfer(client-adapter, msg, 1);
+ ret = __i2c_transfer(client-adapter, msg, 1);
if (ret == 1) {
ret = 0;
} else {
@@ -73,7 +73,7 @@ static int rtl2830_rd(struct i2c_client *client, u8 reg, u8
*val, int len)
}
};
- ret = i2c_transfer(client-adapter, msg, 2);
+ ret = __i2c_transfer(client-adapter, msg, 2);
if (ret == 2) {
ret = 0;
} else {
@@ -93,16 +93,23 @@ static int rtl2830_wr_regs(struct i2c_client *client, u16
reg, const u8 *val, in
u8 reg2 = (reg 0) 0xff;
u8 page = (reg 8) 0xff;
+ mutex_lock(dev-i2c_mutex);
+
/* switch bank if needed */
if (page != dev-page) {
ret = rtl2830_wr(client, 0x00, page, 1);
if (ret)
- return ret;
+ goto err_mutex_unlock;
dev-page = page;
}
- return rtl2830_wr(client, reg2, val, len);
+ ret = rtl2830_wr(client, reg2, val, len);
+
+err_mutex_unlock:
+ mutex_unlock(dev-i2c_mutex);
+
+ return ret;
}
/* read multiple registers */
@@ -113,16 +120,23 @@ static int rtl2830_rd_regs(struct i2c_client *client,
u16 reg, u8 *val, int len)
u8 reg2 = (reg 0) 0xff;
u8 page = (reg 8) 0xff;
+ mutex_lock(dev-i2c_mutex);
+
/* switch bank if needed */
if (page != dev-page) {
ret = rtl2830_wr(client, 0x00, page, 1);
if (ret)
- return ret;
+ goto err_mutex_unlock;
dev-page = page;
}
- return rtl2830_rd(client, reg2, val, len);
+ ret = rtl2830_rd(client, reg2, val, len);
+
+err_mutex_unlock:
+ mutex_unlock(dev-i2c_mutex);
+
+ return ret;
}
/* read single register */
@@ -815,6 +829,10 @@ static int rtl2830_select(struct i2c_adapter *adap, void
*mux_priv, u32 chan_id)
};
int ret;
+ dev_dbg(client-dev, \n);
+
+ mutex_lock(dev-i2c_mutex);
+
/* select register page */
ret = __i2c_transfer(client-adapter, select_reg_page_msg, 1);
if (ret != 1) {
@@ -841,6 +859,18 @@ err:
return ret;
}
+static int rtl2830_deselect(struct i2c_adapter *adap, void *mux_priv, u32
chan)
+{
+ struct i2c_client *client = mux_priv;
+ struct rtl2830_dev *dev = i2c_get_clientdata(client);
+
+ dev_dbg(client-dev, \n);
+
+ mutex_unlock(dev-i2c_mutex);
+
+ return 0;
+}
+
static struct dvb_frontend *rtl2830_get_dvb_frontend(struct i2c_client
*client)
{
struct rtl2830_dev *dev = i2c_get_clientdata(client);
@@ -886,6 +916,7 @@ static int rtl2830_probe(struct i2c_client *client,
dev-client = client;
dev-pdata = client-dev.platform_data;
dev-sleeping = true;
+ mutex_init(dev-i2c_mutex);
INIT_DELAYED_WORK(dev-stat_work, rtl2830_stat_work);
/* check if the demod is there */
@@ -895,7 +926,7 @@ static int rtl2830_probe(struct i2c_client *client,
/* create muxed i2c adapter for tuner */
dev-adapter = i2c_add_mux_adapter(client-adapter, client-dev,
- client, 0, 0, 0, rtl2830_select, NULL);
+ client, 0, 0, 0, rtl2830_select, rtl2830_deselect);
if (dev-adapter == NULL) {
ret = -ENODEV;
goto err_kfree;
diff --git a/drivers/media/dvb-frontends/rtl2830_priv.h
b/drivers/media/dvb-frontends/rtl2830_priv.h
index 2931889..517758a 100644
---
Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than an exporter can actually do.. I think the scenario you describe could be handled by two sg-lists, if the exporter was clever enough. That's already needed, each attachment has it's own sg-list. After all there's no array of dma_addr_t in the sg tables, so you can't use one sg for more than one mapping. And due to different iommu different devices can easily end up with different addresses. Well, to be fair it may not be explicitly stated, but currently one should assume the dma_addr_t's in the dmabuf sglist are bogus. With gpu's that implement per-process/context page tables, I'm not really sure that there is a sane way to actually do anything else.. BR, -R -- 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 21/66] rtl2830: implement own I2C locking
On 02/02/2015 10:56 PM, Jean Delvare wrote: Hi Mauro, Antti, On Mon, 2 Feb 2015 18:07:26 -0200, Mauro Carvalho Chehab wrote: Em Tue, 23 Dec 2014 22:49:14 +0200 Antti Palosaari cr...@iki.fi escreveu: Own I2C locking is needed due to two special reasons: 1) Chips uses multiple register pages/banks on single I2C slave. Page is changed via I2C register access. This is no good reason to implement your own i2c bus locking. Lots of i2c slave device work that way, and the way to handle it is through a dedicated lock at the i2c slave device level. This is in addition to the standard i2c bus locking and not a replacement. Patch description is bit misleading as it does not implement own I2C bus lock but own 'I2C lock' is there to warrant none will interrupt I/O operation as it needs multiple I2C calls. *** take own I2C lock here 1) I2C mux read to read current register page 2) I2C mux write to switch register page (if needed) 3) I2C mux write to change mux (open gate/repeater for I2C bus tuner is) 4) perform tuner I2C access *** release own I2C lock here Mux is closed automatically after tuner I2C in that case, but very often there is I2C commands needed for that too. 2) Chip offers muxed/gated I2C adapter for tuner. Gate/mux is controlled by I2C register access. This, OTOH, is a valid reason for calling __i2c_transfer, and as a matter of fact a number of dvb frontend drivers already do so. Due to these reasons, I2C locking did not fit very well. I don't like the idea of calling __i2c_transfer() without calling first i2c_lock_adapter(). This can be dangerous, as the I2C core itself uses the lock for its own usage. I think the idea is that the i2c bus lock is already held at the time the muxing code is called. This happens each time the I2C muxing chip is an I2C chip itself. Ok, this may eventually work ok for now, but a further change at the I2C core could easily break it. So, we need to double check about such patch with the I2C maintainer. If it breaks than it'll break a dozen drivers which are already doing that, not just this one. But it's OK, I don't see this happening soon. Jean, Are you ok with such patch? If so, please ack. First of all: I am no longer the maintainer of the I2C subsystem. That being said... The changes look OK to me. I think it's how they are presented which make them look suspect. As I understand it, the extra locking at device level is unrelated with calling unlocked i2c transfer functions. The former change is to address the multi-page/bank register mapping, while the latter is to solve the deadlock due to the i2c bus topology and i2c-based muxing. If I am correct then it would be clearer to make that two separate patches with better descriptions. And if I'm wrong then the patch needs a better description too ;-) 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: HP EC372S (Yuan DVB ExpressCard) crash in 3.18.3
On Mon, 2 Feb 2015, Jonas Jonsson wrote: Hi, I posted a bug on kernel.org (https://bugzilla.kernel.org/show_bug.cgi?id=92301 ) and was asked to sent it to this mail-address. Since this bug involves the dvb-usb driver, it should also be posted to the linux-media mailing list (CC-ed). Alan Stern Jan 29 21:26:51 plattpcn kernel: [ 17.322493] input: UVC Camera (05ca:1812) as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input10 Jan 29 21:26:51 plattpcn kernel: [ 17.322621] usbcore: registered new interface driver uvcvideo Jan 29 21:26:51 plattpcn kernel: [ 17.322623] USB Video Class driver (1.1.1) Jan 29 21:26:51 plattpcn kernel: [ 17.583002] input: HP WMI hotkeys as /devices/virtual/input/input11 Jan 29 21:26:51 plattpcn kernel: [ 18.108106] iwl4965 :02:00.0: loaded firmware version 228.61.2.24 Jan 29 21:26:51 plattpcn kernel: [ 18.360154] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs' Jan 29 21:26:51 plattpcn kernel: [ 18.620404] dvb-usb: found a 'Yuan EC372S' in cold state, will try to load a firmware Jan 29 21:26:51 plattpcn kernel: [ 18.993039] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Jan 29 21:26:51 plattpcn kernel: [ 19.194634] dib0700: firmware started successfully. Jan 29 21:26:51 plattpcn kernel: [ 19.695174] dvb-usb: found a 'Yuan EC372S' in warm state. Jan 29 21:26:51 plattpcn kernel: [ 19.695448] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jan 29 21:26:51 plattpcn kernel: [ 19.695527] DVB: registering new adapter (Yuan EC372S) Jan 29 21:26:51 plattpcn kernel: [ 20.090809] BUG: unable to handle kernel NULL pointer dereference at 0080 Jan 29 21:26:51 plattpcn kernel: [ 20.090987] IP: [a057b061] dib7000p_attach+0x11/0xa0 [dib7000p] Jan 29 21:26:51 plattpcn kernel: [ 20.091007] PGD 36893067 PUD b95b0067 PMD 0 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Oops: 0002 [#1] SMP Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Modules linked in: dib7000p(E) dvb_usb_dib0700(E+) dib7000m(E) arc4(E) dib0090(E) dib0070(E) dib3000mc(E) dibx000_common(E) dvb_usb(E) dvb_core(E) coretemp(E) hp_wmi(E) rc_core(E) sparse_keymap(E) uvcvideo(E) iwl4965(E) videobuf2_vmalloc(E) snd_hda_codec_si3054(E) kvm(E) iwlegacy(E) snd_hda_codec_realtek(E) videobuf2_memops(E) mac80211(E) videobuf2_core(E) snd_hda_codec_generic(E) v4l2_common(E) videodev(E) snd_hda_intel(E) joydev(E) snd_hda_controller(E) serio_raw(E) snd_hda_codec(E) snd_hwdep(E) r852(E) cfg80211(E) snd_pcm(E) sm_common(E) btusb(E) nand(E) snd_seq_midi(E) nand_ecc(E) snd_seq_midi_event(E) bluetooth(E) snd_rawmidi(E) nand_bch(E) snd_seq(E) bch(E) r592(E) snd_seq_device(E) nand_ids(E) snd_timer(E) mtd(E) memstick(E) drm(E) snd(E) soundcore(E) lpc_ich(E) wmi(E) video(E) mac_hid(E) parport_pc(E) ppdev(E) lp(E) parport(E) psmouse(E) ahci(E) libahci(E) firewire_ohci(E) firewire_core(E) sdhci_pci(E) crc_itu_t(E) sdhci(E) r8169(E) mii(E) Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CPU: 0 PID: 442 Comm: systemd-udevd Tainted: GE 3.18.3jonas #1 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Hardware name: Hewlett-Packard HP Pavilion dv9700 Notebook PC/30CB, BIOS F.59 11/25/2008 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] task: 8800b8f68000 ti: 8800b9148000 task.ti: 8800b9148000 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RIP: 0010:[a057b061] [a057b061] dib7000p_attach+0x11/0xa0 [dib7000p] Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RSP: 0018:8800b914ba88 EFLAGS: 00010202 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RAX: 0010 RBX: 8800ba9d1278 RCX: a0581040 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RDX: a0581040 RSI: a0581c2b RDI: 0010 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RBP: 8800b914ba88 R08: 810e47a0 R09: 0001802a0029 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] R10: ea0002ed9fc0 R11: 8107cf84 R12: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] R13: 0010 R14: 8800ba9d1278 R15: 8800ba9d1398 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] FS: 7fd441492880() GS:88013fc0() knlGS: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CS: 0010 DS: ES: CR0: 8005003b Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CR2: 0080 CR3: 36892000 CR4: 07f0 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Stack: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800b914bab8 a055adab 8800ba9d1278 8800ba9d1278 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800ba9d1278 8800b914baf8 a04776b8 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800ba9d
Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Mon, Feb 2, 2015 at 4:46 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than an exporter can actually do.. I think the scenario you describe could be handled by two sg-lists, if the exporter was clever enough. That's already needed, each attachment has it's own sg-list. After all there's no array of dma_addr_t in the sg tables, so you can't use one sg for more than one mapping. And due to different iommu different devices can easily end up with different addresses. Well, to be fair it may not be explicitly stated, but currently one should assume the dma_addr_t's in the dmabuf sglist are bogus. With gpu's that implement per-process/context page tables, I'm not really sure that there is a sane way to actually do anything else.. That's incorrect - and goes dead against the design of scatterlists. yeah, a bit of an abuse, although I'm not sure I see a much better way when a device vaddr depends on user context.. Not only that, but it is entirely possible that you may get handed memory via dmabufs for which there are no struct page's associated with that memory - think about display systems which have their own video memory which is accessible to the GPU, but it isn't system memory. well, I guess anyways when it comes to sharing buffers, it won't be the vram placement of the bo that gets shared ;-) BR, -R In those circumstances, you have to use the dma_addr_t's and not the pages. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.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
Re: [PATCH v2 03/15] [media] adv7180: Use inline function instead of macro
On 02/02/2015 02:36 PM, Mauro Carvalho Chehab wrote: Em Fri, 23 Jan 2015 16:52:22 +0100 Lars-Peter Clausen l...@metafoo.de escreveu: Use a inline function instead of a macro for the container_of helper for getting the driver's state struct from a control. A inline function has the advantage that it is more typesafe and nicer in general. I don't see any advantage on this. See: container_of is already a macro, and it is written in a way that, if you use it with inconsistent values, the compilation will break. Yes, container_of is a macro, because it needs to be a macro. Compilation will also not always break if you pass in a incorrect type, it might succeed with even generating a warning. Furthermore if compilation breaks the error message is completely incomprehensible. Using a function instead makes sure that the error message you get is in the style of passing argument of wrong type to function, expected typeX, got typeY. Also, there's the risk that, for whatever reason, gcc to decide to not inline this. If the compiler does not inline this it probably has a good reason to do so. Not inlining this will not break the functionality, so it is not a problem. - 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
Re: [PATCH v4 2/2] V4L: add CCF support to the v4l2_clk API
Hi, Guennadi
On 2/1/2015 7:12 PM, Guennadi Liakhovetski wrote:
V4L2 clocks, e.g. used by camera sensors for their master clock, do not
have to be supplied by a different V4L2 driver, they can also be
supplied by an independent source. In this case the standart kernel
clock API should be used to handle such clocks. This patch adds support
for such cases.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thanks for the patch.
Tested-by: Josh Wu josh...@atmel.com
Best Regards,
Josh Wu
---
v4: sizeof(*clk) :)
drivers/media/v4l2-core/v4l2-clk.c | 48 +++---
include/media/v4l2-clk.h | 2 ++
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-clk.c
b/drivers/media/v4l2-core/v4l2-clk.c
index 3ff0b00..9f8cb20 100644
--- a/drivers/media/v4l2-core/v4l2-clk.c
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -9,6 +9,7 @@
*/
#include linux/atomic.h
+#include linux/clk.h
#include linux/device.h
#include linux/errno.h
#include linux/list.h
@@ -37,6 +38,21 @@ static struct v4l2_clk *v4l2_clk_find(const char *dev_id)
struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
{
struct v4l2_clk *clk;
+ struct clk *ccf_clk = clk_get(dev, id);
+
+ if (PTR_ERR(ccf_clk) == -EPROBE_DEFER)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ if (!IS_ERR_OR_NULL(ccf_clk)) {
+ clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+ if (!clk) {
+ clk_put(ccf_clk);
+ return ERR_PTR(-ENOMEM);
+ }
+ clk-clk = ccf_clk;
+
+ return clk;
+ }
mutex_lock(clk_lock);
clk = v4l2_clk_find(dev_name(dev));
@@ -56,6 +72,12 @@ void v4l2_clk_put(struct v4l2_clk *clk)
if (IS_ERR(clk))
return;
+ if (clk-clk) {
+ clk_put(clk-clk);
+ kfree(clk);
+ return;
+ }
+
mutex_lock(clk_lock);
list_for_each_entry(tmp, clk_list, list)
@@ -93,8 +115,12 @@ static void v4l2_clk_unlock_driver(struct v4l2_clk *clk)
int v4l2_clk_enable(struct v4l2_clk *clk)
{
- int ret = v4l2_clk_lock_driver(clk);
+ int ret;
+ if (clk-clk)
+ return clk_prepare_enable(clk-clk);
+
+ ret = v4l2_clk_lock_driver(clk);
if (ret 0)
return ret;
@@ -120,6 +146,9 @@ void v4l2_clk_disable(struct v4l2_clk *clk)
{
int enable;
+ if (clk-clk)
+ return clk_disable_unprepare(clk-clk);
+
mutex_lock(clk-lock);
enable = --clk-enable;
@@ -137,8 +166,12 @@ EXPORT_SYMBOL(v4l2_clk_disable);
unsigned long v4l2_clk_get_rate(struct v4l2_clk *clk)
{
- int ret = v4l2_clk_lock_driver(clk);
+ int ret;
+
+ if (clk-clk)
+ return clk_get_rate(clk-clk);
+ ret = v4l2_clk_lock_driver(clk);
if (ret 0)
return ret;
@@ -157,7 +190,16 @@ EXPORT_SYMBOL(v4l2_clk_get_rate);
int v4l2_clk_set_rate(struct v4l2_clk *clk, unsigned long rate)
{
- int ret = v4l2_clk_lock_driver(clk);
+ int ret;
+
+ if (clk-clk) {
+ long r = clk_round_rate(clk-clk, rate);
+ if (r 0)
+ return r;
+ return clk_set_rate(clk-clk, r);
+ }
+
+ ret = v4l2_clk_lock_driver(clk);
if (ret 0)
return ret;
diff --git a/include/media/v4l2-clk.h b/include/media/v4l2-clk.h
index 928045f..3ef6e3d 100644
--- a/include/media/v4l2-clk.h
+++ b/include/media/v4l2-clk.h
@@ -22,6 +22,7 @@
struct module;
struct device;
+struct clk;
struct v4l2_clk {
struct list_head list;
const struct v4l2_clk_ops *ops;
@@ -29,6 +30,7 @@ struct v4l2_clk {
int enable;
struct mutex lock; /* Protect the enable count */
atomic_t use_count;
+ struct clk *clk;
void *priv;
};
--
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
[BUG] - Why anyone fix this problem?
Is it possible that the problem I explained here isn't interesting for anyone? The device is supported by kernel but obviously there is a bug with DVB-T. I have the working firmware (on Windows) for DVB-T if you need it. http://www.spinics.net/lists/linux-media/msg85505.html http://www.spinics.net/lists/linux-media/msg85478.html http://www.spinics.net/lists/linux-media/msg85432.html Regards Francesco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/15] [media] adv7180: Use inline function instead of macro
Em Fri, 23 Jan 2015 16:52:22 +0100
Lars-Peter Clausen l...@metafoo.de escreveu:
Use a inline function instead of a macro for the container_of helper for
getting the driver's state struct from a control. A inline function has the
advantage that it is more typesafe and nicer in general.
I don't see any advantage on this.
See: container_of is already a macro, and it is written in a way that, if
you use it with inconsistent values, the compilation will break.
Also, there's the risk that, for whatever reason, gcc to decide to not
inline this.
So, this doesn't sound a good idea.
Regards,
Mauro
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7180.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index f424a4d..f2508abe 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -130,9 +130,11 @@ struct adv7180_state {
boolpowered;
u8 input;
};
-#define to_adv7180_sd(_ctrl) (container_of(_ctrl-handler, \
- struct adv7180_state, \
- ctrl_hdl)-sd)
+
+static struct adv7180_state *ctrl_to_adv7180(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct adv7180_state, ctrl_hdl);
+}
static v4l2_std_id adv7180_std_to_v4l2(u8 status1)
{
@@ -345,9 +347,8 @@ static int adv7180_s_power(struct v4l2_subdev *sd, int on)
static int adv7180_s_ctrl(struct v4l2_ctrl *ctrl)
{
- struct v4l2_subdev *sd = to_adv7180_sd(ctrl);
- struct adv7180_state *state = to_state(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct adv7180_state *state = ctrl_to_adv7180(ctrl);
+ struct i2c_client *client = v4l2_get_subdevdata(state-sd);
int ret = mutex_lock_interruptible(state-mutex);
int val;
--
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 PATCH 1/2] [media] videodev2: Add V4L2_BUF_FLAG_LAST
On 01/22/2015 12:28 PM, Philipp Zabel wrote:
From: Peter Seiderer ps.rep...@gmx.net
This v4l2_buffer flag can be used by drivers to mark a capture buffer
as the last generated buffer, for example after a V4L2_DEC_CMD_STOP
command was issued.
Signed-off-by: Peter Seiderer ps.rep...@gmx.net
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
include/uapi/linux/videodev2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index fbdc360..c642c10 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -809,6 +809,8 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_TSTAMP_SRC_MASK0x0007
#define V4L2_BUF_FLAG_TSTAMP_SRC_EOF 0x
#define V4L2_BUF_FLAG_TSTAMP_SRC_SOE 0x0001
+/* mem2mem encoder/decoder */
+#define V4L2_BUF_FLAG_LAST 0x0010
/**
* struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
You probably knew this, but this should of course be documented in the V4L2
spec. In particular the spec should be clear about *when* the flag is set.
Also, any drivers that need this should be updated as well. Otherwise
applications
cannot rely on it.
Regards,
Hans
--
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 PATCH 2/2] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
On 01/22/2015 12:28 PM, Philipp Zabel wrote:
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
This looks OK to me, although I would like to see comments from others as well.
Of course, this needs to be documented in the spec as well.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
TODO: (How) should the last_buffer_dequeud flag be cleared in reaction to
V4L2_DEC_CMD_START?
I would suggest an inline function in videobuf2-core.h that clears the flag
and that drivers can call. I don't think the vb2 core can detect when it is
OK to clear the flag, it needs to be told by the driver (correct me if I am
wrong).
Regards,
Hans
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +-
drivers/media/v4l2-core/videobuf2-core.c | 18 +-
include/media/videobuf2-core.h | 1 +
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 80c588f..1b5b432 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -564,8 +564,16 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
if (list_empty(src_q-done_list))
poll_wait(file, src_q-done_wq, wait);
- if (list_empty(dst_q-done_list))
+ if (list_empty(dst_q-done_list)) {
+ /*
+ * If the last buffer was dequeued from the capture queue,
+ * return immediately. DQBUF will return -EPIPE.
+ */
+ if (dst_q-last_buffer_dequeued)
+ return rc | POLLIN | POLLRDNORM;
+
poll_wait(file, dst_q-done_wq, wait);
+ }
if (m2m_ctx-m2m_dev-m2m_ops-lock)
m2m_ctx-m2m_dev-m2m_ops-lock(m2m_ctx-priv);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index d09a891..c2c2eac 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2046,6 +2046,10 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
struct vb2_buffer *vb = NULL;
int ret;
+ if (q-last_buffer_dequeued) {
+ dprintk(3, last buffer dequeued already\n);
+ return -EPIPE;
+ }
if (b-type != q-type) {
dprintk(1, invalid buffer type\n);
return -EINVAL;
@@ -2073,6 +2077,9 @@ static int vb2_internal_dqbuf(struct vb2_queue *q,
struct v4l2_buffer *b, bool n
/* Remove from videobuf queue */
list_del(vb-queued_entry);
q-queued_count--;
+ if (!V4L2_TYPE_IS_OUTPUT(q-type)
+ vb-v4l2_buf.flags V4L2_BUF_FLAG_LAST)
+ q-last_buffer_dequeued = true;
/* go back to dequeued state */
__vb2_dqbuf(vb);
@@ -2286,6 +2293,7 @@ static int vb2_internal_streamoff(struct vb2_queue *q,
enum v4l2_buf_type type)
*/
__vb2_queue_cancel(q);
q-waiting_for_buffers = !V4L2_TYPE_IS_OUTPUT(q-type);
+ q-last_buffer_dequeued = false;
dprintk(3, successful\n);
return 0;
@@ -2628,8 +2636,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
if (V4L2_TYPE_IS_OUTPUT(q-type) q-queued_count q-num_buffers)
return res | POLLOUT | POLLWRNORM;
- if (list_empty(q-done_list))
+ if (list_empty(q-done_list)) {
+ /*
+ * If the last buffer was dequeued from a capture queue,
+ * return immediately. DQBUF will return -EPIPE.
+ */
+ if (!V4L2_TYPE_IS_OUTPUT(q-type) q-last_buffer_dequeued)
+ return res | POLLIN | POLLRDNORM;
+
poll_wait(file, q-done_wq, wait);
+ }
/*
* Take first buffer available for dequeuing.
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bd2cec2..ca337bf 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -429,6 +429,7 @@ struct vb2_queue {
unsigned intstart_streaming_called:1;
unsigned interror:1;
unsigned intwaiting_for_buffers:1;
+ unsigned intlast_buffer_dequeued:1;
struct vb2_fileio_data *fileio;
struct vb2_threadio_data*threadio;
--
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] staging: bcm2048: Delete an unnecessary check before the function call video_unregister_device
From: Markus Elfring elfr...@users.sourceforge.net Date: Mon, 2 Feb 2015 13:20:23 +0100 The video_unregister_device() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net --- drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c b/drivers/staging/media/bcm2048/radio-bcm2048.c index 60a57b2..f308078 100644 --- a/drivers/staging/media/bcm2048/radio-bcm2048.c +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c @@ -2684,9 +2684,7 @@ static int __exit bcm2048_i2c_driver_remove(struct i2c_client *client) vd = bdev-videodev; bcm2048_sysfs_unregister_properties(bdev, ARRAY_SIZE(attrs)); - - if (vd) - video_unregister_device(vd); + video_unregister_device(vd); if (bdev-power_state) bcm2048_set_power_state(bdev, BCM2048_POWER_OFF); -- 2.2.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] - Why anyone fix this problem?
Mauro, Francesco has reported problem with DVB-T on Siano sms2270. Basically him reach a lock with tzap but seems not have stream data. I tried to help him to debug but I can't reproduce their problem once I have isdb-t only here. He is using some dvb firmware with device that seems works fine on Windows. Cheers, - Roberto - Roberto On Mon, Feb 2, 2015 at 10:10 AM, Francesco Other francesco.ot...@gmail.com wrote: Is it possible that the problem I explained here isn't interesting for anyone? The device is supported by kernel but obviously there is a bug with DVB-T. I have the working firmware (on Windows) for DVB-T if you need it. http://www.spinics.net/lists/linux-media/msg85505.html http://www.spinics.net/lists/linux-media/msg85478.html http://www.spinics.net/lists/linux-media/msg85432.html Regards Francesco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.20] au0828: fixes and vb2 conversion
The following changes since commit a5f43c18fceb2b96ec9fddb4348f5282a71cf2b0: [media] Documentation/video4linux: remove obsolete text files (2015-01-29 19:16:30 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git au0828 for you to fetch changes up to bdf9b69416a114cd8a6eaa96384535b2e0275653: media: au0828 - convert to use videobuf2 (2015-02-02 13:08:02 +0100) Shuah Khan (3): media: fix au0828_analog_register() to not free au0828_dev media: fix au0828 compile error from au0828_boards initialization media: au0828 - convert to use videobuf2 drivers/media/usb/au0828/Kconfig| 2 +- drivers/media/usb/au0828/au0828-cards.c | 2 +- drivers/media/usb/au0828/au0828-vbi.c | 122 --- drivers/media/usb/au0828/au0828-video.c | 964 drivers/media/usb/au0828/au0828.h | 61 +++--- 5 files changed, 443 insertions(+), 708 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
[PATCH] cx231xx: don't use dev it not allocated
changeset 5eeb3014827f added a fixup at the error check code. However, it introduced a new error: drivers/media/usb/cx231xx/cx231xx-cards.c:1586 cx231xx_usb_probe() error: we previously assumed 'dev' could be null (see line 1430) This happens when dev = kmalloc() fails. So, instead of relying on it to succeed, just change the parameter of clear_bit() from 'dev-devno' to 'nr'. Cc: Alexey Khoroshilov khoroshi...@ispras.ru Cc: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c index 33c2fa2e7596..da03733690bd 100644 --- a/drivers/media/usb/cx231xx/cx231xx-cards.c +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c @@ -1583,7 +1583,7 @@ err_v4l2: usb_set_intfdata(interface, NULL); err_if: usb_put_dev(udev); - clear_bit(dev-devno, cx231xx_devused); + clear_bit(nr, cx231xx_devused); return retval; } -- 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] staging: media: vino: vino: Removed variables that is never used
On 01/28/2015 11:47 PM, Rickard Strandqvist wrote: Variable ar assigned a value that is never used. I have also removed all the code that thereby serves no purpose. This was found using a static code analysis program called cppcheck FYI: I've dropped this patch since the vino driver will be removed in 3.20. Regards. Hans Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/staging/media/vino/vino.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/media/vino/vino.c b/drivers/staging/media/vino/vino.c index 2c85357..f43c1ea 100644 --- a/drivers/staging/media/vino/vino.c +++ b/drivers/staging/media/vino/vino.c @@ -2375,7 +2375,6 @@ static irqreturn_t vino_interrupt(int irq, void *dev_id) next_4_desc = vino-a.next_4_desc; unsigned int line_count_2, page_index_2, - field_counter_2, start_desc_tbl_2, next_4_desc_2; #endif @@ -2421,7 +2420,6 @@ static irqreturn_t vino_interrupt(int irq, void *dev_id) #ifdef VINO_DEBUG_INT line_count_2 = vino-a.line_count; page_index_2 = vino-a.page_index; - field_counter_2 = vino-a.field_counter; start_desc_tbl_2 = vino-a.start_desc_tbl; next_4_desc_2 = vino-a.next_4_desc; -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/15] [media] adv7180: Use inline function instead of macro
On 02/02/2015 02:36 PM, Mauro Carvalho Chehab wrote:
Em Fri, 23 Jan 2015 16:52:22 +0100
Lars-Peter Clausen l...@metafoo.de escreveu:
Use a inline function instead of a macro for the container_of helper for
getting the driver's state struct from a control. A inline function has the
advantage that it is more typesafe and nicer in general.
I don't see any advantage on this.
See: container_of is already a macro, and it is written in a way that, if
you use it with inconsistent values, the compilation will break.
Also, there's the risk that, for whatever reason, gcc to decide to not
inline this.
For the record: I disagree with this. I think a static inline is more readable
than a macro. It is also consistent with other existing i2c subdev drivers since
they all use a static inline as well. And if in rare cases gcc might decide not
to inline this, then so what? You really won't notice any difference. It's an
i2c device, so it's slow as molasses anyway. Readability is much more important
IMHO.
On the other hand, it's not critical enough for me to make a big deal out of
it if this patch is dropped.
Regards,
Hans
So, this doesn't sound a good idea.
Regards,
Mauro
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/adv7180.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index f424a4d..f2508abe 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -130,9 +130,11 @@ struct adv7180_state {
boolpowered;
u8 input;
};
-#define to_adv7180_sd(_ctrl) (container_of(_ctrl-handler, \
-struct adv7180_state, \
-ctrl_hdl)-sd)
+
+static struct adv7180_state *ctrl_to_adv7180(struct v4l2_ctrl *ctrl)
+{
+return container_of(ctrl-handler, struct adv7180_state, ctrl_hdl);
+}
static v4l2_std_id adv7180_std_to_v4l2(u8 status1)
{
@@ -345,9 +347,8 @@ static int adv7180_s_power(struct v4l2_subdev *sd, int
on)
static int adv7180_s_ctrl(struct v4l2_ctrl *ctrl)
{
-struct v4l2_subdev *sd = to_adv7180_sd(ctrl);
-struct adv7180_state *state = to_state(sd);
-struct i2c_client *client = v4l2_get_subdevdata(sd);
+struct adv7180_state *state = ctrl_to_adv7180(ctrl);
+struct i2c_client *client = v4l2_get_subdevdata(state-sd);
int ret = mutex_lock_interruptible(state-mutex);
int val;
--
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 v4] [media] Add LVDS RGB media bus formats
Hi Steve, Am Samstag, den 31.01.2015, 20:54 +0100 schrieb Steve Cotton: On Wed, Jan 28, 2015 at 05:55:06PM +0100, Philipp Zabel wrote: + paraOn LVDS buses, usually each sample is transferred serialized in + seven time slots per pixel clock, on three (18-bit) or four (24-bit) + differential data pairs at the same time. The remaining bits are used for + control signals as defined by SPWG/PSWG/VESA or JEIDA standards. + The 24-bit RGB format serialized in seven time slots on four lanes using + JEIDA defined bit mapping will be named + constantMEDIA_BUS_FMT_RGB888_1X7X3_JEIDA/constant, for example. + /para Hi Philipp, Should that example be MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA instead of 1X7X3? Yes, thank you. I'll fix this and resend. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: atmel-isi: increase the burst length to improve the performance
Hi, Guennadi Ping? what about the status of this patch? Best Regards, Josh Wu On 11/25/2014 5:30 PM, Josh Wu wrote: The burst length could be BEATS_4/8/16. Before this patch, isi use default value BEATS_4. To imporve the performance we could set it to BEATS_16. Otherwise sometime it would cause the ISI overflow error. Reported-by: Bo Shen voice.s...@atmel.com Signed-off-by: Josh Wu josh...@atmel.com --- drivers/media/platform/soc_camera/atmel-isi.c | 2 ++ include/media/atmel-isi.h | 4 2 files changed, 6 insertions(+) diff --git a/drivers/media/platform/soc_camera/atmel-isi.c b/drivers/media/platform/soc_camera/atmel-isi.c index ee5650f..fda587b 100644 --- a/drivers/media/platform/soc_camera/atmel-isi.c +++ b/drivers/media/platform/soc_camera/atmel-isi.c @@ -839,6 +839,8 @@ static int isi_camera_set_bus_param(struct soc_camera_device *icd) if (isi-pdata.full_mode) cfg1 |= ISI_CFG1_FULL_MODE; + cfg1 |= ISI_CFG1_THMASK_BEATS_16; + isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS); isi_writel(isi, ISI_CFG1, cfg1); diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h index c2e5703..6008b09 100644 --- a/include/media/atmel-isi.h +++ b/include/media/atmel-isi.h @@ -59,6 +59,10 @@ #define ISI_CFG1_FRATE_DIV_MASK (7 8) #define ISI_CFG1_DISCR(1 11) #define ISI_CFG1_FULL_MODE(1 12) +/* Definition for THMASK(ISI_V2) */ +#defineISI_CFG1_THMASK_BEATS_4 (0 13) +#defineISI_CFG1_THMASK_BEATS_8 (1 13) +#defineISI_CFG1_THMASK_BEATS_16(2 13) /* Bitfields in CFG2 */ #define ISI_CFG2_GRAYSCALE(1 13) -- 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On 02/01/2015 02:06 PM, Raimonds Cicans wrote:
On 29.01.2015 14:12, Hans Verkuil wrote:
On 01/29/15 12:51, Raimonds Cicans wrote:
On 29.01.2015 09:33, Hans Verkuil wrote:
On 01/11/2015 10:33 AM, Raimonds Cicans wrote:
I contacted you because I am hit by regression caused by your commit:
453afdd [media] cx23885: convert to vb2
My system:
AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard
TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver)
After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7
(have commit) I started receiving following IOMMU related messages:
1)
AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d
address=0x0637c000 flags=0x]
where device=0a:00.0 is TBS6981 card
As far as I can tell this has nothing to do with the cx23885 driver but is
a bug in the amd iommu/BIOS. See e.g.:
https://bbs.archlinux.org/viewtopic.php?pid=1309055
I managed to reproduce the Intel equivalent if I enable
CONFIG_IOMMU_SUPPORT.
Most likely due to broken BIOS/ACPI/whatever information that's read by the
kernel. I would recommend disabling this kernel option.
Maybe...
But on other hand this did not happen on old kernel with old driver.
And when I did bisection on old kernel + media tree I started to
receive this message only on new driver.
Was CONFIG_IOMMU_SUPPORT enabled in the old kernel?
zgrep CONFIG_IOMMU_SUPPORT /proc/config.gz
CONFIG_IOMMU_SUPPORT=y
Raimonds Cicans
Raimonds and Jurgen,
Can you both test with the following patch applied to the driver:
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 1ad4994..72df5ae 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -1497,6 +1497,7 @@ void cx23885_buf_queue(struct cx23885_tsport *port,
struct cx23885_buffer *buf)
buf-risc.jmp[0] = cpu_to_le32(RISC_JUMP | RISC_CNT_INC);
buf-risc.jmp[1] = cpu_to_le32(buf-risc.dma + 12);
buf-risc.jmp[2] = cpu_to_le32(0); /* bits 63-32 */
+ wmb();
spin_lock_irqsave(dev-slock, flags);
if (list_empty(cx88q-active)) {
@@ -1505,10 +1506,12 @@ void cx23885_buf_queue(struct cx23885_tsport *port,
struct cx23885_buffer *buf)
buf, buf-vb.v4l2_buf.index, __func__);
} else {
buf-risc.cpu[0] |= cpu_to_le32(RISC_IRQ1);
+ wmb();
prev = list_entry(cx88q-active.prev, struct cx23885_buffer,
queue);
list_add_tail(buf-queue, cx88q-active);
prev-risc.jmp[1] = cpu_to_le32(buf-risc.dma);
+ wmb();
dprintk(1, [%p/%d] %s - append to active\n,
buf, buf-vb.v4l2_buf.index, __func__);
}
I wonder if there is some PCI write reordering going on that is causing some of
the weird
behavior that you see.
Regards,
Hans
--
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 1/5] [media] horus3a: Sony Horus3A DVB-S/S2 tuner driver
DVB-S/S2 frontend driver for Sony Horus3A (CXD2832AER) chip
Signed-off-by: Kozlov Sergey se...@netup.ru
---
MAINTAINERS |9 +
drivers/media/dvb-frontends/Kconfig |7 +
drivers/media/dvb-frontends/Makefile |1 +
drivers/media/dvb-frontends/horus3a.c | 429 +
drivers/media/dvb-frontends/horus3a.h | 53
5 files changed, 499 insertions(+)
create mode 100644 drivers/media/dvb-frontends/horus3a.c
create mode 100644 drivers/media/dvb-frontends/horus3a.h
diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8..a3a1767 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4365,6 +4365,15 @@ W: http://linuxtv.org
S: Odd Fixes
F: drivers/media/usb/hdpvr/
+HORUS3A MEDIA DRIVER
+M: Sergey Kozlov se...@netup.ru
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+W: http://netup.tv/
+T: git git://linuxtv.org/media_tree.git
+S: Supported
+F: drivers/media/dvb-frontends/horus3a*
+
HWPOISON MEMORY FAILURE HANDLING
M: Naoya Horiguchi n-horigu...@ah.jp.nec.com
L: linux...@kvack.org
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index 6c75418..c2c157b 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -796,6 +796,13 @@ config DVB_AF9033
depends on DVB_CORE I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
+config DVB_HORUS3A
+ tristate Sony Horus3A tuner
+ depends on DVB_CORE I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Say Y when you want to support this frontend.
+
comment Tools to develop new frontends
config DVB_DUMMY_FE
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index ba59df6..3aa05f3 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -116,3 +116,4 @@ obj-$(CONFIG_DVB_M88RS2000) += m88rs2000.o
obj-$(CONFIG_DVB_AF9033) += af9033.o
obj-$(CONFIG_DVB_AS102_FE) += as102_fe.o
obj-$(CONFIG_DVB_TC90522) += tc90522.o
+obj-$(CONFIG_DVB_HORUS3A) += horus3a.o
diff --git a/drivers/media/dvb-frontends/horus3a.c
b/drivers/media/dvb-frontends/horus3a.c
new file mode 100644
index 000..aaf61d5ef
--- /dev/null
+++ b/drivers/media/dvb-frontends/horus3a.c
@@ -0,0 +1,429 @@
+/*
+ * horus3a.h
+ *
+ * Sony Horus3A DVB-S/S2 tuner driver
+ *
+ * Copyright 2012 Sony Corporation
+ * Copyright (C) 2014 NetUP Inc.
+ * Copyright (C) 2014 Sergey Kozlov se...@netup.ru
+ * Copyright (C) 2014 Abylay Ospan aos...@netup.ru
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/slab.h
+#include linux/module.h
+#include linux/dvb/frontend.h
+#include linux/types.h
+#include horus3a.h
+#include dvb_frontend.h
+
+static int debug;
+module_param(debug, int, 0644);
+
+#define dprintk(args...) \
+ do { \
+ if (debug) \
+ dev_dbg(priv-i2c-dev, args); \
+ } while (0)
+
+enum horus3a_state {
+ STATE_UNKNOWN,
+ STATE_SLEEP,
+ STATE_ACTIVE
+};
+
+struct horus3a_priv {
+ u32 frequency;
+ u8 i2c_address;
+ struct i2c_adapter *i2c;
+ enum horus3a_state state;
+ void*set_tuner_data;
+ int (*set_tuner)(void *, int);
+};
+
+static void horus3a_i2c_debug(struct horus3a_priv *priv,
+ u8 reg, u8 write, const u8 *data, u32 len)
+{
+ u32 i;
+ u8 buf[128];
+ int offst = 0;
+
+ for (i = 0; i len; i++) {
+ offst += snprintf(buf + offst, sizeof(buf) - offst, %02x,
+ data[i]);
+ if (offst = sizeof(buf) - 1)
+ break;
+ }
+ dprintk(horus3a: I2C %s 0x%02x [%s ]\n,
+ (write == 0 ? read : write), reg, buf);
+}
+
+static int horus3a_write_regs(struct horus3a_priv *priv,
+ u8 reg, const u8 *data, u32 len)
+{
+ int ret;
+ u8 buf[len+1];
+ struct i2c_msg msg[1] = {
+ {
+ .addr = priv-i2c_address,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf,
+ }
+ };
+
+ horus3a_i2c_debug(priv, reg, 1, data, len);
+ buf[0] = reg;
+ memcpy(buf[1], data, len);
+
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (ret == 1) {
+ ret = 0;
+ } else
Re: [PATCH] media: i2c: ADV7604: Migrate to regmap
Hi Pablo, Jean-Michel,
On 02/01/2015 11:08 AM, Jean-Michel Hautbois wrote:
This is a preliminary patch in order to add support for ALSA.
It replaces all current i2c access with regmap.
Add the registers which will then be used too, as these are declared at init.
Signed-off-by: Pablo Anton pablo.an...@vodalys-labs.com
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
drivers/media/i2c/adv7604.c | 428
+---
include/media/adv7604.h | 129 +
2 files changed, 455 insertions(+), 102 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e43dd2e..af19544 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -43,6 +43,8 @@
#include media/v4l2-dv-timings.h
#include media/v4l2-of.h
+#include linux/regmap.h
+
static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, debug level (0-2));
@@ -165,6 +167,9 @@ struct adv7604_state {
/* i2c clients */
struct i2c_client *i2c_clients[ADV7604_PAGE_MAX];
+ /* Regmaps */
+ struct regmap *regmap[ADV7604_PAGE_MAX];
+
/* controls */
struct v4l2_ctrl *detect_tx_5v_ctrl;
struct v4l2_ctrl *analog_sampling_phase_ctrl;
@@ -353,84 +358,53 @@ static inline unsigned vtotal(const struct
v4l2_bt_timings *t)
return V4L2_DV_BT_FRAME_HEIGHT(t);
}
-/* --- */
-
-static s32 adv_smbus_read_byte_data_check(struct i2c_client *client,
- u8 command, bool check)
-{
- union i2c_smbus_data data;
-
- if (!i2c_smbus_xfer(client-adapter, client-addr, client-flags,
- I2C_SMBUS_READ, command,
- I2C_SMBUS_BYTE_DATA, data))
- return data.byte;
- if (check)
- v4l_err(client, error reading %02x, %02x\n,
- client-addr, command);
- return -EIO;
-}
-
-static s32 adv_smbus_read_byte_data(struct adv7604_state *state,
- enum adv7604_page page, u8 command)
-{
- return adv_smbus_read_byte_data_check(state-i2c_clients[page],
- command, true);
-}
-
-static s32 adv_smbus_write_byte_data(struct adv7604_state *state,
- enum adv7604_page page, u8 command,
- u8 value)
+static int regmap_read_check(struct adv7604_state *state,
+ int client_page, u8 reg)
{
- struct i2c_client *client = state-i2c_clients[page];
- union i2c_smbus_data data;
+ struct i2c_client *client = state-i2c_clients[client_page];
int err;
- int i;
+ unsigned int val;
- data.byte = value;
- for (i = 0; i 3; i++) {
- err = i2c_smbus_xfer(client-adapter, client-addr,
- client-flags,
- I2C_SMBUS_WRITE, command,
- I2C_SMBUS_BYTE_DATA, data);
- if (!err)
- break;
+ err = regmap_read(state-regmap[client_page], reg, val);
+
+ if (err) {
+ v4l_err(client, error reading %02x, %02x\n,
+ client-addr, reg);
+ return err;
}
- if (err 0)
- v4l_err(client, error writing %02x, %02x, %02x\n,
- client-addr, command, value);
- return err;
+ return val;
}
-static s32 adv_smbus_write_i2c_block_data(struct adv7604_state *state,
- enum adv7604_page page, u8 command,
- unsigned length, const u8 *values)
+/* regmap_write_block(): Write raw data with a maximum of I2C_SMBUS_BLOCK_MAX
+ * size to one or more registers.
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+static int regmap_write_block(struct adv7604_state *state, int client_page,
+ unsigned int init_reg, const void *val,
+ size_t val_len)
{
- struct i2c_client *client = state-i2c_clients[page];
- union i2c_smbus_data data;
+ struct regmap *regmap = state-regmap[client_page];
- if (length I2C_SMBUS_BLOCK_MAX)
- length = I2C_SMBUS_BLOCK_MAX;
- data.block[0] = length;
- memcpy(data.block + 1, values, length);
- return i2c_smbus_xfer(client-adapter, client-addr, client-flags,
- I2C_SMBUS_WRITE, command,
- I2C_SMBUS_I2C_BLOCK_DATA, data);
-}
+ if (val_len I2C_SMBUS_BLOCK_MAX)
+ val_len = I2C_SMBUS_BLOCK_MAX;
-/* --- */
+ return regmap_raw_write(regmap, init_reg, val, val_len);
+}
Re: Vivid test device: adding YU12
On 01/29/2015 03:44 AM, Miguel Casas-Sanchez wrote: Hi folks, I've been trying to add a triplanar format to those that vivid can generate, and didn't quite manage :( So, I tried adding code for it like in the patch (with some dprintk() as well) to clarify what I wanted to do. Module is insmod'ed like insmod vivid.ko n_devs=1 node_types=0x1 multiplanar=2 vivid_debug=1 You are confusing something: PIX_FMT_YUV420 is single-planar, not multi-planar. That is, all image data is contained in one buffer. PIX_FMT_YUV420M is multi-planar, however. So you need to think which one you actually want to support. Another problem is that for the chroma part you need to average the values over four pixels. So the TPG needs to be aware of the previous line. This makes the TPG more complicated, and of course it is the reason why I didn't implement 4:2:0 formats :-) I would implement YUV420 first, and (if needed) YUV420M and/or NV12 can easily be added later. Regards, Hans With the patch, vivid: - seems to enumerate the new triplanar format all right - vid_s_fmt_vid_cap() works as intended too, apparently - when arriving to vid_cap_queue_setup(), the size of the different sub-arrays does not look quite ok. - Generated video is, visually, all green. I added as well a capture output dmesgs. Not much of interest here, the first few lines configure the queue -- with my few added dprintk it can be seen that the queue sizes are seemingly incorrect. If and when this part is up and running, I wanted to use Vivid to test dma-buf based capture. Big thanks! -- 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 FOR v3.20] Various fixes
The following changes since commit a5f43c18fceb2b96ec9fddb4348f5282a71cf2b0: [media] Documentation/video4linux: remove obsolete text files (2015-01-29 19:16:30 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.20c for you to fetch changes up to 533ab6434b8d57778bd764bcae2e9ec8fdf068a5: davinci: add V4L2 dependencies (2015-02-02 11:49:28 +0100) Alexey Khoroshilov (1): cx231xx: fix usbdev leak on failure paths in cx231xx_usb_probe() Arnd Bergmann (4): timberdale: do not select TIMB_DMA radio/aimslab: use mdelay instead of udelay siano: fix Kconfig dependencies davinci: add V4L2 dependencies Hans Verkuil (1): vivid: use consistent colorspace/Y'CbCr Encoding strings Ismael Luceno (1): MAINTAINERS: Update solo6x10 entry Nicholas Mc Guire (1): pvrusb2: use msecs_to_jiffies for conversion Prabhakar Lad (1): media: am437x: fix sparse warnings MAINTAINERS | 1 + drivers/media/mmc/siano/Kconfig | 2 ++ drivers/media/platform/Kconfig | 6 ++ drivers/media/platform/am437x/am437x-vpfe.c | 5 ++--- drivers/media/platform/davinci/Kconfig | 6 +++--- drivers/media/platform/vivid/vivid-ctrls.c | 4 ++-- drivers/media/radio/radio-aimslab.c | 4 ++-- drivers/media/usb/cx231xx/cx231xx-cards.c | 7 --- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 19 --- drivers/media/usb/siano/Kconfig | 2 ++ 10 files changed, 28 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] WmT: adv7604 driver compatibility
Hi Guennadi,
On Sunday 01 February 2015 12:26:11 Guennadi Liakhovetski wrote:
On a second thought:
On Sun, 1 Feb 2015, Guennadi Liakhovetski wrote:
Hi Wills,
Thanks for the patch. First and foremost, the title of the patch is wrong.
This patch does more than just adding some adv7604 compatibility. It's
adding pad-level API to soc-camera.
This is just a rough review. I'm not an expert in media-controller /
pad-level API, I hope someone with a better knowledge of those areas will
help me reviewing this.
Another general comment: it has been discussed since a long time, whether
a wrapper wouldn't be desired to enable a seamless use of both subdev
drivers using and not using the pad-level API. Maybe it's the right time
now?..
This would be a considerable change and would most probably take a rather
long time, given how busy everyone is.
If I understood correctly Hans Verkuil told me over the weekend that he wanted
to address this problem in the near future. Hans, could you detail your plans
?
I personally would be fine with a (yet another) intermittent solution,
whereby we create a soc_camera_subdev.c file, in which we collect all those
function to call either a video or a pad subdev operation, depending on
whether the latter is available. E.g.
int soc_camera_sd_enum_mbus_fmt(sd, code)
{
int ret;
if (v4l2_subdev_has_op(sd, pad, enum_mbus_code)) {
ret = v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, code);
} else {
u32 pixcode;
ret = v4l2_subdev_call(sd, video, enum_mbus_fmt, code-index,
pixcode);
if (!ret)
code-code= pixcode;
}
return ret;
}
Similarly for other ops.
Thanks
Guennadi
On Thu, 29 Jan 2015, William Towle wrote:
Add 'struct media_pad pad' member and suitable glue code, so that
soc_camera/rcar_vin can become agnostic to whether an old or new-
style driver (wrt pad API use) can sit underneath
This version has been reworked to include appropriate constant and
datatype names for kernel v3.18
---
drivers/media/platform/soc_camera/soc_camera.c | 148
+++-
drivers/media/platform/soc_camera/soc_scale_crop.c | 43 +-
include/media/soc_camera.h |1 +
3 files changed, 182 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c index f4be2a1..efc20bf
100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -37,8 +37,11 @@
#include media/v4l2-ioctl.h
#include media/v4l2-dev.h
#include media/v4l2-of.h
+#if 0
#include media/videobuf-core.h
#include media/videobuf2-core.h
+#endif
No. These headers are needed even if the code can be compiled without
them.
+#include media/v4l2-mediabus.h
Well, maybe. This header is included indirectly via soc_mediabus.h, but
yes, as I just said above, headers, whose defines, structs etc. are used,
should be encluded directly. Further, you'll need more headers, e.g.
media-entity.h, maybe some more.
/* Default to VGA resolution */
#define DEFAULT_WIDTH640
@@ -453,6 +456,98 @@ static int soc_camera_expbuf(struct file *file,
void *priv,
return vb2_expbuf(icd-vb2_vidq, p);
}
+static int soc_camera_init_user_formats_pad(struct soc_camera_device
*icd, int src_pad_idx) +{
+ struct v4l2_subdev *sd= soc_camera_to_subdev(icd);
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct v4l2_subdev_mbus_code_enum code;
+ int fmts= 0, raw_fmts, i, ret;
Please, run this patch through checkpatch.pl. It will tell you to add a
Signed-off-by line, (hopefully) to add spaces before = in multiple
places, to place braces correctly, to not use C++-style comments etc. Only
feel free to ignore 80-character warnings.
+
+ code.pad= src_pad_idx;
+ code.index= 0;
+
+ // subdev_has_op - enum_mbus_code vs enum_mbus_fmt
+ if (v4l2_subdev_has_op(sd, pad, enum_mbus_code)) {
This function is called only once below and only after the above test has
already returned success. Looks like you don't need it here again and the
below else branch can be dropped completely?
+ while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, code))
+ code.index++;
+ } else {
+ u32 pixcode;
+
+ while (!v4l2_subdev_call(sd, video, enum_mbus_fmt, code.index,
pixcode)) + {
+ code.code= pixcode;
+ code.index++;
+ }
+ }
+ raw_fmts= code.index;
+
+ if (!ici-ops-get_formats) {
+ /*
+ * Fallback mode - the host will have to serve all
+ *
Re: [PATCH v6] media: au0828 - convert to use videobuf2
On Thu, Jan 29, 2015 at 4:41 PM, Shuah Khan shua...@osg.samsung.com wrote: Convert au0828 to use videobuf2. Tested with NTSC. Tested video and vbi devices with xawtv, tvtime, and vlc. Ran v4l2-compliance to ensure there are no failures. Video compliance test results summary: Total: 75, Succeeded: 75, Failed: 0, Warnings: 18 Vbi compliance test results summary: Total: 75, Succeeded: 75, Failed: 0, Warnings: 0 Signed-off-by: Shuah Khan shua...@osg.samsung.com Reviewed-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regards, --Prabhakar Lad -- 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 6/8] WmT: adv7604 driver compatibility
On 02/02/2015 11:01 AM, Laurent Pinchart wrote: Hi Guennadi, On Sunday 01 February 2015 12:26:11 Guennadi Liakhovetski wrote: On a second thought: On Sun, 1 Feb 2015, Guennadi Liakhovetski wrote: Hi Wills, Thanks for the patch. First and foremost, the title of the patch is wrong. This patch does more than just adding some adv7604 compatibility. It's adding pad-level API to soc-camera. This is just a rough review. I'm not an expert in media-controller / pad-level API, I hope someone with a better knowledge of those areas will help me reviewing this. Another general comment: it has been discussed since a long time, whether a wrapper wouldn't be desired to enable a seamless use of both subdev drivers using and not using the pad-level API. Maybe it's the right time now?.. This would be a considerable change and would most probably take a rather long time, given how busy everyone is. If I understood correctly Hans Verkuil told me over the weekend that he wanted to address this problem in the near future. Hans, could you detail your plans ? That's correct. This patch series makes all the necessary changes. https://www.mail-archive.com/linux-media@vger.kernel.org/msg83415.html Patches 1-4 have been merged already, but I need to do more testing for the remainder. The Renesas SH7724 board is ideal for that, but unfortunately I can't get it to work with the current kernel. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: adv7604: CP CSC uses a different register on adv7604 and adv7611
Hi Jean-Michel, On 01/26/2015 02:52 PM, Jean-Michel Hautbois wrote: The bits are the same, but register is 0xf4 on ADV7611 instead of 0xfc. When reading back the value in log_status, differentiate both. Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com --- drivers/media/i2c/adv7604.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index e43dd2e..32e53e0 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2310,8 +2310,12 @@ static int adv7604_log_status(struct v4l2_subdev *sd) (reg_io_0x02 0x04) ? (16-235) : (0-255), ((reg_io_0x02 0x04) ^ (reg_io_0x02 0x01)) ? enabled : disabled); - v4l2_info(sd, Color space conversion: %s\n, + if (state-info-type == ADV7604) + v4l2_info(sd, Color space conversion: %s\n, csc_coeff_sel_rb[cp_read(sd, 0xfc) 4]); + else + v4l2_info(sd, Color space conversion: %s\n, + csc_coeff_sel_rb[cp_read(sd, 0xf4) 4]); if (!is_digital_input(sd)) return 0; You need to add this register to the adv7604_chip_info struct, just like is done for other registers that have this issue. Regards, Hans -- 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 v3 1/2] V4L: remove clock name from v4l2_clk API
Hi, Guennadi
On 2/1/2015 7:21 AM, Guennadi Liakhovetski wrote:
All uses of the v4l2_clk API so far only register one clock with a fixed
name. This allows us to get rid of it, which also will make CCF and DT
integration easier.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Thanks for the patch.
Tested-by: Josh Wu josh...@atmel.com
Best Regards,
Josh Wu
v3: .id field removed from the struct. Since CCF clocks won't be added to
the V4L2 clock list at all in patch 2 in this series, no clock ID
comparison is needed in v4l2_clk_find() either.
drivers/media/platform/soc_camera/soc_camera.c | 6 ++---
drivers/media/usb/em28xx/em28xx-camera.c | 2 +-
drivers/media/v4l2-core/v4l2-clk.c | 33 ++
include/media/v4l2-clk.h | 8 +++
4 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..ce192b6 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1380,7 +1380,7 @@ static int soc_camera_i2c_init(struct soc_camera_device
*icd,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
shd-i2c_adapter_id, shd-board_info-addr);
- icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk, icd);
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1561,7 +1561,7 @@ static int scan_async_group(struct soc_camera_host *ici,
snprintf(clk_name, sizeof(clk_name), %d-%04x,
sasd-asd.match.i2c.adapter_id, sasd-asd.match.i2c.address);
- icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk, icd);
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
@@ -1666,7 +1666,7 @@ static int soc_of_bind(struct soc_camera_host *ici,
snprintf(clk_name, sizeof(clk_name), of-%s,
of_node_full_name(remote));
- icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk, icd);
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, icd);
if (IS_ERR(icd-clk)) {
ret = PTR_ERR(icd-clk);
goto eclkreg;
diff --git a/drivers/media/usb/em28xx/em28xx-camera.c
b/drivers/media/usb/em28xx/em28xx-camera.c
index 7be661f..a4b22c2 100644
--- a/drivers/media/usb/em28xx/em28xx-camera.c
+++ b/drivers/media/usb/em28xx/em28xx-camera.c
@@ -330,7 +330,7 @@ int em28xx_init_camera(struct em28xx *dev)
v4l2_clk_name_i2c(clk_name, sizeof(clk_name),
i2c_adapter_id(adap), client-addr);
- v4l2-clk = v4l2_clk_register_fixed(clk_name, mclk, -EINVAL);
+ v4l2-clk = v4l2_clk_register_fixed(clk_name, -EINVAL);
if (IS_ERR(v4l2-clk))
return PTR_ERR(v4l2-clk);
diff --git a/drivers/media/v4l2-core/v4l2-clk.c b/drivers/media/v4l2-core/v4l2-clk.c
index e18cc04..3ff0b00 100644
--- a/drivers/media/v4l2-core/v4l2-clk.c
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -23,17 +23,13 @@
static DEFINE_MUTEX(clk_lock);
static LIST_HEAD(clk_list);
-static struct v4l2_clk *v4l2_clk_find(const char *dev_id, const char *id)
+static struct v4l2_clk *v4l2_clk_find(const char *dev_id)
{
struct v4l2_clk *clk;
- list_for_each_entry(clk, clk_list, list) {
- if (strcmp(dev_id, clk-dev_id))
- continue;
-
- if (!id || !clk-id || !strcmp(clk-id, id))
+ list_for_each_entry(clk, clk_list, list)
+ if (!strcmp(dev_id, clk-dev_id))
return clk;
- }
return ERR_PTR(-ENODEV);
}
@@ -43,7 +39,7 @@ struct v4l2_clk *v4l2_clk_get(struct device *dev, const char
*id)
struct v4l2_clk *clk;
mutex_lock(clk_lock);
- clk = v4l2_clk_find(dev_name(dev), id);
+ clk = v4l2_clk_find(dev_name(dev));
if (!IS_ERR(clk))
atomic_inc(clk-use_count);
@@ -127,8 +123,8 @@ void v4l2_clk_disable(struct v4l2_clk *clk)
mutex_lock(clk-lock);
enable = --clk-enable;
- if (WARN(enable 0, Unbalanced %s() on %s:%s!\n, __func__,
-clk-dev_id, clk-id))
+ if (WARN(enable 0, Unbalanced %s() on %s!\n, __func__,
+clk-dev_id))
clk-enable++;
else if (!enable clk-ops-disable)
clk-ops-disable(clk);
@@ -181,7 +177,7 @@ EXPORT_SYMBOL(v4l2_clk_set_rate);
struct v4l2_clk *v4l2_clk_register(const struct v4l2_clk_ops *ops,
const char *dev_id,
- const char *id, void *priv)
+ void *priv)
{
struct v4l2_clk *clk;
int ret;
@@ -193,9
[PATCH 3/5] [media] lnbh25: LNBH25 SEC controller driver
DVB SEC frontend driver for STM LNBH25PQR chip.
Signed-off-by: Kozlov Sergey se...@netup.ru
---
MAINTAINERS |9 ++
drivers/media/dvb-frontends/Kconfig |8 ++
drivers/media/dvb-frontends/Makefile |1 +
drivers/media/dvb-frontends/lnbh25.c | 182 ++
drivers/media/dvb-frontends/lnbh25.h | 56 +++
5 files changed, 256 insertions(+)
create mode 100644 drivers/media/dvb-frontends/lnbh25.c
create mode 100644 drivers/media/dvb-frontends/lnbh25.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a022d6d..8a687dc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5853,6 +5853,15 @@ Q:
http://patchwork.linuxtv.org/project/linux-media/list/
S: Maintained
F: drivers/media/usb/dvb-usb-v2/lmedm04*
+LNBH25 MEDIA DRIVER
+M: Sergey Kozlov se...@netup.ru
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+W: http://netup.tv/
+T: git git://linuxtv.org/media_tree.git
+S: Supported
+F: drivers/media/dvb-frontends/lnbh25*
+
LOCKDEP AND LOCKSTAT
M: Peter Zijlstra pet...@infradead.org
M: Ingo Molnar mi...@redhat.com
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index c94bb7b..b3b216d 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -693,6 +693,14 @@ comment SEC control devices for DVB-S
source drivers/media/dvb-frontends/drx39xyj/Kconfig
+config DVB_LNBH25
+ tristate LNBH25 SEC controller
+ depends on DVB_CORE I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ An SEC control chip.
+ Say Y when you want to support this chip.
+
config DVB_LNBP21
tristate LNBP21/LNBH24 SEC controllers
depends on DVB_CORE I2C
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index 0b19c10..06a0d21 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_DVB_LGDT330X) += lgdt330x.o
obj-$(CONFIG_DVB_LGDT3305) += lgdt3305.o
obj-$(CONFIG_DVB_LG2160) += lg2160.o
obj-$(CONFIG_DVB_CX24123) += cx24123.o
+obj-$(CONFIG_DVB_LNBH25) += lnbh25.o
obj-$(CONFIG_DVB_LNBP21) += lnbp21.o
obj-$(CONFIG_DVB_LNBP22) += lnbp22.o
obj-$(CONFIG_DVB_ISL6405) += isl6405.o
diff --git a/drivers/media/dvb-frontends/lnbh25.c
b/drivers/media/dvb-frontends/lnbh25.c
new file mode 100644
index 000..fcefc66
--- /dev/null
+++ b/drivers/media/dvb-frontends/lnbh25.c
@@ -0,0 +1,182 @@
+/*
+ * lnbh25.c
+ *
+ * Driver for LNB supply and control IC LNBH25
+ *
+ * Copyright (C) 2014 NetUP Inc.
+ * Copyright (C) 2014 Sergey Kozlov se...@netup.ru
+ * Copyright (C) 2014 Abylay Ospan aos...@netup.ru
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/string.h
+#include linux/slab.h
+
+#include dvb_frontend.h
+#include lnbh25.h
+
+static int debug;
+
+#define dprintk(args...) \
+ do { \
+ if (debug) \
+ dev_dbg(priv-i2c-dev, args); \
+ } while (0)
+
+struct lnbh25_priv {
+ struct i2c_adapter *i2c;
+ u8 i2c_address;
+ /*
+* LNBH25 configuration:
+* offset 0: first LNBH25 register address: always 0x02 (DATA1)
+* offset 1: DATA1 register value
+* offset 2: DATA2 register value
+*/
+ u8 config[3];
+};
+
+#define LNBH25_STATUS_OFL 0x1
+#define LNBH25_STATUS_VMON 0x4
+#define LNBH25_VSEL_13 0x03
+#define LNBH25_VSEL_18 0x0a
+
+static void lnbh25_read_vmon(struct lnbh25_priv *priv)
+{
+ int i;
+ u8 addr = 0x00;
+ u8 status[6];
+ struct i2c_msg msg[2] = {
+ {
+ .addr = priv-i2c_address,
+ .flags = 0,
+ .len = 1,
+ .buf = addr
+ }, {
+ .addr = priv-i2c_address,
+ .flags = I2C_M_RD,
+ .len = sizeof(status),
+ .buf = status
+ }
+ };
+
+ msleep(100);
+ for (i = 0; i 2; i++) {
+ if (i2c_transfer(priv-i2c, msg[i], 1) != 1) {
+ dprintk(%s(): I2C transfer %d failed\n,
+ __func__, i);
+ return;
+ }
+ }
+ for (i = 0; i sizeof(status); i++)
+
[PATCH 2/5] [media] ascot2e: Sony Ascot2e DVB-C/T/T2 tuner driver
DVB-T/T2/C frontend driver for Sony Ascot2e (CXD2861ER) chip.
Signed-off-by: Kozlov Sergey se...@netup.ru
---
MAINTAINERS |9 +
drivers/media/dvb-frontends/Kconfig |7 +
drivers/media/dvb-frontends/Makefile |1 +
drivers/media/dvb-frontends/ascot2e.c | 551 +
drivers/media/dvb-frontends/ascot2e.h | 53
5 files changed, 621 insertions(+)
create mode 100644 drivers/media/dvb-frontends/ascot2e.c
create mode 100644 drivers/media/dvb-frontends/ascot2e.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a3a1767..a022d6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1613,6 +1613,15 @@ S: Maintained
F: Documentation/hwmon/asc7621
F: drivers/hwmon/asc7621.c
+ASCOT2E MEDIA DRIVER
+M: Sergey Kozlov se...@netup.ru
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org
+W: http://netup.tv/
+T: git git://linuxtv.org/media_tree.git
+S: Supported
+F: drivers/media/dvb-frontends/ascot2e*
+
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
M: Corentin Chary corentin.ch...@gmail.com
L: acpi4asus-u...@lists.sourceforge.net
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index c2c157b..c94bb7b 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -803,6 +803,13 @@ config DVB_HORUS3A
help
Say Y when you want to support this frontend.
+config DVB_ASCOT2E
+ tristate Sony Ascot2E tuner
+ depends on DVB_CORE I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Say Y when you want to support this frontend.
+
comment Tools to develop new frontends
config DVB_DUMMY_FE
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index 3aa05f3..0b19c10 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -117,3 +117,4 @@ obj-$(CONFIG_DVB_AF9033) += af9033.o
obj-$(CONFIG_DVB_AS102_FE) += as102_fe.o
obj-$(CONFIG_DVB_TC90522) += tc90522.o
obj-$(CONFIG_DVB_HORUS3A) += horus3a.o
+obj-$(CONFIG_DVB_ASCOT2E) += ascot2e.o
diff --git a/drivers/media/dvb-frontends/ascot2e.c
b/drivers/media/dvb-frontends/ascot2e.c
new file mode 100644
index 000..d0bde8ea
--- /dev/null
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -0,0 +1,551 @@
+/*
+ * ascot2e.c
+ *
+ * Sony Ascot3E DVB-T/T2/C/C2 tuner driver
+ *
+ * Copyright 2012 Sony Corporation
+ * Copyright (C) 2014 NetUP Inc.
+ * Copyright (C) 2014 Sergey Kozlov se...@netup.ru
+ * Copyright (C) 2014 Abylay Ospan aos...@netup.ru
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/slab.h
+#include linux/module.h
+#include linux/dvb/frontend.h
+#include linux/types.h
+#include ascot2e.h
+#include dvb_frontend.h
+
+static int debug;
+module_param(debug, int, 0644);
+
+#define dprintk(args...) \
+ do { \
+ if (debug) \
+ printk(args); \
+ } while (0)
+
+enum ascot2e_state {
+ STATE_UNKNOWN,
+ STATE_SLEEP,
+ STATE_ACTIVE
+};
+
+struct ascot2e_priv {
+ u32 frequency;
+ u8 i2c_address;
+ struct i2c_adapter *i2c;
+ enum ascot2e_state state;
+ void*set_tuner_data;
+ int (*set_tuner)(void *, int);
+};
+
+enum ascot2e_tv_system_t {
+ ASCOT2E_DTV_DVBT_5,
+ ASCOT2E_DTV_DVBT_6,
+ ASCOT2E_DTV_DVBT_7,
+ ASCOT2E_DTV_DVBT_8,
+ ASCOT2E_DTV_DVBT2_1_7,
+ ASCOT2E_DTV_DVBT2_5,
+ ASCOT2E_DTV_DVBT2_6,
+ ASCOT2E_DTV_DVBT2_7,
+ ASCOT2E_DTV_DVBT2_8,
+ ASCOT2E_DTV_DVBC_6,
+ ASCOT2E_DTV_DVBC_8,
+ ASCOT2E_DTV_DVBC2_6,
+ ASCOT2E_DTV_DVBC2_8,
+ ASCOT2E_DTV_UNKNOWN
+};
+
+struct ascot2e_band_sett {
+ u8 if_out_sel;
+ u8 agc_sel;
+ u8 mix_oll;
+ u8 rf_gain;
+ u8 if_bpf_gc;
+ u8 fif_offset;
+ u8 bw_offset;
+ u8 bw;
+ u8 rf_oldet;
+ u8 if_bpf_f0;
+};
+
+#define ASCOT2E_AUTO 0xff
+#define ASCOT2E_OFFSET(ofs)((u8)(ofs) 0x1F)
+#define ASCOT2E_BW_6 0x00
+#define ASCOT2E_BW_7 0x01
+#define ASCOT2E_BW_8 0x02
+#define ASCOT2E_BW_1_7 0x03
+
+static struct ascot2e_band_sett ascot2e_sett[] = {
+ { ASCOT2E_AUTO, ASCOT2E_AUTO, 0x03, ASCOT2E_AUTO, 0x06,
+ ASCOT2E_OFFSET(-8),
[PATCH 0/5] [media] NetUP Universal DVB PCIe card support
This patch adds support for NetUP Universal Dual DVB-CI PCIe board. The board has: - two CI slots - Altera FPGA-based PCIe bridge - two independent multistandard DTV demodulators based on Sony CXD2841ER chip - two Sony Horus3a DVB-S/S2 tuner chips - two Sony Ascot2e DVB-T/T2/C/C2 tuner chips - two LNBH25 SEC controller chips DVB-C2 is supported by hardware but not yet implemented in the driver. Product webpages are http://www.netup.tv/en-EN/netup-universal-dual-dvb-ci (official) http://linuxtv.org/wiki/index.php/NetUP_Dual_Universal_CI (LinuxTV WIKI) Also we have a copy of http://git.linuxtv.org/cgit.cgi/linux.git/ repository with our patches at http://git.netup.tv/linux-netup-unidvb.git Kozlov Sergey (5): [media] horus3a: Sony Horus3A DVB-S/S2 tuner driver [media] ascot2e: Sony Ascot2e DVB-C/T/T2 tuner driver [media] lnbh25: LNBH25 SEC controller driver [media] cxd2841er: Sony CXD2841ER DVB-S/S2/T/T2/C demodulator driver [media] netup_unidvb: NetUP Universal DVB-S/S2/T/T2/C PCI-E card driver MAINTAINERS | 45 + drivers/media/dvb-frontends/Kconfig | 29 + drivers/media/dvb-frontends/Makefile |4 + drivers/media/dvb-frontends/ascot2e.c| 551 + drivers/media/dvb-frontends/ascot2e.h| 53 + drivers/media/dvb-frontends/cxd2841er.c | 2778 ++ drivers/media/dvb-frontends/cxd2841er.h | 64 + drivers/media/dvb-frontends/cxd2841er_priv.h | 44 + drivers/media/dvb-frontends/horus3a.c| 429 drivers/media/dvb-frontends/horus3a.h| 53 + drivers/media/dvb-frontends/lnbh25.c | 182 ++ drivers/media/dvb-frontends/lnbh25.h | 56 + drivers/media/pci/Kconfig|1 + drivers/media/pci/Makefile |3 +- drivers/media/pci/netup/Kconfig | 12 + drivers/media/pci/netup/Makefile |9 + drivers/media/pci/netup/netup_unidvb.h | 232 +++ drivers/media/pci/netup/netup_unidvb_ci.c| 248 +++ drivers/media/pci/netup/netup_unidvb_core.c | 919 + drivers/media/pci/netup/netup_unidvb_i2c.c | 350 drivers/media/pci/netup/netup_unidvb_spi.c | 272 +++ 21 files changed, 6333 insertions(+), 1 deletion(-) create mode 100644 drivers/media/dvb-frontends/ascot2e.c create mode 100644 drivers/media/dvb-frontends/ascot2e.h create mode 100644 drivers/media/dvb-frontends/cxd2841er.c create mode 100644 drivers/media/dvb-frontends/cxd2841er.h create mode 100644 drivers/media/dvb-frontends/cxd2841er_priv.h create mode 100644 drivers/media/dvb-frontends/horus3a.c create mode 100644 drivers/media/dvb-frontends/horus3a.h create mode 100644 drivers/media/dvb-frontends/lnbh25.c create mode 100644 drivers/media/dvb-frontends/lnbh25.h create mode 100644 drivers/media/pci/netup/Kconfig create mode 100644 drivers/media/pci/netup/Makefile create mode 100644 drivers/media/pci/netup/netup_unidvb.h create mode 100644 drivers/media/pci/netup/netup_unidvb_ci.c create mode 100644 drivers/media/pci/netup/netup_unidvb_core.c create mode 100644 drivers/media/pci/netup/netup_unidvb_i2c.c create mode 100644 drivers/media/pci/netup/netup_unidvb_spi.c -- 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] media: atmel-isi: increase the burst length to improve the performance
Hi Josh, On Mon, 2 Feb 2015, Josh Wu wrote: Hi, Guennadi Ping? what about the status of this patch? Right, got lost, sorry... Added to the queue now. Thanks Guennadi Best Regards, Josh Wu On 11/25/2014 5:30 PM, Josh Wu wrote: The burst length could be BEATS_4/8/16. Before this patch, isi use default value BEATS_4. To imporve the performance we could set it to BEATS_16. Otherwise sometime it would cause the ISI overflow error. Reported-by: Bo Shen voice.s...@atmel.com Signed-off-by: Josh Wu josh...@atmel.com --- drivers/media/platform/soc_camera/atmel-isi.c | 2 ++ include/media/atmel-isi.h | 4 2 files changed, 6 insertions(+) diff --git a/drivers/media/platform/soc_camera/atmel-isi.c b/drivers/media/platform/soc_camera/atmel-isi.c index ee5650f..fda587b 100644 --- a/drivers/media/platform/soc_camera/atmel-isi.c +++ b/drivers/media/platform/soc_camera/atmel-isi.c @@ -839,6 +839,8 @@ static int isi_camera_set_bus_param(struct soc_camera_device *icd) if (isi-pdata.full_mode) cfg1 |= ISI_CFG1_FULL_MODE; + cfg1 |= ISI_CFG1_THMASK_BEATS_16; + isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS); isi_writel(isi, ISI_CFG1, cfg1); diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h index c2e5703..6008b09 100644 --- a/include/media/atmel-isi.h +++ b/include/media/atmel-isi.h @@ -59,6 +59,10 @@ #define ISI_CFG1_FRATE_DIV_MASK (7 8) #define ISI_CFG1_DISCR(1 11) #define ISI_CFG1_FULL_MODE(1 12) +/* Definition for THMASK(ISI_V2) */ +#defineISI_CFG1_THMASK_BEATS_4 (0 13) +#defineISI_CFG1_THMASK_BEATS_8 (1 13) +#defineISI_CFG1_THMASK_BEATS_16(2 13) /* Bitfields in CFG2 */ #define ISI_CFG2_GRAYSCALE(1 13) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/15] media: blackfin: bfin_capture enhancements
On 01/30/2015 04:49 PM, Lad, Prabhakar wrote: Hello Scott, On Thu, Jan 22, 2015 at 10:18 PM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: This patch series, enhances blackfin capture driver with vb2 helpers. Changes for v2: -- Only patches 5/15 and 8/15 as per Scott's suggestions. Lad, Prabhakar (15): media: blackfin: bfin_capture: drop buf_init() callback media: blackfin: bfin_capture: release buffers in case start_streaming() call back fails media: blackfin: bfin_capture: set min_buffers_needed media: blackfin: bfin_capture: improve buf_prepare() callback media: blackfin: bfin_capture: improve queue_setup() callback media: blackfin: bfin_capture: use vb2_fop_mmap/poll media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release media: blackfin: bfin_capture: use vb2_ioctl_* helpers media: blackfin: bfin_capture: make sure all buffers are returned on stop_streaming() callback media: blackfin: bfin_capture: return -ENODATA for *std calls media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls media: blackfin: bfin_capture: add support for vidioc_create_bufs media: blackfin: bfin_capture: add support for VB2_DMABUF media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF media: blackfin: bfin_capture: set v4l2 buffer sequence drivers/media/platform/blackfin/bfin_capture.c | 311 - 1 file changed, 99 insertions(+), 212 deletions(-) Can you ACK the series ? so that its easier for Hans to pick it up. ping! Scott, I can't take it unless you Ack it. Actually, I'd like to see a 'Tested-by' tag. And if you are testing anyway, then I would really like to see the output of 'v4l2-compliance -s', using the v4l2-compliance from the latest v4l-utils.git. I'm curious to see the results of that. Regards, Hans Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: atmel-isi: increase the burst length to improve the performance
Hi, Guennadi On 2/2/2015 6:22 PM, Guennadi Liakhovetski wrote: Hi Josh, On Mon, 2 Feb 2015, Josh Wu wrote: Hi, Guennadi Ping? what about the status of this patch? Right, got lost, sorry... Added to the queue now. Thank you. Best Regards, Josh Wu Thanks Guennadi Best Regards, Josh Wu On 11/25/2014 5:30 PM, Josh Wu wrote: The burst length could be BEATS_4/8/16. Before this patch, isi use default value BEATS_4. To imporve the performance we could set it to BEATS_16. Otherwise sometime it would cause the ISI overflow error. Reported-by: Bo Shen voice.s...@atmel.com Signed-off-by: Josh Wu josh...@atmel.com --- drivers/media/platform/soc_camera/atmel-isi.c | 2 ++ include/media/atmel-isi.h | 4 2 files changed, 6 insertions(+) diff --git a/drivers/media/platform/soc_camera/atmel-isi.c b/drivers/media/platform/soc_camera/atmel-isi.c index ee5650f..fda587b 100644 --- a/drivers/media/platform/soc_camera/atmel-isi.c +++ b/drivers/media/platform/soc_camera/atmel-isi.c @@ -839,6 +839,8 @@ static int isi_camera_set_bus_param(struct soc_camera_device *icd) if (isi-pdata.full_mode) cfg1 |= ISI_CFG1_FULL_MODE; +cfg1 |= ISI_CFG1_THMASK_BEATS_16; + isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS); isi_writel(isi, ISI_CFG1, cfg1); diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h index c2e5703..6008b09 100644 --- a/include/media/atmel-isi.h +++ b/include/media/atmel-isi.h @@ -59,6 +59,10 @@ #define ISI_CFG1_FRATE_DIV_MASK (7 8) #define ISI_CFG1_DISCR (1 11) #define ISI_CFG1_FULL_MODE (1 12) +/* Definition for THMASK(ISI_V2) */ +#defineISI_CFG1_THMASK_BEATS_4 (0 13) +#defineISI_CFG1_THMASK_BEATS_8 (1 13) +#defineISI_CFG1_THMASK_BEATS_16(2 13) /* Bitfields in CFG2 */ #define ISI_CFG2_GRAYSCALE (1 13) -- 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: OK
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: Tue Feb 3 04:00:15 CET 2015 git branch: test git hash: ab98180ac2e6e41058f8829c0961aa306c610c16 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: 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-i686: OK linux-3.17.8-i686: OK linux-3.18-i686: OK linux-3.19-rc4-i686: OK 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-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18-x86_64: OK linux-3.19-rc4-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
Antti/Mark, Any news with regards to this? Regards, Mauro Em Mon, 22 Dec 2014 15:05:15 + Mark Brown broo...@kernel.org escreveu: On Mon, Dec 22, 2014 at 03:53:10PM +0200, Antti Palosaari wrote: On 12/22/2014 03:31 PM, Mark Brown wrote: Why is this configurable, how would a device know if the system it is in needs a custom locking class and can safely use one? If RegMap instance is bus master, eg. I2C adapter, then you should define own custom key. If you don't define own key and there will be slave on that bus which uses RegMap too, there will be recursive locking from a lockdep point of view. That doesn't really explain to me why this is configurable, why should drivers have to worry about this? Did you read the lockdep documentation I pointed previous mail? No, quite apart from the fact that you pasted a good chunk of it into your mail I don't think it's a good idea to require people to have to reverse engineer everything to figure out if they're supposed to use this, or expect people reviewing code using this feature to do that in order to figure out if it's being used correctly or not. Suggesting that I'm not thinking hard enough isn't helping here; this stuff needs to be clear and easy so that people naturally get it right when they need to and don't break things as a result of confusion or error, requiring people to directly work with infrequently used things like lock classes with minimal explanation doesn't achieve that goal. One possibility is to disable lockdep checking from that driver totally, then drivers do not need to care it about. But I don't think it is proper way. One solution is to use custom regmap locking available already, but Mauro nor me didn't like that hack: You don't seem to be answering any of my questions here... for example, you keep saying that this is something bus masters should do. Why does it make sense for people writing such drivers to have to figure out that they need to do this and how to do it? Are there some bus masters that shouldn't be doing so? Should anything that isn't a bus master have to do it? Please also write technical terms like regmap normally. Lower-case letters? Yes, the way it's written in every place it's used in the kernel except a few I see you've added. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] Add BGR888_1X24 and GBR888_1X24 media bus formats
Am Montag, den 02.02.2015, 13:24 -0200 schrieb Mauro Carvalho Chehab: Em Mon, 02 Feb 2015 16:21:00 +0100 Philipp Zabel p.za...@pengutronix.de escreveu: Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil: On 12/03/2014 02:53 PM, Philipp Zabel wrote: This patch adds two more 24-bit RGB formats. BGR888 is more or less common, GBR888 is used on the internal connection between the IPU display interface and the TVE (VGA DAC) on i.MX53 SoCs. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This three-part patch series doesn't apply. Is it on top of another patch series? It is on top of Add RGB444_1X12 and RGB565_1X16 media bus formats and Add LVDS RGB media bus formats. Anyway, it can't be merged unless it is actually used in a driver. I'd like to use these in the imx-drm driver, so this is kind of a chicken and egg situation. Shall I submit a patch that uses the defines to dri-devel and reference it here? Submit the full patch series with the imx-drm driver, mentioning at the V4L2 patch that it will be applied via the DRM tree. We'll review and give our ack for it to be applied via DRM tree. I'll do that, thanks. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Em Mon, 02 Feb 2015 16:32:07 +0100 Boris Brezillon boris.brezil...@free-electrons.com escreveu: Hi Mauro, On Mon, 02 Feb 2015 12:57:55 -0200 Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Tue, 6 Jan 2015 12:43:35 +0100 Boris Brezillon boris.brezil...@free-electrons.com escreveu: Add RGB444_1X12 and RGB565_1X16 format definitions and update the documentation. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Sakari Ailus sakari.ai...@linux.intel.com --- Hi Mauro, Sakari, This patch has been rejected as 'Not Applicable'. Is there anyting wrong in it ? I was expecting that this patch would be merged together with the remaining series, via the DRM tree. That's basically why I gave my ack: https://lkml.org/lkml/2014/11/3/661 HINT: when a subsystem maintainer gives an ack, that likely means that he expects that the patch will be applied via some other tree. My bad, I thought this would go into the media tree since this single patch is not exactly related to a DRM feature (except the fact that I was planning to use it in my DRM driver). Actually, I didn't send it to the DRM maintainer or dri-devel ML in the first place :-(. Can you reconsider taking it in the media tree ? I you can't, I'll ask Dave (just added him in Cc) to take it into the DRM tree. I really prefer if you submit this together with the DRM series. We don't apply API changes at media, except if the API change is needed by some driver that it is also submitted in the same series. I don't mind applying it via media, but in this case, I'll apply together with the remaining DRM drivers, and will require DRM maintainer's ack. So, it is probably easier to just apply this change via the DRM subtree than the reverse. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Em Tue, 6 Jan 2015 12:43:35 +0100 Boris Brezillon boris.brezil...@free-electrons.com escreveu: Add RGB444_1X12 and RGB565_1X16 format definitions and update the documentation. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Sakari Ailus sakari.ai...@linux.intel.com --- Hi Mauro, Sakari, This patch has been rejected as 'Not Applicable'. Is there anyting wrong in it ? I was expecting that this patch would be merged together with the remaining series, via the DRM tree. That's basically why I gave my ack: https://lkml.org/lkml/2014/11/3/661 HINT: when a subsystem maintainer gives an ack, that likely means that he expects that the patch will be applied via some other tree. Regards, Mauro Best Regards, Boris Documentation/DocBook/media/v4l/subdev-formats.xml | 40 ++ include/uapi/linux/media-bus-format.h | 4 ++- 2 files changed, 43 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index c5ea868..be57efa 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -192,6 +192,24 @@ see xref linkend=colorspaces /./entry /row /thead tbody valign=top + row id=MEDIA-BUS-FMT-RGB444-1X12 + entryMEDIA_BUS_FMT_RGB444_1X12/entry + entry0x100d/entry + entry/entry + dash-ent-20; + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row row id=MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE entryMEDIA_BUS_FMT_RGB444_2X8_PADHI_BE/entry entry0x1001/entry @@ -304,6 +322,28 @@ see xref linkend=colorspaces /./entry entrygsubscript4/subscript/entry entrygsubscript3/subscript/entry /row + row id=MEDIA-BUS-FMT-RGB565-1X16 + entryMEDIA_BUS_FMT_RGB565_1X16/entry + entry0x100d/entry + entry/entry + dash-ent-16; + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row row id=MEDIA-BUS-FMT-BGR565-2X8-BE entryMEDIA_BUS_FMT_BGR565_2X8_BE/entry entry0x1005/entry diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 23b4090..37091c6 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -33,11 +33,13 @@ #define MEDIA_BUS_FMT_FIXED 0x0001 -/* RGB - next is 0x100e */ +/* RGB - next is 0x1010 */ +#define MEDIA_BUS_FMT_RGB444_1X120x100e #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE0x1003 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE0x1004 +#define MEDIA_BUS_FMT_RGB565_1X160x100f #define MEDIA_BUS_FMT_BGR565_2X8_BE 0x1005 #define MEDIA_BUS_FMT_BGR565_2X8_LE 0x1006 #define MEDIA_BUS_FMT_RGB565_2X8_BE 0x1007 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] Add BGR888_1X24 and GBR888_1X24 media bus formats
Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil: On 12/03/2014 02:53 PM, Philipp Zabel wrote: This patch adds two more 24-bit RGB formats. BGR888 is more or less common, GBR888 is used on the internal connection between the IPU display interface and the TVE (VGA DAC) on i.MX53 SoCs. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This three-part patch series doesn't apply. Is it on top of another patch series? It is on top of Add RGB444_1X12 and RGB565_1X16 media bus formats and Add LVDS RGB media bus formats. Anyway, it can't be merged unless it is actually used in a driver. I'd like to use these in the imx-drm driver, so this is kind of a chicken and egg situation. Shall I submit a patch that uses the defines to dri-devel and reference it here? regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] Add BGR888_1X24 and GBR888_1X24 media bus formats
Em Mon, 02 Feb 2015 16:21:00 +0100 Philipp Zabel p.za...@pengutronix.de escreveu: Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil: On 12/03/2014 02:53 PM, Philipp Zabel wrote: This patch adds two more 24-bit RGB formats. BGR888 is more or less common, GBR888 is used on the internal connection between the IPU display interface and the TVE (VGA DAC) on i.MX53 SoCs. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This three-part patch series doesn't apply. Is it on top of another patch series? It is on top of Add RGB444_1X12 and RGB565_1X16 media bus formats and Add LVDS RGB media bus formats. Anyway, it can't be merged unless it is actually used in a driver. I'd like to use these in the imx-drm driver, so this is kind of a chicken and egg situation. Shall I submit a patch that uses the defines to dri-devel and reference it here? Submit the full patch series with the imx-drm driver, mentioning at the V4L2 patch that it will be applied via the DRM tree. We'll review and give our ack for it to be applied via DRM tree. Regards, Mauro regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Hi Mauro, On Mon, 02 Feb 2015 12:57:55 -0200 Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Tue, 6 Jan 2015 12:43:35 +0100 Boris Brezillon boris.brezil...@free-electrons.com escreveu: Add RGB444_1X12 and RGB565_1X16 format definitions and update the documentation. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Sakari Ailus sakari.ai...@linux.intel.com --- Hi Mauro, Sakari, This patch has been rejected as 'Not Applicable'. Is there anyting wrong in it ? I was expecting that this patch would be merged together with the remaining series, via the DRM tree. That's basically why I gave my ack: https://lkml.org/lkml/2014/11/3/661 HINT: when a subsystem maintainer gives an ack, that likely means that he expects that the patch will be applied via some other tree. My bad, I thought this would go into the media tree since this single patch is not exactly related to a DRM feature (except the fact that I was planning to use it in my DRM driver). Actually, I didn't send it to the DRM maintainer or dri-devel ML in the first place :-(. Can you reconsider taking it in the media tree ? I you can't, I'll ask Dave (just added him in Cc) to take it into the DRM tree. Thanks. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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 v2 1/3] Add BGR888_1X24 and GBR888_1X24 media bus formats
Hi Philip, On Mon, 02 Feb 2015 16:34:42 +0100 Philipp Zabel p.za...@pengutronix.de wrote: Am Montag, den 02.02.2015, 13:24 -0200 schrieb Mauro Carvalho Chehab: Em Mon, 02 Feb 2015 16:21:00 +0100 Philipp Zabel p.za...@pengutronix.de escreveu: Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil: On 12/03/2014 02:53 PM, Philipp Zabel wrote: This patch adds two more 24-bit RGB formats. BGR888 is more or less common, GBR888 is used on the internal connection between the IPU display interface and the TVE (VGA DAC) on i.MX53 SoCs. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This three-part patch series doesn't apply. Is it on top of another patch series? It is on top of Add RGB444_1X12 and RGB565_1X16 media bus formats and Add LVDS RGB media bus formats. Anyway, it can't be merged unless it is actually used in a driver. I'd like to use these in the imx-drm driver, so this is kind of a chicken and egg situation. Shall I submit a patch that uses the defines to dri-devel and reference it here? Submit the full patch series with the imx-drm driver, mentioning at the V4L2 patch that it will be applied via the DRM tree. We'll review and give our ack for it to be applied via DRM tree. I'll do that, thanks. Don't know if you plan to keep the dependency on my RGB444 and RGB565 addition, but if you do, I guess you don't want to wait for my atmel-hlcdc changes, so the best solution is to include my patch in your series ;-). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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] media:dvb-frontends:Change setting of dtv_frontend_properties modulation to the correct value in the function,hd29l2_get_frontend
Moikka!
That patch is not correct and will not even compile. Problem is that
QAM_4NR and QAM_4 are not defined (OK, QPSK is QAM-4).
regards
Antti
On 02/02/2015 04:34 PM, Nicholas Krause wrote:
Changes the values in the switch statement of the function,d29l2_get_frontend
to use the proper value for the dtv_frontend_properties modulation value.
Further
more this changes the values of case 0 and case 1 to use the correct values of
QAM_4NR and QAM_4 respectfully.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/media/dvb-frontends/hd29l2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/hd29l2.c
b/drivers/media/dvb-frontends/hd29l2.c
index d7b9d54..48cafc9 100644
--- a/drivers/media/dvb-frontends/hd29l2.c
+++ b/drivers/media/dvb-frontends/hd29l2.c
@@ -579,11 +579,11 @@ static int hd29l2_get_frontend(struct dvb_frontend *fe)
switch ((buf[0] 0) 0x07) {
case 0: /* QAM4NR */
str_constellation = QAM4NR;
- c-modulation = QAM_AUTO; /* FIXME */
+ c-modulation = QAM_4NR;
break;
case 1: /* QAM4 */
str_constellation = QAM4;
- c-modulation = QPSK; /* FIXME */
+ c-modulation = QAM_4;
break;
case 2:
str_constellation = QAM16;
--
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
[no subject]
Hi, As I faced problems with my Terratec Cinergy T PCIe Dual and was unable to solve it (yet), I recently purchased a used Hauppauge HVR-2200 PCIe dual tuner. I immediately ran into problems with the HVR-2200 as well, perfectly described here: http://whirlpool.net.au/wiki/n54l_all_in_one (scroll down or search saa7164_cmd_send() No free sequences) Basically, it starts working but after a while I get an Event timed out message and several i2c errors and VDR shuts down (some hours after reboot). As the web page mentions, I tested downgrading the PCIe bandwith from GEN2 to GEN1 without success. But after playing with different BIOS options, what did the trick was limiting the power-saving C-states. If I select C7 as the maximum C-state, the card fails as described. After limiting the maximum C-state to C6, it has been working for a whole weekend. The HVR-2200 was also tested in a GA-H67MA-UD2H-B3 board with an G1610 Celeron, working without problems (although maximum C-state setup was not checked). Probably the error is present in other saa7164 boards. My VDR server is based on BayTrail J1900 (Asrock Q1900M). PS: I'm still waiting for advice regarding my Cinergy T/cx23885 problems and debugging.
Re: [RFC PATCH 2/2] [media] videobuf2: return -EPIPE from DQBUF after the last buffer
Am Montag, den 02.02.2015, 15:00 +0100 schrieb Hans Verkuil: On 01/22/2015 12:28 PM, Philipp Zabel wrote: If the last buffer was dequeued from a capture queue, let poll return immediately and let DQBUF return -EPIPE to signal there will no more buffers to dequeue until STREAMOFF. This looks OK to me, although I would like to see comments from others as well. Of course, this needs to be documented in the spec as well. Thanks, I'll fix that in the next round. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- TODO: (How) should the last_buffer_dequeud flag be cleared in reaction to V4L2_DEC_CMD_START? I would suggest an inline function in videobuf2-core.h that clears the flag and that drivers can call. I don't think the vb2 core can detect when it is OK to clear the flag, it needs to be told by the driver (correct me if I am wrong). No, I think you are right that this should be done explicitly. I'll add an inline function next time. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] Add BGR888_1X24 and GBR888_1X24 media bus formats
On 12/03/2014 02:53 PM, Philipp Zabel wrote: This patch adds two more 24-bit RGB formats. BGR888 is more or less common, GBR888 is used on the internal connection between the IPU display interface and the TVE (VGA DAC) on i.MX53 SoCs. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This three-part patch series doesn't apply. Is it on top of another patch series? Anyway, it can't be merged unless it is actually used in a driver. I'm changing this to 'Changes Requested' in patchwork. Regards, Hans --- Changes since v1: - Reordered 24-bit RGB formats alphabetically --- Documentation/DocBook/media/v4l/subdev-formats.xml | 60 ++ include/uapi/linux/media-bus-format.h | 4 +- 2 files changed, 63 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 52d7f04..a8da9d3 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -469,6 +469,66 @@ entrybsubscript1/subscript/entry entrybsubscript0/subscript/entry /row + row id=MEDIA-BUS-FMT-BGR888-1X24 + entryMEDIA_BUS_FMT_BGR888_1X24/entry + entry0x1013/entry + entry/entry + dash-ent-8; + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row + row id=MEDIA-BUS-FMT-GBR888-1X24 + entryMEDIA_BUS_FMT_GBR888_1X24/entry + entry0x1014/entry + entry/entry + dash-ent-8; + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row row id=MEDIA-BUS-FMT-RGB888-1X24 entryMEDIA_BUS_FMT_RGB888_1X24/entry entry0x100a/entry diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 7f8b1e2..10b40dd 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -33,7 +33,7 @@ #define MEDIA_BUS_FMT_FIXED 0x0001 -/* RGB - next is 0x1013 */ +/* RGB - next is 0x1015 */ #define MEDIA_BUS_FMT_RGB444_1X120x100e #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 @@ -46,6 +46,8 @@ #define MEDIA_BUS_FMT_RGB565_2X8_LE 0x1008 #define MEDIA_BUS_FMT_RGB666_1X180x1009 #define MEDIA_BUS_FMT_RGB666_LVDS_SPWG 0x1010 +#define MEDIA_BUS_FMT_BGR888_1X240x1013 +#define MEDIA_BUS_FMT_GBR888_1X240x1014 #define MEDIA_BUS_FMT_RGB888_1X240x100a #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c -- To unsubscribe from this list: send
[PATCHv2] [media] cx23885: move CI/MAC registration to a separate function
As reported by smatch:
drivers/media/pci/cx23885/cx23885-dvb.c:2080 dvb_register() Function
too hairy. Giving up.
This is indeed a too complex function, with lots of stuff inside.
Breaking this into two functions makes it a little bit less hairy.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 351fa952f210..45fbe1e4d2d0 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1069,6 +1069,116 @@ static struct dib7000p_config dib7070p_dib7000p_config
= {
.hostbus_diversity = 1,
};
+static int dvb_register_ci_mac(struct cx23885_tsport *port)
+{
+ struct cx23885_dev *dev = port-dev;
+ struct i2c_client *client_ci = NULL;
+ struct vb2_dvb_frontend *fe0;
+
+ fe0 = vb2_dvb_get_frontend(port-frontends, 1);
+ if (!fe0)
+ return -EINVAL;
+
+ switch (dev-board) {
+ case CX23885_BOARD_NETUP_DUAL_DVBS2_CI: {
+ static struct netup_card_info cinfo;
+
+ netup_get_card_info(dev-i2c_bus[0].i2c_adap, cinfo);
+ memcpy(port-frontends.adapter.proposed_mac,
+ cinfo.port[port-nr - 1].mac, 6);
+ printk(KERN_INFO NetUP Dual DVB-S2 CI card port%d MAC=%pM\n,
+ port-nr, port-frontends.adapter.proposed_mac);
+
+ netup_ci_init(port);
+ return 0;
+ }
+ case CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF: {
+ struct altera_ci_config netup_ci_cfg = {
+ .dev = dev,/* magic number to identify*/
+ .adapter = port-frontends.adapter,/* for CI */
+ .demux = fe0-dvb.demux,/* for hw pid filter */
+ .fpga_rw = netup_altera_fpga_rw,
+ };
+
+ altera_ci_init(netup_ci_cfg, port-nr);
+ return 0;
+ }
+ case CX23885_BOARD_TEVII_S470: {
+ u8 eeprom[256]; /* 24C02 i2c eeprom */
+
+ if (port-nr != 1)
+ return 0;
+
+ /* Read entire EEPROM */
+ dev-i2c_bus[0].i2c_client.addr = 0xa0 1;
+ tveeprom_read(dev-i2c_bus[0].i2c_client, eeprom,
sizeof(eeprom));
+ printk(KERN_INFO TeVii S470 MAC= %pM\n, eeprom + 0xa0);
+ memcpy(port-frontends.adapter.proposed_mac, eeprom + 0xa0, 6);
+ return 0;
+ }
+ case CX23885_BOARD_DVBSKY_T9580:
+ case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_DVBSKY_S952:
+ case CX23885_BOARD_DVBSKY_T982: {
+ u8 eeprom[256]; /* 24C02 i2c eeprom */
+
+ if (port-nr 2)
+ return 0;
+
+ /* Read entire EEPROM */
+ dev-i2c_bus[0].i2c_client.addr = 0xa0 1;
+ tveeprom_read(dev-i2c_bus[0].i2c_client, eeprom,
+ sizeof(eeprom));
+ printk(KERN_INFO %s port %d MAC address: %pM\n,
+ cx23885_boards[dev-board].name, port-nr,
+ eeprom + 0xc0 + (port-nr-1) * 8);
+ memcpy(port-frontends.adapter.proposed_mac, eeprom + 0xc0 +
+ (port-nr-1) * 8, 6);
+ return 0;
+ }
+ case CX23885_BOARD_DVBSKY_S950C:
+ case CX23885_BOARD_DVBSKY_T980C:
+ case CX23885_BOARD_TT_CT2_4500_CI: {
+ u8 eeprom[256]; /* 24C02 i2c eeprom */
+ struct sp2_config sp2_config;
+ struct i2c_board_info info;
+ struct cx23885_i2c *i2c_bus2 = dev-i2c_bus[1];
+
+ /* attach CI */
+ memset(sp2_config, 0, sizeof(sp2_config));
+ sp2_config.dvb_adap = port-frontends.adapter;
+ sp2_config.priv = port;
+ sp2_config.ci_control = cx23885_sp2_ci_ctrl;
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, sp2, I2C_NAME_SIZE);
+ info.addr = 0x40;
+ info.platform_data = sp2_config;
+ request_module(info.type);
+ client_ci = i2c_new_device(i2c_bus2-i2c_adap, info);
+ if (client_ci == NULL || client_ci-dev.driver == NULL)
+ return -ENODEV;
+ if (!try_module_get(client_ci-dev.driver-owner)) {
+ i2c_unregister_device(client_ci);
+ return -ENODEV;
+ }
+ port-i2c_client_ci = client_ci;
+
+ if (port-nr != 1)
+ return 0;
+
+ /* Read entire EEPROM */
+ dev-i2c_bus[0].i2c_client.addr = 0xa0 1;
+ tveeprom_read(dev-i2c_bus[0].i2c_client, eeprom,
+ sizeof(eeprom));
+ printk(KERN_INFO %s MAC
Re: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote:
On 02/01/2015 02:06 PM, Raimonds Cicans wrote:
On 29.01.2015 14:12, Hans Verkuil wrote:
On 01/29/15 12:51, Raimonds Cicans wrote:
On 29.01.2015 09:33, Hans Verkuil wrote:
On 01/11/2015 10:33 AM, Raimonds Cicans wrote:
I contacted you because I am hit by regression caused by your commit:
453afdd [media] cx23885: convert to vb2
My system:
AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard
TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver)
After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7
(have commit) I started receiving following IOMMU related messages:
1)
AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d
address=0x0637c000 flags=0x]
where device=0a:00.0 is TBS6981 card
As far as I can tell this has nothing to do with the cx23885 driver but
is
a bug in the amd iommu/BIOS. See e.g.:
https://bbs.archlinux.org/viewtopic.php?pid=1309055
I managed to reproduce the Intel equivalent if I enable
CONFIG_IOMMU_SUPPORT.
Most likely due to broken BIOS/ACPI/whatever information that's read by
the
kernel. I would recommend disabling this kernel option.
Maybe...
But on other hand this did not happen on old kernel with old driver.
And when I did bisection on old kernel + media tree I started to
receive this message only on new driver.
Was CONFIG_IOMMU_SUPPORT enabled in the old kernel?
zgrep CONFIG_IOMMU_SUPPORT /proc/config.gz
CONFIG_IOMMU_SUPPORT=y
Raimonds Cicans
Hi Hans,
Raimonds and Jurgen,
Can you both test with the following patch applied to the driver:
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 1ad4994..72df5ae 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -1497,6 +1497,7 @@ void cx23885_buf_queue(struct cx23885_tsport *port,
struct cx23885_buffer *buf)
buf-risc.jmp[0] = cpu_to_le32(RISC_JUMP | RISC_CNT_INC);
buf-risc.jmp[1] = cpu_to_le32(buf-risc.dma + 12);
buf-risc.jmp[2] = cpu_to_le32(0); /* bits 63-32 */
+ wmb();
spin_lock_irqsave(dev-slock, flags);
if (list_empty(cx88q-active)) {
@@ -1505,10 +1506,12 @@ void cx23885_buf_queue(struct cx23885_tsport *port,
struct cx23885_buffer *buf)
buf, buf-vb.v4l2_buf.index, __func__);
} else {
buf-risc.cpu[0] |= cpu_to_le32(RISC_IRQ1);
+ wmb();
prev = list_entry(cx88q-active.prev, struct cx23885_buffer,
queue);
list_add_tail(buf-queue, cx88q-active);
prev-risc.jmp[1] = cpu_to_le32(buf-risc.dma);
+ wmb();
dprintk(1, [%p/%d] %s - append to active\n,
buf, buf-vb.v4l2_buf.index, __func__);
}
I wonder if there is some PCI write reordering going on that is causing some
of the weird
behavior that you see.
I'll test this patch on top of the other patches. So far the only
messages left are the mpeg errors.
Regards,
Jurgen
--
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 FOR v3.20] Various fixes
Found a few more patches that I missed. Regards, Hans The following changes since commit 05439b1a36935992785c4f28f6693e73820321cb: [media] media: au0828 - convert to use videobuf2 (2015-02-02 11:58:27 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.20e for you to fetch changes up to d1abf49aab3b43ac0eb2551592ab9cba65abad9b: media: platform: fix platform_no_drv_owner.cocci warnings (2015-02-02 16:14:31 +0100) Arnd Bergmann (1): marvell-ccic: MMP_CAMERA no longer builds Fengguang Wu (1): media: platform: fix platform_no_drv_owner.cocci warnings Markus Elfring (1): staging: bcm2048: Delete an unnecessary check before the function call video_unregister_device Prabhakar Lad (1): media: ti-vpe: Use mem-to-mem ioctl helpers drivers/media/platform/am437x/am437x-vpfe.c | 1 - drivers/media/platform/marvell-ccic/Kconfig | 2 +- drivers/media/platform/ti-vpe/vpe.c | 157 +- drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +- 4 files changed, 52 insertions(+), 112 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state
I'm sorry, I resend the message with a descriptive subject Mensaje original De : dcr...@telefonica.net Fecha : 02/02/2015 - 16:04 (GMT) Para : linux-media@vger.kernel.org Asunto : Hi, As I faced problems with my Terratec Cinergy T PCIe Dual and was unable to solve it (yet), I recently purchased a used Hauppauge HVR-2200 PCIe dual tuner. I immediately ran into problems with the HVR-2200 as well, perfectly described here: http://whirlpool.net.au/wiki/n54l_all_in_one (scroll down or search saa7164_cmd_send() No free sequences) Basically, it starts working but after a while I get an Event timed out message and several i2c errors and VDR shuts down (some hours after reboot). As the web page mentions, I tested downgrading the PCIe bandwith from GEN2 to GEN1 without success. But after playing with different BIOS options, what did the trick was limiting the power-saving C-states. If I select C7 as the maximum C-state, the card fails as described. After limiting the maximum C-state to C6, it has been working for a whole weekend. The HVR-2200 was also tested in a GA-H67MA-UD2H-B3 board with an G1610 Celeron, working without problems (although maximum C-state setup was not checked). Probably the error is present in other saa7164 boards. My VDR server is based on BayTrail J1900 (Asrock Q1900M). PS: I'm still waiting for advice regarding my Cinergy T/cx23885 problems and debugging. -- --- dCrypt -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state
Basically, it starts working but after a while I get an Event timed out message and several i2c errors and VDR shuts down (some hours after reboot). As the web page mentions, I tested downgrading the PCIe bandwith from GEN2 to GEN1 without success. But after playing with different BIOS options, what did the trick was limiting the power-saving C-states. If I select C7 as the maximum C-state, the card fails as described. After limiting the maximum C-state to C6, it has been working for a whole weekend. Good feedback on the C7 vs C6 power state, thanks. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than an exporter can actually do.. I think the scenario you describe could be handled by two sg-lists, if the exporter was clever enough. That's already needed, each attachment has it's own sg-list. After all there's no array of dma_addr_t in the sg tables, so you can't use one sg for more than one mapping. And due to different iommu different devices can easily end up with different addresses. Well, to be fair it may not be explicitly stated, but currently one should assume the dma_addr_t's in the dmabuf sglist are bogus. With gpu's that implement per-process/context page tables, I'm not really sure that there is a sane way to actually do anything else.. Hm, what does per-process/context page tables have to do here? At least on i915 we have a two levels of page tables: - first level for vm/device isolation, used through dma api - 2nd level for per-gpu-context isolation and context switching, handled internally. Since atm the dma api doesn't have any context of contexts or different pagetables, I don't see who you could use that at all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Mon, Feb 02, 2015 at 05:36:10PM -0500, Rob Clark wrote: well, I guess anyways when it comes to sharing buffers, it won't be the vram placement of the bo that gets shared ;-) Actually that's pretty much what I'd like to be able to do for i915. Except that vram is just a specially protected chunk of main memory. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Mon, Feb 02, 2015 at 09:46:16PM +, Russell King - ARM Linux wrote: On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than an exporter can actually do.. I think the scenario you describe could be handled by two sg-lists, if the exporter was clever enough. That's already needed, each attachment has it's own sg-list. After all there's no array of dma_addr_t in the sg tables, so you can't use one sg for more than one mapping. And due to different iommu different devices can easily end up with different addresses. Well, to be fair it may not be explicitly stated, but currently one should assume the dma_addr_t's in the dmabuf sglist are bogus. With gpu's that implement per-process/context page tables, I'm not really sure that there is a sane way to actually do anything else.. That's incorrect - and goes dead against the design of scatterlists. Not only that, but it is entirely possible that you may get handed memory via dmabufs for which there are no struct page's associated with that memory - think about display systems which have their own video memory which is accessible to the GPU, but it isn't system memory. In those circumstances, you have to use the dma_addr_t's and not the pages. Yeah exactly. At least with i915 we'd really want to be able to share stolen memory in some cases, and since that's stolen there's no struct pages for them. On top of that any cpu access is also blocked to that range in the memory controller, so the dma_addr_t is really the _only_ thing you can use to get at those memory ranges. And afaik the camera pipe on intel soc can get there - unfortunately that one doesn't have an upstream driver :( And just to clarify: All current dma-buf exporter that I've seen implement the sg mapping correctly and _do_ map the sg table into device address space with dma_map_sg. In other words: The dma_addr_t are all valid, it's just that e.g. with ttm no one has bothered to teach ttm a dma-buf correctly. The internal abstraction is all there, ttm-internal buffer object interface match what dma-buf exposes fairly closes (hey I didn't do shit when designing those interfaces ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
randconfig build error with next-20150202, in drivers/media/usb/dvb-usb/dib0700_devices.c
Building with the attached random configuration file, drivers/built-in.o: In function `stk7700p_tuner_attach': dib0700_devices.c:(.text+0x85e1d7): undefined reference to `dib7000m_get_i2c_master' drivers/built-in.o: In function `stk7700p_pid_filter': dib0700_devices.c:(.text+0x85e2e5): undefined reference to `dib7000m_pid_filter' drivers/built-in.o: In function `stk7700p_pid_filter_ctrl': dib0700_devices.c:(.text+0x85e34f): undefined reference to `dib7000m_pid_filter_ctrl' make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.19.0-rc6 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y CONFIG_RCU_USER_QS=y # CONFIG_CONTEXT_TRACKING_FORCE is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set CONFIG_TREE_RCU_TRACE=y CONFIG_RCU_KTHREAD_PRIO=0 # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_CGROUPS is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_LTO_MENU is not set CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_PCSPKR_PLATFORM is not set # CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y # CONFIG_AIO is
Re: [PATCH v2 1/3] Add BGR888_1X24 and GBR888_1X24 media bus formats
Hi Boris, Am Montag, den 02.02.2015, 16:48 +0100 schrieb Boris Brezillon: Hi Philip, On Mon, 02 Feb 2015 16:34:42 +0100 Philipp Zabel p.za...@pengutronix.de wrote: Am Montag, den 02.02.2015, 13:24 -0200 schrieb Mauro Carvalho Chehab: Em Mon, 02 Feb 2015 16:21:00 +0100 Philipp Zabel p.za...@pengutronix.de escreveu: Am Montag, den 02.02.2015, 16:08 +0100 schrieb Hans Verkuil: On 12/03/2014 02:53 PM, Philipp Zabel wrote: This patch adds two more 24-bit RGB formats. BGR888 is more or less common, GBR888 is used on the internal connection between the IPU display interface and the TVE (VGA DAC) on i.MX53 SoCs. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This three-part patch series doesn't apply. Is it on top of another patch series? It is on top of Add RGB444_1X12 and RGB565_1X16 media bus formats and Add LVDS RGB media bus formats. Anyway, it can't be merged unless it is actually used in a driver. I'd like to use these in the imx-drm driver, so this is kind of a chicken and egg situation. Shall I submit a patch that uses the defines to dri-devel and reference it here? Submit the full patch series with the imx-drm driver, mentioning at the V4L2 patch that it will be applied via the DRM tree. We'll review and give our ack for it to be applied via DRM tree. I'll do that, thanks. Don't know if you plan to keep the dependency on my RGB444 and RGB565 addition, but if you do, I guess you don't want to wait for my atmel-hlcdc changes, so the best solution is to include my patch in your series ;-). Ok, I'll include your patch since I need the RGB565 format description as well. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote: On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote: Quite possibly for some of these edge some of cases, some of the dma-buf exporters are going to need to get more clever (ie. hand off different scatterlists to different clients). Although I think by far the two common cases will be I can support anything via an iommu/mmu and I need phys contig. But that isn't an issue w/ dma-buf itself, so much as it is an issue w/ drivers. I guess there would be more interest in fixing up drivers when actual hw comes along that needs it.. However, validating the attachments is the business of dma-buf. This is actual infrastructure, which should ensure some kind of sanity such as the issues I've raised. My initial thought is for dma-buf to not try to prevent something than an exporter can actually do.. I think the scenario you describe could be handled by two sg-lists, if the exporter was clever enough. That's already needed, each attachment has it's own sg-list. After all there's no array of dma_addr_t in the sg tables, so you can't use one sg for more than one mapping. And due to different iommu different devices can easily end up with different addresses. That all said, I think probably all the existing exporters cache the sg-list. And I can't think of any actual hw which would hit this problem that can be solved by multiple sg-lists for the same physical memory. (And the constraint calculation kind of assumes the end result will be a single sg-list.) So it seems reasonable to me to check that max_segment_count * max_segment_size is not smaller than the buffer. If it was a less theoretical problem, I think I'd more inclined for a way that the exporter could override the checks, or something along those lines. otoh, if the attachment is just not possible because the buffer has been already allocated and mapped by someone with more relaxed constraints.. then I think the driver should be the one returning the error since dma-buf doesn't know this. Importers currently cache the mapped sg list aggressively (i915) or outright pin it for as long as possible (everyone else). So any kind of moving stuff around is pretty much impossible with current drivers. The even worse violation of the dma-buf spec is that all the ttm drivers don't use the sg table correctly at all. They assume that each physical page has exactly one sg table entry, and then fish out the struct page * pointer from that to build up their own bo management stuff and ignore everything else. The whole we can push it onto our users is really on - what that results in is the users ignoring most of the requirements and just doing their own thing, which ultimately ends up with the whole thing turning into a disgusting mess - one which becomes very difficult to fix later. Ideally at some point, dma-mapping or some helpers would support allocations matching constraints.. I think only actual gpu drivers want to do crazy enough things that they'd want to bypass dma-mapping. If everyone else can use dma-mapping and/or helpers then we make it harder for drivers to do the wrong thing than to do the right thing. Now, if we're going to do the more clever thing you mention above, that rather negates the point of this two-part patch set, which is to provide the union of the DMA capabilities of all users. A union in that case is no longer sane as we'd be tailoring the SG lists to each user. It doesn't really negate.. a different sg list representing the same physical memory cannot suddenly make the buffer physically contiguous (from the perspective of memory).. (unless we are not on the same page here, so to speak) Or someone was not chip and put a decent iommu in front of the same IP block. E.g. the raspi gpu needs contiguous memory for rendering, but the same block is used elsewhere but then with an iommu. But thinking about all this I wonder whether we really should start with some kind of constraint solving. It feels fairly leaky compared to the encapsulation the dma api provides, and so isn't really better for upstream than just using ion (which completely gives up on this problem and relies on userspace allocating correct buffers). And if we step away for a bit there's already a bunch of things that the current dma api fails at, and which is just a bit a worse problem with dma-buf sharing: There's not really a generic way to map an sg table zero-copy, i.e. there's no generic way to avoid bounce buffers. And that's already hurting all the existing gpu drivers: ttm essentially does page-sized allocs for everything and then has it's own dma allocator on top of that page-cache. i915 has some other hacks to at least not fail the bounce buffer allocator too badly. Grepping for SWIOTLB in drm is fairly interesting. So imo
[PATCH] rtl2830: add kernel-doc comments for platform_data
Add kernel-doc comments for platform_data configuration structure.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2830.h | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2830.h
b/drivers/media/dvb-frontends/rtl2830.h
index 156edf7..1c6df7f 100644
--- a/drivers/media/dvb-frontends/rtl2830.h
+++ b/drivers/media/dvb-frontends/rtl2830.h
@@ -20,33 +20,26 @@
#include linux/dvb/frontend.h
+/**
+ * struct rtl2830_platform_data - Platform data for the RTL2830 driver
+ * @clk: Clock frequency (400, 1600, 2500, 2880).
+ * @spec_inv: Spectrum inversion.
+ * @vtop: AGC take-over point.
+ * @krf: AGC ratio.
+ * @agc_targ_val: AGC.
+ * @get_dvb_frontend: Get DVB frontend.
+ * @get_i2c_adapter: Get I2C adapter.
+ * @pid_filter: Set PID to PID filter.
+ * @pid_filter_ctrl: Control PID filter.
+ */
+
struct rtl2830_platform_data {
- /*
-* Clock frequency.
-* Hz
-* 400, 1600, 2500, 2880
-*/
u32 clk;
-
- /*
-* Spectrum inversion.
-*/
bool spec_inv;
-
- /*
-*/
u8 vtop;
-
- /*
-*/
u8 krf;
-
- /*
-*/
u8 agc_targ_val;
- /*
-*/
struct dvb_frontend* (*get_dvb_frontend)(struct i2c_client *);
struct i2c_adapter* (*get_i2c_adapter)(struct i2c_client *);
int (*pid_filter)(struct dvb_frontend *, u8, u16, int);
--
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: libv4l
Hi, On Mon, Feb 2, 2015 at 5:55 PM, Kyle Dominguez k...@openmailbox.org wrote: Hello, When trying to build libv4l, it fails because I don't have the dependencies for v4l1. Is it possibe to make libv4l without having videodev.h? I only want the v4l2 parts, to which I have videodev2.h. What are the steps you are following to build it ? What error do you get ? just incase here are the correct steps (of current master assuming you are cross compiling): 1: ./bootstrap.sh 2: ./configure --host=cross-compiler --without-jpeg 3: make -j 4 Regards, --Prabhakar Lad -- 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 21/66] rtl2830: implement own I2C locking
On 02/02/2015 10:07 PM, Mauro Carvalho Chehab wrote:
Em Tue, 23 Dec 2014 22:49:14 +0200
Antti Palosaari cr...@iki.fi escreveu:
Own I2C locking is needed due to two special reasons:
1) Chips uses multiple register pages/banks on single I2C slave.
Page is changed via I2C register access.
2) Chip offers muxed/gated I2C adapter for tuner. Gate/mux is
controlled by I2C register access.
Due to these reasons, I2C locking did not fit very well.
I don't like the idea of calling __i2c_transfer() without calling first
i2c_lock_adapter(). This can be dangerous, as the I2C core itself uses
the lock for its own usage.
Ok, this may eventually work ok for now, but a further change at the I2C
core could easily break it. So, we need to double check about such
patch with the I2C maintainer.
Jean,
Are you ok with such patch? If so, please ack.
Basic problem here is that I2C-mux itself is controlled by same I2C
device which implements I2C adapter for tuner.
Here is what connections looks like:
___
| USB IF | | demod| |tuner |
|---| || ||
| |--I2C--|-/ -|--I2C--||
|I2C master | | I2C mux | | I2C slave |
|___| || ||
So when tuner is called via I2C, it needs recursively call same I2C
adapter which is already locked. More elegant solution would be indeed nice.
regards
Antti
Regards,
Mauro
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2830.c | 45 +-
drivers/media/dvb-frontends/rtl2830_priv.h | 1 +
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2830.c
b/drivers/media/dvb-frontends/rtl2830.c
index 8abaca6..3a9e4e9 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -43,7 +43,7 @@ static int rtl2830_wr(struct i2c_client *client, u8 reg,
const u8 *val, int len)
buf[0] = reg;
memcpy(buf[1], val, len);
- ret = i2c_transfer(client-adapter, msg, 1);
+ ret = __i2c_transfer(client-adapter, msg, 1);
if (ret == 1) {
ret = 0;
} else {
@@ -73,7 +73,7 @@ static int rtl2830_rd(struct i2c_client *client, u8 reg, u8
*val, int len)
}
};
- ret = i2c_transfer(client-adapter, msg, 2);
+ ret = __i2c_transfer(client-adapter, msg, 2);
if (ret == 2) {
ret = 0;
} else {
@@ -93,16 +93,23 @@ static int rtl2830_wr_regs(struct i2c_client *client, u16
reg, const u8 *val, in
u8 reg2 = (reg 0) 0xff;
u8 page = (reg 8) 0xff;
+ mutex_lock(dev-i2c_mutex);
+
/* switch bank if needed */
if (page != dev-page) {
ret = rtl2830_wr(client, 0x00, page, 1);
if (ret)
- return ret;
+ goto err_mutex_unlock;
dev-page = page;
}
- return rtl2830_wr(client, reg2, val, len);
+ ret = rtl2830_wr(client, reg2, val, len);
+
+err_mutex_unlock:
+ mutex_unlock(dev-i2c_mutex);
+
+ return ret;
}
/* read multiple registers */
@@ -113,16 +120,23 @@ static int rtl2830_rd_regs(struct i2c_client *client, u16
reg, u8 *val, int len)
u8 reg2 = (reg 0) 0xff;
u8 page = (reg 8) 0xff;
+ mutex_lock(dev-i2c_mutex);
+
/* switch bank if needed */
if (page != dev-page) {
ret = rtl2830_wr(client, 0x00, page, 1);
if (ret)
- return ret;
+ goto err_mutex_unlock;
dev-page = page;
}
- return rtl2830_rd(client, reg2, val, len);
+ ret = rtl2830_rd(client, reg2, val, len);
+
+err_mutex_unlock:
+ mutex_unlock(dev-i2c_mutex);
+
+ return ret;
}
/* read single register */
@@ -815,6 +829,10 @@ static int rtl2830_select(struct i2c_adapter *adap, void
*mux_priv, u32 chan_id)
};
int ret;
+ dev_dbg(client-dev, \n);
+
+ mutex_lock(dev-i2c_mutex);
+
/* select register page */
ret = __i2c_transfer(client-adapter, select_reg_page_msg, 1);
if (ret != 1) {
@@ -841,6 +859,18 @@ err:
return ret;
}
+static int rtl2830_deselect(struct i2c_adapter *adap, void *mux_priv, u32 chan)
+{
+ struct i2c_client *client = mux_priv;
+ struct rtl2830_dev *dev = i2c_get_clientdata(client);
+
+ dev_dbg(client-dev, \n);
+
+ mutex_unlock(dev-i2c_mutex);
+
+ return 0;
+}
+
static struct dvb_frontend *rtl2830_get_dvb_frontend(struct i2c_client
*client)
{
struct rtl2830_dev *dev = i2c_get_clientdata(client);
@@ -886,6 +916,7 @@ static int rtl2830_probe(struct i2c_client *client,
dev-client = client;
dev-pdata = client-dev.platform_data;
dev-sleeping = true;
Re: [PATCH 21/66] rtl2830: implement own I2C locking
Ok, this may eventually work ok for now, but a further change at the I2C core could easily break it. So, we need to double check about such patch with the I2C maintainer. Jean, Are you ok with such patch? If so, please ack. Jean handed over I2C to me in late 2012 :) Basic problem here is that I2C-mux itself is controlled by same I2C device which implements I2C adapter for tuner. Here is what connections looks like: ___ | USB IF | | demod| |tuner | |---| || || | |--I2C--|-/ -|--I2C--|| |I2C master | | I2C mux | | I2C slave | |___| || || So when tuner is called via I2C, it needs recursively call same I2C adapter which is already locked. More elegant solution would be indeed nice. So, AFAIU this is the same problem that I2C based mux devices have (like drivers/i2c/muxes/i2c-mux-pca954x.c)? They also use the unlocked transfers... signature.asc Description: Digital signature
Re: [PATCH 21/66] rtl2830: implement own I2C locking
Hi Mauro, Antti, On Mon, 2 Feb 2015 18:07:26 -0200, Mauro Carvalho Chehab wrote: Em Tue, 23 Dec 2014 22:49:14 +0200 Antti Palosaari cr...@iki.fi escreveu: Own I2C locking is needed due to two special reasons: 1) Chips uses multiple register pages/banks on single I2C slave. Page is changed via I2C register access. This is no good reason to implement your own i2c bus locking. Lots of i2c slave device work that way, and the way to handle it is through a dedicated lock at the i2c slave device level. This is in addition to the standard i2c bus locking and not a replacement. 2) Chip offers muxed/gated I2C adapter for tuner. Gate/mux is controlled by I2C register access. This, OTOH, is a valid reason for calling __i2c_transfer, and as a matter of fact a number of dvb frontend drivers already do so. Due to these reasons, I2C locking did not fit very well. I don't like the idea of calling __i2c_transfer() without calling first i2c_lock_adapter(). This can be dangerous, as the I2C core itself uses the lock for its own usage. I think the idea is that the i2c bus lock is already held at the time the muxing code is called. This happens each time the I2C muxing chip is an I2C chip itself. Ok, this may eventually work ok for now, but a further change at the I2C core could easily break it. So, we need to double check about such patch with the I2C maintainer. If it breaks than it'll break a dozen drivers which are already doing that, not just this one. But it's OK, I don't see this happening soon. Jean, Are you ok with such patch? If so, please ack. First of all: I am no longer the maintainer of the I2C subsystem. That being said... The changes look OK to me. I think it's how they are presented which make them look suspect. As I understand it, the extra locking at device level is unrelated with calling unlocked i2c transfer functions. The former change is to address the multi-page/bank register mapping, while the latter is to solve the deadlock due to the i2c bus topology and i2c-based muxing. If I am correct then it would be clearer to make that two separate patches with better descriptions. And if I'm wrong then the patch needs a better description too ;-) -- Jean Delvare SUSE L3 Support -- 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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote: On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter dan...@ffwll.ch wrote: My initial thought is for dma-buf to not try to prevent something than an exporter can actually do.. I think the scenario you describe could be handled by two sg-lists, if the exporter was clever enough. That's already needed, each attachment has it's own sg-list. After all there's no array of dma_addr_t in the sg tables, so you can't use one sg for more than one mapping. And due to different iommu different devices can easily end up with different addresses. Well, to be fair it may not be explicitly stated, but currently one should assume the dma_addr_t's in the dmabuf sglist are bogus. With gpu's that implement per-process/context page tables, I'm not really sure that there is a sane way to actually do anything else.. That's incorrect - and goes dead against the design of scatterlists. Not only that, but it is entirely possible that you may get handed memory via dmabufs for which there are no struct page's associated with that memory - think about display systems which have their own video memory which is accessible to the GPU, but it isn't system memory. In those circumstances, you have to use the dma_addr_t's and not the pages. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.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
Re: [GIT PULL] rtl28xxu / rtl2830 / rtl2832 / rtl2832_sdr changes
PULL request update. The following changes since commit ab98180ac2e6e41058f8829c0961aa306c610c16: [media] smipcie: return more proper value in interrupt handler (2015-02-02 14:42:53 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git rtl28xx for you to fetch changes up to 5dd18a43dfaa3a17f7f3ab9835ce55740cf20706: rtl2832_sdr: add kernel-doc comments for platform_data (2015-02-02 19:41:31 +0200) Antti Palosaari (67): dvb-usb-v2: add pointer to 'struct usb_interface' for driver usage rtl2832: convert driver to I2C binding rtl2830: convert driver to kernel I2C model rtl28xxu: use I2C binding for RTL2830 demod driver rtl2830: get rid of legacy DVB driver binding rtl2830: rename 'priv' to 'dev' rtl2830: carry pointer to I2C client for every function rtl2830: fix logging rtl2830: get rid of internal config data rtl2830: style related changes rtl2830: implement DVBv5 CNR statistic rtl2830: implement DVBv5 signal strength statistics rtl2830: implement DVBv5 BER statistic rtl2830: wrap DVBv5 signal strength to DVBv3 rtl2830: wrap DVBv5 BER to DVBv3 rtl2830: wrap DVBv5 CNR to DVBv3 SNR rtl2830: implement PID filter rtl28xxu: add support for RTL2831U/RTL2830 PID filter rtl2830: implement own I2C locking rtl2830: convert to regmap API rtl2832: add platform data callbacks for exported resources rtl28xxu: use rtl2832 demod callbacks accessing its resources rtl2832: remove exported resources rtl2832: rename driver state variable from 'priv' to 'dev' rtl2832: enhance / fix logging rtl2832: move all configuration to platform data struct rtl28xxu: use platform data config for rtl2832 demod rtl2832: convert to regmap API rtl2832: implement DVBv5 CNR statistic rtl2832: implement DVBv5 BER statistic rtl2832: wrap DVBv5 CNR to DVBv3 SNR rtl2832: wrap DVBv5 BER to DVBv3 rtl2832: implement DVBv5 signal strength statistics rtl28xxu: use demod mux I2C adapter for every tuner rtl2832: drop FE i2c gate control support rtl2832: define more demod lock statuses rtl2832: implement PID filter rtl28xxu: add support for RTL2832U/RTL2832 PID filter rtl2832: use regmap reg cache rtl2832: remove unneeded software reset from init() rtl2832: merge reg page as a part of reg address rtl2832: provide register IO callbacks rtl2832_sdr: rename state variable from 's' to 'dev' rtl2832_sdr: convert to platform driver rtl28xxu: switch SDR module to platform driver rtl28xxu: use master I2C adapter for slave demods rtl2832_sdr: fix logging rtl2832_sdr: cleanups rtl2832: cleanups and minor changes rtl2832: claim copyright and module author rtl2832: implement sleep rtl28xxu: fix DVB FE callback rtl28xxu: simplify FE callback handling rtl28xxu: do not refcount rtl2832_sdr module rtl2832_sdr: refcount to rtl28xxu rtl2832: remove internal mux I2C adapter rtl28xxu: rename state variable 'priv' to 'dev' rtl28xxu: fix logging rtl28xxu: move usb buffers to state rtl28xxu: add heuristic to detect chip type rtl28xxu: merge chip type specific all callbacks rtl28xxu: merge rtl2831u and rtl2832u properties rtl28xxu: correct reg access routine name prefixes rtl2832: implement own lock for regmap rtl2830: add kernel-doc comments for platform_data rtl2832: add kernel-doc comments for platform_data rtl2832_sdr: add kernel-doc comments for platform_data drivers/media/dvb-frontends/Kconfig |4 +- drivers/media/dvb-frontends/rtl2830.c | 944 --- drivers/media/dvb-frontends/rtl2830.h | 79 +++--- drivers/media/dvb-frontends/rtl2830_priv.h | 24 +-- drivers/media/dvb-frontends/rtl2832.c | 1341 +- drivers/media/dvb-frontends/rtl2832.h | 107 - drivers/media/dvb-frontends/rtl2832_priv.h | 31 ++-- drivers/media/dvb-frontends/rtl2832_sdr.c | 1189 ++-- drivers/media/dvb-frontends/rtl2832_sdr.h | 57 --- drivers/media/usb/dvb-usb-v2/dvb_usb.h |2 + drivers/media/usb/dvb-usb-v2/dvb_usb_core.c |1 + drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 881
Re: [PATCH 05/66] rtl2830: convert driver to kernel I2C model
On 01/27/2015 03:10 PM, Mauro Carvalho Chehab wrote:
Em Tue, 23 Dec 2014 22:48:58 +0200
Antti Palosaari cr...@iki.fi escreveu:
Convert driver to kernel I2C model. Old DVB proprietary model is
still left there also.
Signed-off-by: Antti Palosaari cr...@iki.fi
+struct rtl2830_platform_data {
+ /*
+* Clock frequency.
+* Hz
+* 400, 1600, 2500, 2880
+*/
+ u32 clk;
+
+ /*
+* Spectrum inversion.
+*/
+ bool spec_inv;
+
+ /*
+*/
+ u8 vtop;
+
+ /*
+*/
+ u8 krf;
+
+ /*
+*/
+ u8 agc_targ_val;
+
+ /*
+*/
+ struct dvb_frontend* (*get_dvb_frontend)(struct i2c_client *);
+ struct i2c_adapter* (*get_i2c_adapter)(struct i2c_client *);
+};
Please fix this to follow the Kernel CodingStyle for struct/function/...
documentation:
Documentation/kernel-doc-nano-HOWTO.txt
Sometimes, I just leave things like that to pass, but the above one is too
ugly, with empty multiple line comments, uncommented arguments, etc.
I added kernel-doc comments for rtl2830, rtl2832 and rtl2832_sdr driver
platform data. PULL request is already updated.
And next time please start keep noise earlier - I have written tens of
these drivers and that was first time you ask kernel-doc format comments
for driver configurations structures. I see those should be as
kernel-doc-nano-HOWTO.txt says, but it was first time I hear about that
rule.
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
[PATCH 3/3] rtl2832_sdr: add kernel-doc comments for platform_data
Add kernel-doc comments for platform_data configuration structure.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832_sdr.h | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.h
b/drivers/media/dvb-frontends/rtl2832_sdr.h
index dd22e42..d259476 100644
--- a/drivers/media/dvb-frontends/rtl2832_sdr.h
+++ b/drivers/media/dvb-frontends/rtl2832_sdr.h
@@ -29,16 +29,22 @@
#include media/v4l2-subdev.h
#include dvb_frontend.h
+/**
+ * struct rtl2832_sdr_platform_data - Platform data for the rtl2832_sdr driver
+ * @clk: Clock frequency (400, 1600, 2500, 2880).
+ * @tuner: Used tuner model.
+ * @i2c_client: rtl2832 demod driver I2C client.
+ * @bulk_read: rtl2832 driver private I/O interface.
+ * @bulk_write: rtl2832 driver private I/O interface.
+ * @update_bits: rtl2832 driver private I/O interface.
+ * @dvb_frontend: rtl2832 DVB frontend.
+ * @v4l2_subdev: Tuner v4l2 controls.
+ * @dvb_usb_device: DVB USB interface for USB streaming.
+ */
+
struct rtl2832_sdr_platform_data {
- /*
-* Clock frequency.
-* Hz
-* 400, 1600, 2500, 2880
-*/
u32 clk;
-
/*
-* Tuner.
* XXX: This list must be kept sync with dvb_usb_rtl28xxu USB IF driver.
*/
#define RTL2832_SDR_TUNER_TUA9001 0x24
--
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
[PATCH 2/3] rtl2832: add kernel-doc comments for platform_data
Add kernel-doc comments for platform_data configuration structure.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.h | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.h
b/drivers/media/dvb-frontends/rtl2832.h
index e5f67cf..a8e912e 100644
--- a/drivers/media/dvb-frontends/rtl2832.h
+++ b/drivers/media/dvb-frontends/rtl2832.h
@@ -25,16 +25,20 @@
#include linux/dvb/frontend.h
#include linux/i2c-mux.h
+/**
+ * struct rtl2832_platform_data - Platform data for the rtl2832 driver
+ * @clk: Clock frequency (400, 1600, 2500, 2880).
+ * @tuner: Used tuner model.
+ * @get_dvb_frontend: Get DVB frontend.
+ * @get_i2c_adapter: Get I2C adapter.
+ * @enable_slave_ts: Enable slave TS IF.
+ * @pid_filter: Set PID to PID filter.
+ * @pid_filter_ctrl: Control PID filter.
+ */
+
struct rtl2832_platform_data {
- /*
-* Clock frequency.
-* Hz
-* 400, 1600, 2500, 2880
-*/
u32 clk;
-
/*
-* Tuner.
* XXX: This list must be kept sync with dvb_usb_rtl28xxu USB IF driver.
*/
#define RTL2832_TUNER_TUA9001 0x24
@@ -45,15 +49,12 @@ struct rtl2832_platform_data {
#define RTL2832_TUNER_R828D 0x2b
u8 tuner;
- /*
-* Callbacks.
-*/
struct dvb_frontend* (*get_dvb_frontend)(struct i2c_client *);
struct i2c_adapter* (*get_i2c_adapter)(struct i2c_client *);
int (*enable_slave_ts)(struct i2c_client *);
int (*pid_filter)(struct dvb_frontend *, u8, u16, int);
int (*pid_filter_ctrl)(struct dvb_frontend *, int);
- /* Register access for SDR module */
+/* private: Register access for SDR module use only */
int (*bulk_read)(struct i2c_client *, unsigned int, void *, size_t);
int (*bulk_write)(struct i2c_client *, unsigned int, const void *,
size_t);
int (*update_bits)(struct i2c_client *, unsigned int, unsigned int,
unsigned int);
--
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
[PATCH 1/3] rtl2830: add kernel-doc comments for platform_data
Add kernel-doc comments for platform_data configuration structure.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2830.h | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2830.h
b/drivers/media/dvb-frontends/rtl2830.h
index 156edf7..0cde151 100644
--- a/drivers/media/dvb-frontends/rtl2830.h
+++ b/drivers/media/dvb-frontends/rtl2830.h
@@ -20,33 +20,26 @@
#include linux/dvb/frontend.h
+/**
+ * struct rtl2830_platform_data - Platform data for the rtl2830 driver
+ * @clk: Clock frequency (400, 1600, 2500, 2880).
+ * @spec_inv: Spectrum inversion.
+ * @vtop: AGC take-over point.
+ * @krf: AGC ratio.
+ * @agc_targ_val: AGC.
+ * @get_dvb_frontend: Get DVB frontend.
+ * @get_i2c_adapter: Get I2C adapter.
+ * @pid_filter: Set PID to PID filter.
+ * @pid_filter_ctrl: Control PID filter.
+ */
+
struct rtl2830_platform_data {
- /*
-* Clock frequency.
-* Hz
-* 400, 1600, 2500, 2880
-*/
u32 clk;
-
- /*
-* Spectrum inversion.
-*/
bool spec_inv;
-
- /*
-*/
u8 vtop;
-
- /*
-*/
u8 krf;
-
- /*
-*/
u8 agc_targ_val;
- /*
-*/
struct dvb_frontend* (*get_dvb_frontend)(struct i2c_client *);
struct i2c_adapter* (*get_i2c_adapter)(struct i2c_client *);
int (*pid_filter)(struct dvb_frontend *, u8, u16, int);
--
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
libv4l
Hello, When trying to build libv4l, it fails because I don't have the dependencies for v4l1. Is it possibe to make libv4l without having videodev.h? I only want the v4l2 parts, to which I have videodev2.h. Thanks, kpd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] [media] V4L: soc-camera: add SPI device support
From: Kassey Li kass...@nvidia.com
This adds support for spi interface sub device for
soc_camera.
Signed-off-by: Kassey Li kass...@nvidia.com
---
drivers/media/platform/soc_camera/soc_camera.c | 94
include/media/soc_camera.h |4 +
2 files changed, 98 insertions(+)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index b3db51c..b01c075 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -27,6 +27,7 @@
#include linux/pm_runtime.h
#include linux/regulator/consumer.h
#include linux/slab.h
+#include linux/spi/spi.h
#include linux/vmalloc.h
#include media/soc_camera.h
@@ -1430,6 +1431,91 @@ static void soc_camera_i2c_free(struct soc_camera_device
*icd)
icd-clk = NULL;
}
+static int soc_camera_spi_init(struct soc_camera_device *icd,
+ struct soc_camera_desc *sdesc)
+{
+ struct soc_camera_subdev_desc *ssdd;
+ struct spi_device *spi;
+ struct soc_camera_host *ici;
+ struct soc_camera_host_desc *shd = sdesc-host_desc;
+ struct spi_master *spi_master;
+ struct v4l2_subdev *subdev;
+ char clk_name[V4L2_SUBDEV_NAME_SIZE];
+ int ret;
+
+ /* First find out how we link the main client */
+ if (icd-sasc) {
+ /* Async non-OF probing handled by the subdevice list */
+ return -EPROBE_DEFER;
+ }
+
+ ici = to_soc_camera_host(icd-parent);
+ spi_master = spi_busnum_to_master(shd-spi_bus_id);
+ if (!spi_master) {
+ dev_err(icd-pdev, Cannot get SPI master #%d. No driver?\n,
+ shd-spi_bus_id);
+ return -ENODEV;
+ }
+
+ ssdd = kmemdup(sdesc-subdev_desc, sizeof(*ssdd), GFP_KERNEL);
+ if (!ssdd)
+ return -ENOMEM;
+ /*
+* In synchronous case we request regulators ourselves in
+* soc_camera_pdrv_probe(), make sure the subdevice driver doesn't try
+* to allocate them again.
+*/
+ ssdd-sd_pdata.num_regulators = 0;
+ ssdd-sd_pdata.regulators = NULL;
+ shd-board_info_spi-platform_data = ssdd;
+
+ snprintf(clk_name, sizeof(clk_name), %d,
+shd-spi_bus_id);
+
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
icd);
+ if (IS_ERR(icd-clk)) {
+ ret = PTR_ERR(icd-clk);
+ goto eclkreg;
+ }
+
+ subdev = v4l2_spi_new_subdev(ici-v4l2_dev, spi_master,
+ shd-board_info_spi);
+ if (!subdev) {
+ ret = -ENODEV;
+ goto espind;
+ }
+
+ spi = v4l2_get_subdevdata(subdev);
+
+ icd-control = spi-dev;
+
+ return 0;
+espind:
+ v4l2_clk_unregister(icd-clk);
+ icd-clk = NULL;
+eclkreg:
+ kfree(ssdd);
+ return ret;
+}
+
+static void soc_camera_spi_free(struct soc_camera_device *icd)
+{
+ struct spi_device *spi =
+ to_spi_device(to_soc_camera_control(icd));
+ struct soc_camera_subdev_desc *ssdd;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+
+ icd-control = NULL;
+ if (icd-sasc)
+ return;
+ ssdd = spi-dev.platform_data;
+ v4l2_device_unregister_subdev(sd);
+ spi_unregister_device(spi);
+ kfree(ssdd);
+ v4l2_clk_unregister(icd-clk);
+ icd-clk = NULL;
+}
+
/*
* V4L2 asynchronous notifier callbacks. They are all called under a v4l2-async
* internal global mutex, therefore cannot race against other asynchronous
@@ -1762,6 +1848,10 @@ static int soc_camera_probe(struct soc_camera_host *ici,
ret = soc_camera_i2c_init(icd, sdesc);
if (ret 0 ret != -EPROBE_DEFER)
goto eadd;
+ } else if (shd-board_info_spi) {
+ ret = soc_camera_spi_init(icd, sdesc);
+ if (ret 0)
+ goto eadd;
} else if (!shd-add_device || !shd-del_device) {
ret = -EINVAL;
goto eadd;
@@ -1803,6 +1893,8 @@ static int soc_camera_probe(struct soc_camera_host *ici,
efinish:
if (shd-board_info) {
soc_camera_i2c_free(icd);
+ } else if (shd-board_info_spi) {
+ soc_camera_spi_free(icd);
} else {
shd-del_device(icd);
module_put(control-driver-owner);
@@ -1843,6 +1935,8 @@ static int soc_camera_remove(struct soc_camera_device
*icd)
if (sdesc-host_desc.board_info) {
soc_camera_i2c_free(icd);
+ } else if (sdesc-host_desc.board_info_spi) {
+ soc_camera_spi_free(icd);
} else {
struct device *dev = to_soc_camera_control(icd);
struct device_driver *drv = dev ? dev-driver : NULL;
diff --git a/include/media/soc_camera.h
