cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Mar 28 05:00:10 CEST 2018 media-tree git hash:6ccd228e0cfce2a4f44558422d25c60fcb1a6710 media_build git hash: 40eb338395af58c910ebd1985334e259a211d2b3 v4l-utils git hash: 098e402950fd45b5a572cccfe1d103661d418417 gcc version:i686-linux-gcc (GCC) 7.3.0 sparse version: v0.5.0-3994-g45eb2282 smatch version: v0.5.0-3994-g45eb2282 host hardware: x86_64 host os:4.14.0-3-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-blackfin-bf561: 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.36.4-i686: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.101-i686: WARNINGS linux-3.0.101-x86_64: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.100-i686: WARNINGS linux-3.2.100-x86_64: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.113-i686: WARNINGS linux-3.4.113-x86_64: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.10-i686: WARNINGS linux-3.7.10-x86_64: WARNINGS linux-3.8.13-i686: WARNINGS linux-3.8.13-x86_64: WARNINGS linux-3.9.11-i686: WARNINGS linux-3.9.11-x86_64: WARNINGS linux-3.10.108-i686: WARNINGS linux-3.10.108-x86_64: WARNINGS linux-3.11.10-i686: WARNINGS linux-3.11.10-x86_64: WARNINGS linux-3.12.74-i686: WARNINGS linux-3.12.74-x86_64: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.79-i686: WARNINGS linux-3.14.79-x86_64: WARNINGS linux-3.15.10-i686: WARNINGS linux-3.15.10-x86_64: WARNINGS linux-3.16.55-i686: WARNINGS linux-3.16.55-x86_64: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.100-i686: WARNINGS linux-3.18.100-x86_64: WARNINGS linux-3.19.8-i686: WARNINGS linux-3.19.8-x86_64: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.50-i686: WARNINGS linux-4.1.50-x86_64: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.99-i686: OK linux-4.4.99-x86_64: OK linux-4.5.7-i686: WARNINGS linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: WARNINGS linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.87-i686: WARNINGS linux-4.9.87-x86_64: WARNINGS linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.27-i686: OK linux-4.14.27-x86_64: OK linux-4.15.10-i686: OK linux-4.15.10-x86_64: OK linux-4.16-rc5-i686: OK linux-4.16-rc5-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS smatch: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
RE: [PATCH v4 00/12] Intel IPU3 ImgU patchset
Adding Tomasz... > -Original Message- > From: Mani, Rajmohan > Sent: Tuesday, February 20, 2018 5:56 PM > To: 'Mauro Carvalho Chehab' > Cc: Zhi, Yong ; 'linux-media@vger.kernel.org' me...@vger.kernel.org>; 'sakari.ai...@linux.intel.com' > ; Zheng, Jian Xu ; > Toivonen, Tuukka ; Hu, Jerry W > ; 'a...@arndb.de' ; 'h...@lst.de' > ; 'robin.mur...@arm.com' ; > 'io...@lists.linux-foundation.org' > Subject: RE: [PATCH v4 00/12] Intel IPU3 ImgU patchset > > Hi Mauro, > > > > > Subject: Re: [PATCH v4 00/12] Intel IPU3 ImgU patchset > > > > > > > > Hi, > > > > > > > > Em Fri, 17 Nov 2017 02:58:56 + "Mani, Rajmohan" > > > > escreveu: > > > > > > > > > Here is an update on the IPU3 documentation that we are > > > > > currently working > > > > on. > > > > > > > > > > Image processing in IPU3 relies on the following. > > > > > > > > > > 1) HW configuration to enable ISP and > > > > > 2) setting customer specific 3A Tuning / Algorithm Parameters to > > > > > achieve > > > > desired image quality. > > > > > > > > > > We intend to provide documentation on ImgU driver programming > > > > > interface > > > > to help users of this driver to configure and enable ISP HW to > > > > meet their needs. This documentation will include details on > > > > complete > > > > V4L2 Kernel driver interface and IO-Control parameters, except for > > > > the ISP internal algorithm and its parameters (which is Intel > > > > proprietary > IP). > > > > > > > > Sakari asked me to take a look on this thread, specifically on > > > > this email. I took a look on the other e-mails from this thread > > > > that are discussing about this IP block. > > > > > > > > I understand that Intel wants to keep their internal 3A algorithm > > > > protected, just like other vendors protect their own algos. It was > > > > never a requirement to open whatever algorithm are used inside a > > > > hardware (or firmware). The only requirement is that firmwares > > > > should be licensed with redistribution permission, ideally merged > > > > at linux-firmware > > > git tree. > > > > > > > > Yet, what I don't understand is why Intel also wants to also > > > > protect the interface for such 3A hardware/firmware algorithm. The > > > > parameters that are passed from an userspace application to Intel > > > > ISP logic doesn't contain the algorithm itself. What's the issue > > > > of documenting the meaning of each parameter? > > > > > > > > > > Thanks for looking into this. > > > > > > To achieve improved image quality using IPU3, 3A (Auto White > > > balance, Auto Focus and Auto Exposure) Tuning parameters specific to > > > a given camera sensor module, are converted to Intel ISP algorithm > > > parameters in user space camera HAL using AIC (Automatic ISP > Configuration) library. > > > > > > As a unique design of Intel ISP, it exposes very detailed algorithm > > > parameters (~ 1 parameters) to configure ISP's image processing > > > algorithm per each image fame in runtime. Typical Camera SW > > > developers (including those at > > > Intel) are not expected to fully understand and directly set these > > > parameters to configure the ISP algorithm blocks. Due to the above, > > > a user space AIC library (in binary form) is provided to generate > > > ISP Algorithm specific parameters, for a given set of 3A tuning > > > parameters. It significantly reduces the efforts of SW development > > > in ISP HW > > configuration. > > > > > > On the other hand, the ISP algorithm details could be deduced > > > readily through these detailed parameters by other ISP experts outside > Intel. > > > This is the reason that we want to keep these parameter definitions > > > as Intel > > proprietary IP. > > > > > > We are fully aware of your concerns on how to enable open source > > > developers to use Intel ISP through up-streamed Kernel Driver. > > > Internally, we are working on the license for this AIC library > > > release now (as Hans said NDA license is not acceptable). We believe > > > this will be more efficient way to help open source developers. > > > > > > This AIC library release would be a binary-only release. This AIC > > > library does not use any kernel uAPIs directly. The user space > > > Camera HAL that uses kernel uAPIs is available at > > > https://chromium.googlesource.com/chromiumos/platform/arc- > > > camera/+/master > > > > > The AIC library (in binary form) is available here. > https://storage.googleapis.com/chromeos-localmirror/distfiles/intel-3a-libs- > bin-2017.09.27.tbz2 > > Licensing information can be found in ./LICENSE.intel_3a_library file after > unzipping the tar file. > > > > > Just pinging to know your thoughts on this. > > > > Thanks > > Raj
[PATCH] media: i2c: wm9090: replace codec to component
From: Kuninori Morimoto
Now we can replace Codec to Component. Let's do it.
Note:
xxx_codec_xxx() -> xxx_component_xxx()
.idle_bias_off = 0 -> .idle_bias_on = 1
.ignore_pmdown_time = 0 -> .use_pmdown_time = 1
- -> .endianness = 1
- -> .non_legacy_dai_naming = 1
Signed-off-by: Kuninori Morimoto
---
Hi Mark, Tim, Mauro
ALSA SoC had replaced codec to component, thus, we can't use it anymore.
This patch fixes it. But, I don't know who/how can handle it.
drivers/media/i2c/tda1997x.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
index 3021913..5c5de3e 100644
--- a/drivers/media/i2c/tda1997x.c
+++ b/drivers/media/i2c/tda1997x.c
@@ -2444,7 +2444,7 @@ static int tda1997x_pcm_startup(struct snd_pcm_substream
*substream,
struct snd_soc_dai *dai)
{
struct tda1997x_state *state = snd_soc_dai_get_drvdata(dai);
- struct snd_soc_codec *codec = dai->codec;
+ struct snd_soc_component *component = dai->component;
struct snd_pcm_runtime *rtd = substream->runtime;
int rate, err;
@@ -2452,11 +2452,11 @@ static int tda1997x_pcm_startup(struct
snd_pcm_substream *substream,
err = snd_pcm_hw_constraint_minmax(rtd, SNDRV_PCM_HW_PARAM_RATE,
rate, rate);
if (err < 0) {
- dev_err(codec->dev, "failed to constrain samplerate to %dHz\n",
+ dev_err(component->dev, "failed to constrain samplerate to
%dHz\n",
rate);
return err;
}
- dev_info(codec->dev, "set samplerate constraint to %dHz\n", rate);
+ dev_info(component->dev, "set samplerate constraint to %dHz\n", rate);
return 0;
}
@@ -2479,20 +2479,23 @@ static int tda1997x_pcm_startup(struct
snd_pcm_substream *substream,
.ops = &tda1997x_dai_ops,
};
-static int tda1997x_codec_probe(struct snd_soc_codec *codec)
+static int tda1997x_codec_probe(struct snd_soc_component *component)
{
return 0;
}
-static int tda1997x_codec_remove(struct snd_soc_codec *codec)
+static int tda1997x_codec_remove(struct snd_soc_component *component)
{
return 0;
}
-static struct snd_soc_codec_driver tda1997x_codec_driver = {
+static struct snd_soc_component_driver tda1997x_codec_driver = {
.probe = tda1997x_codec_probe,
.remove = tda1997x_codec_remove,
- .reg_word_size = sizeof(u16),
+ .idle_bias_on = 1,
+ .use_pmdown_time= 1,
+ .endianness = 1,
+ .non_legacy_dai_naming = 1,
};
static int tda1997x_probe(struct i2c_client *client,
@@ -2737,7 +2740,7 @@ static int tda1997x_probe(struct i2c_client *client,
else
formats = SNDRV_PCM_FMTBIT_S16_LE;
tda1997x_audio_dai.capture.formats = formats;
- ret = snd_soc_register_codec(&state->client->dev,
+ ret = devm_snd_soc_register_component(&state->client->dev,
&tda1997x_codec_driver,
&tda1997x_audio_dai, 1);
if (ret) {
@@ -2782,7 +2785,6 @@ static int tda1997x_remove(struct i2c_client *client)
struct tda1997x_platform_data *pdata = &state->pdata;
if (pdata->audout_format) {
- snd_soc_unregister_codec(&client->dev);
mutex_destroy(&state->audio_lock);
}
--
1.9.1
Re: [PATCH v3 1/5] dvb-frontends/dvb-pll: add i2c driver support
On 03/26/2018 09:06 PM, tsk...@gmail.com wrote:
From: Akihiro Tsukada
registers the module as an i2c driver,
but keeps dvb_pll_attach() untouched for compatibility.
Signed-off-by: Akihiro Tsukada
---
drivers/media/dvb-frontends/dvb-pll.c | 49 +++
drivers/media/dvb-frontends/dvb-pll.h | 6 +
2 files changed, 55 insertions(+)
diff --git a/drivers/media/dvb-frontends/dvb-pll.c
b/drivers/media/dvb-frontends/dvb-pll.c
index 5553b89b804..614a5ea3b00 100644
--- a/drivers/media/dvb-frontends/dvb-pll.c
+++ b/drivers/media/dvb-frontends/dvb-pll.c
@@ -827,6 +827,55 @@ struct dvb_frontend *dvb_pll_attach(struct dvb_frontend
*fe, int pll_addr,
}
EXPORT_SYMBOL(dvb_pll_attach);
+
+static int
+dvb_pll_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ struct dvb_pll_config *cfg;
+ struct dvb_frontend *fe;
+ unsigned int desc_id;
+
+ cfg = client->dev.platform_data;
+ fe = cfg->fe;
+ i2c_set_clientdata(client, fe);
+ desc_id = cfg->desc_id;
+
+ if (!dvb_pll_attach(fe, client->addr, client->adapter, desc_id))
+ return -ENOMEM;
+
+ dev_info(&client->dev, "DVB Simple Tuner attached.\n");
+ return 0;
+}
+
+static int dvb_pll_remove(struct i2c_client *client)
+{
+ struct dvb_frontend *fe;
+
+ fe = i2c_get_clientdata(client);
+ dvb_pll_release(fe);
+ return 0;
+}
+
+
+static const struct i2c_device_id dvb_pll_id[] = {
+ {"dvb_pll", 0},
+ {}
+};
+
+
+MODULE_DEVICE_TABLE(i2c, dvb_pll_id);
+
+static struct i2c_driver dvb_pll_driver = {
+ .driver = {
+ .name = "dvb_pll",
+ },
+ .probe= dvb_pll_probe,
+ .remove = dvb_pll_remove,
+ .id_table = dvb_pll_id,
+};
+
+module_i2c_driver(dvb_pll_driver);
+
MODULE_DESCRIPTION("dvb pll library");
MODULE_AUTHOR("Gerd Knorr");
MODULE_LICENSE("GPL");
diff --git a/drivers/media/dvb-frontends/dvb-pll.h
b/drivers/media/dvb-frontends/dvb-pll.h
index ca885e71d2f..15bda0d0c15 100644
--- a/drivers/media/dvb-frontends/dvb-pll.h
+++ b/drivers/media/dvb-frontends/dvb-pll.h
@@ -30,6 +30,12 @@
#define DVB_PLL_TDEE418
#define DVB_PLL_THOMSON_DTT7520X 19
+struct dvb_pll_config {
+ struct dvb_frontend *fe;
+
+ unsigned int desc_id;
+};
+
#if IS_REACHABLE(CONFIG_DVB_PLL)
/**
* Attach a dvb-pll to the supplied frontend structure.
Hello
Idea is correct, but I would use pll chip names for passing correct pll
type for driver - that field is just for that.
Like that:
static const struct i2c_device_id dvb_pll_id[] = {
{"PLL-NAME1", 0},
{"PLL-NAME2", 1},
{"PLL-NAME3", 2},
{}
};
See si2157 for example.
regards
Antti
--
http://palosaari.fi/
Re: [PATCH v4] dvb-usb/friio, dvb-usb-v2/gl861: decompose friio and merge with gl861
On 03/27/2018 08:47 PM, tsk...@gmail.com wrote: From: Akihiro Tsukada Friio device contains "gl861" bridge and "tc90522" demod, for which the separate drivers are already in the kernel. But friio driver was monolithic and did not use them, practically copying those features. This patch decomposes friio driver into sub drivers and re-uses existing ones, thus reduces some code. It adds some features to gl861, to support the friio-specific init/config of the devices and implement i2c communications to the tuner via demod with USB vendor requests. You should implement i2c adapter to demod driver and not add such glue to that USB-bridge. I mean that "relayed" stuff, i2c communication to tuner via demod. I2C-mux may not work I think as there is no gate-style multiplexing so you probably need plain i2c adapter. There is few examples already on some demod drivers. regards Antti -- http://palosaari.fi/
HI
-- Greeting, once again is me Lucy Boston this is twice am contacting you please is very urgent respond to me for more details through my. Email: dr.lucybos...@gmail.com
Re: [PATCH] dma-buf: use parameter structure for dma_buf_attach
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc7 next-20180327]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/dma-buf-use-parameter-structure-for-dma_buf_attach/20180326-044631
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/staging/media/tegra-vde/tegra-vde.c: In function
'tegra_vde_attach_dmabuf':
>> drivers/staging/media/tegra-vde/tegra-vde.c:534:13: error: 'dmabuf'
>> undeclared (first use in this function)
.dmabuf = dmabuf
^~
drivers/staging/media/tegra-vde/tegra-vde.c:534:13: note: each undeclared
identifier is reported only once for each function it appears in
vim +/dmabuf +534 drivers/staging/media/tegra-vde/tegra-vde.c
521
522 static int tegra_vde_attach_dmabuf(struct device *dev,
523 int fd,
524 unsigned long offset,
525 unsigned int min_size,
526 struct dma_buf_attachment **a,
527 dma_addr_t *addr,
528 struct sg_table **s,
529 size_t *size,
530 enum dma_data_direction dma_dir)
531 {
532 struct dma_buf_attach_info attach_info = {
533 .dev = dev,
> 534 .dmabuf = dmabuf
535 };
536 struct dma_buf_attachment *attachment;
537 struct dma_buf *dmabuf;
538 struct sg_table *sgt;
539 int err;
540
541 dmabuf = dma_buf_get(fd);
542 if (IS_ERR(dmabuf)) {
543 dev_err(dev, "Invalid dmabuf FD\n");
544 return PTR_ERR(dmabuf);
545 }
546
547 if ((u64)offset + min_size > dmabuf->size) {
548 dev_err(dev, "Too small dmabuf size %zu @0x%lX, "
549 "should be at least %d\n",
550 dmabuf->size, offset, min_size);
551 return -EINVAL;
552 }
553
554 attachment = dma_buf_attach(&attach_info);
555 if (IS_ERR(attachment)) {
556 dev_err(dev, "Failed to attach dmabuf\n");
557 err = PTR_ERR(attachment);
558 goto err_put;
559 }
560
561 sgt = dma_buf_map_attachment(attachment, dma_dir);
562 if (IS_ERR(sgt)) {
563 dev_err(dev, "Failed to get dmabufs sg_table\n");
564 err = PTR_ERR(sgt);
565 goto err_detach;
566 }
567
568 if (sgt->nents != 1) {
569 dev_err(dev, "Sparse DMA region is unsupported\n");
570 err = -EINVAL;
571 goto err_unmap;
572 }
573
574 *addr = sg_dma_address(sgt->sgl) + offset;
575 *a = attachment;
576 *s = sgt;
577
578 if (size)
579 *size = dmabuf->size - offset;
580
581 return 0;
582
583 err_unmap:
584 dma_buf_unmap_attachment(attachment, sgt, dma_dir);
585 err_detach:
586 dma_buf_detach(dmabuf, attachment);
587 err_put:
588 dma_buf_put(dmabuf);
589
590 return err;
591 }
592
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Industrial routers with high?performance-price ratio and multiple functions
Dear Sir or Madam, If you're on the market for industrial routers, It will be glad to tell you that we can meet all of your requirements . Our company name is Xiamen Ursalink Technology Co,We are the manufacturer specializing on designing and producing M2M/IoT hardware and solutions. The features of our products£º 1. High-availability LTE/WCDMA/GSM connection 2. Automated fail-over between Ethernet and cellular (dual SIMs). 3. IPsec, OpenVPN, DMVPN, L2TP, GRE, PPTP for safety communication. 4. Ultra-reliable and secure data transmission via Gigabit Ethernet ports. 5. Fully integrated into Microsoft Auzure IoT eco-system, easily to be build an IoT solution. 6. Python & Ursalink SDK (Python 2.7/C) for secondary development. 7. Free 3-year warranty 8. No additional license fee (All-in-one system) 9. It can work as Modbus Master to send alerts by SMS. 10. It support TCP2COM protocol to integrate with SCADA system. ... ... Such a high performance-price ratio, with multiple functions, and high security router is your best choice,isn¡¯t it? To get more information£¬you can click here or visit www.ursalink.com . More details will be available on receipt of your reply.
[PATCH v4] dvb-usb/friio, dvb-usb-v2/gl861: decompose friio and merge with gl861
From: Akihiro Tsukada
Friio device contains "gl861" bridge and "tc90522" demod,
for which the separate drivers are already in the kernel.
But friio driver was monolithic and did not use them,
practically copying those features.
This patch decomposes friio driver into sub drivers and
re-uses existing ones, thus reduces some code.
It adds some features to gl861,
to support the friio-specific init/config of the devices
and implement i2c communications to the tuner via demod
with USB vendor requests.
Signed-off-by: Akihiro Tsukada
---
Changes since v3:
- make dvb_usb_device_properties static
Changes since v2:
(patch #27928, dvb-usb-friio: split and merge into dvb-usbv2-gl861)
- used the new i2c binding helpers instead of my own one
- merged gl861-friio.c with gl861.c
drivers/media/usb/dvb-usb-v2/Kconfig | 5 +-
drivers/media/usb/dvb-usb-v2/gl861.c | 468 ++-
drivers/media/usb/dvb-usb-v2/gl861.h | 1 +
drivers/media/usb/dvb-usb/Kconfig| 6 -
drivers/media/usb/dvb-usb/Makefile | 3 -
drivers/media/usb/dvb-usb/friio-fe.c | 441 -
drivers/media/usb/dvb-usb/friio.c| 522 ---
drivers/media/usb/dvb-usb/friio.h| 99 ---
8 files changed, 465 insertions(+), 1080 deletions(-)
delete mode 100644 drivers/media/usb/dvb-usb/friio-fe.c
delete mode 100644 drivers/media/usb/dvb-usb/friio.c
delete mode 100644 drivers/media/usb/dvb-usb/friio.h
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 0e4944b2b0f..e0a1f377295 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -95,10 +95,13 @@ config DVB_USB_GL861
tristate "Genesys Logic GL861 USB2.0 support"
depends on DVB_USB_V2
select DVB_ZL10353 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
help
Say Y here to support the MSI Megasky 580 (55801) DVB-T USB2.0
- receiver with USB ID 0db0:5581.
+ receiver with USB ID 0db0:5581, Friio White ISDB-T receiver
+ with USB ID 0x7a69:0001.
config DVB_USB_LME2510
tristate "LME DM04/QQBOX DVB-S USB2.0 support"
diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c
b/drivers/media/usb/dvb-usb-v2/gl861.c
index b1b09c54786..ef644117f84 100644
--- a/drivers/media/usb/dvb-usb-v2/gl861.c
+++ b/drivers/media/usb/dvb-usb-v2/gl861.c
@@ -10,6 +10,8 @@
#include "zl10353.h"
#include "qt1010.h"
+#include "tc90522.h"
+#include "dvb-pll.h"
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -49,6 +51,80 @@ static int gl861_i2c_msg(struct dvb_usb_device *d, u8 addr,
value, index, rbuf, rlen, 2000);
}
+/* Friio specific I2C read/write */
+/* special USB request is used in Friio's init/config */
+static int
+gl861_i2c_rawwrite(struct dvb_usb_device *d, u8 addr, u8 *wbuf, u16 wlen)
+{
+ u8 *buf;
+ int ret;
+
+ buf = kmalloc(wlen, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ usleep_range(1000, 2000); /* avoid I2C errors */
+ memcpy(buf, wbuf, wlen);
+ ret = usb_control_msg(d->udev, usb_sndctrlpipe(d->udev, 0),
+GL861_REQ_I2C_RAW, GL861_WRITE,
+addr << (8 + 1), 0x0100, buf, wlen, 2000);
+ kfree(buf);
+ return ret;
+}
+
+/*
+ * In Friio,
+ * I2C commnucations to the tuner are relay'ed via the demod (via the bridge),
+ * so its encapsulation to USB message is different from the one to the demod.
+ */
+static int
+gl861_i2c_rawread(struct dvb_usb_device *d, u8 addr, u8 *rbuf, u16 rlen)
+{
+ u8 *buf;
+ int ret;
+
+ buf = kmalloc(rlen, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ usleep_range(1000, 2000); /* avoid I2C errors */
+
+ ret = usb_control_msg(d->udev, usb_rcvctrlpipe(d->udev, 0),
+GL861_REQ_I2C_READ, GL861_READ,
+addr << (8 + 1), 0x0100, buf, rlen, 2000);
+ if (ret > 0 && rbuf)
+ memcpy(rbuf, buf, rlen);
+ kfree(buf);
+
+ return ret;
+}
+
+static int
+gl861_i2c_relay_write(struct dvb_usb_device *d, struct i2c_msg *msg)
+{
+ u8 *buf;
+ int ret;
+
+ if (msg->flags & I2C_M_RD)
+ return -EINVAL;
+ if (msg->len < 2)
+ return -EINVAL;
+
+ buf = kmalloc(msg->len - 1, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+ memcpy(buf, msg->buf + 1, msg->len - 1);
+
+ usleep_range(1000, 2000); /* avoid I2C errors */
+
+ ret = usb_control_msg(d->udev, usb_sndctrlpipe(d->udev, 0),
+GL861_REQ_I2C_RAW, GL861_WRITE,
+msg->addr << (8 + 1), msg->buf[0],
+buf
[PATCH] media: rc: report receiver and transmitter type on device register
On the raspberry pi, we might have two lirc devices; one for sending and
one for receiving. This change makes it much more apparent which one
is which.
Signed-off-by: Sean Young
---
Documentation/media/uapi/rc/lirc-dev-intro.rst | 2 +-
drivers/media/rc/lirc_dev.c| 22 --
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index 698e4f80270e..11516c8bff62 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -18,7 +18,7 @@ Example dmesg output upon a driver registering w/LIRC:
.. code-block:: none
$ dmesg |grep lirc_dev
-rc rc0: lirc_dev: driver mceusb registered at minor = 0
+rc rc0: lirc_dev: driver mceusb registered at minor = 0, raw IR receiver,
raw IR transmitter
What you should see for a chardev:
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 19660f9757e1..cc58ed78462f 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -742,6 +742,7 @@ static void lirc_release_device(struct device *ld)
int ir_lirc_register(struct rc_dev *dev)
{
+ const char *rx_type, *tx_type;
int err, minor;
minor = ida_simple_get(&lirc_ida, 0, RC_DEV_MAX, GFP_KERNEL);
@@ -766,8 +767,25 @@ int ir_lirc_register(struct rc_dev *dev)
get_device(&dev->dev);
- dev_info(&dev->dev, "lirc_dev: driver %s registered at minor = %d",
-dev->driver_name, minor);
+ switch (dev->driver_type) {
+ case RC_DRIVER_SCANCODE:
+ rx_type = "scancode";
+ break;
+ case RC_DRIVER_IR_RAW:
+ rx_type = "raw IR";
+ break;
+ default:
+ rx_type = "no";
+ break;
+ }
+
+ if (dev->tx_ir)
+ tx_type = "raw IR";
+ else
+ tx_type = "no";
+
+ dev_info(&dev->dev, "lirc_dev: driver %s registered at minor = %d, %s
receiver, %s transmitter",
+dev->driver_name, minor, rx_type, tx_type);
return 0;
--
2.14.3
[PATCH 2/4] dvb/pci/pt3: use SPDX License Identifier
From: Akihiro Tsukada Signed-off-by: Akihiro Tsukada --- drivers/media/pci/pt3/pt3.c | 11 +-- drivers/media/pci/pt3/pt3.h | 11 +-- drivers/media/pci/pt3/pt3_dma.c | 11 +-- drivers/media/pci/pt3/pt3_i2c.c | 11 +-- 4 files changed, 4 insertions(+), 40 deletions(-) diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c index b2d9fb976c9..a45cf06ae4f 100644 --- a/drivers/media/pci/pt3/pt3.c +++ b/drivers/media/pci/pt3/pt3.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Earthsoft PT3 driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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 diff --git a/drivers/media/pci/pt3/pt3.h b/drivers/media/pci/pt3/pt3.h index fbe8d9b847b..495891a4ee1 100644 --- a/drivers/media/pci/pt3/pt3.h +++ b/drivers/media/pci/pt3/pt3.h @@ -1,17 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Earthsoft PT3 driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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. */ #ifndef PT3_H diff --git a/drivers/media/pci/pt3/pt3_dma.c b/drivers/media/pci/pt3/pt3_dma.c index f0ce90437fa..de677b90ea5 100644 --- a/drivers/media/pci/pt3/pt3_dma.c +++ b/drivers/media/pci/pt3/pt3_dma.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Earthsoft PT3 driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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 #include diff --git a/drivers/media/pci/pt3/pt3_i2c.c b/drivers/media/pci/pt3/pt3_i2c.c index b66138c7b36..b02be789a8c 100644 --- a/drivers/media/pci/pt3/pt3_i2c.c +++ b/drivers/media/pci/pt3/pt3_i2c.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Earthsoft PT3 driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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 #include -- 2.16.3
[PATCH 1/4] dvb-frontends/tc90522: use SPDX License Identifier
From: Akihiro Tsukada Signed-off-by: Akihiro Tsukada --- drivers/media/dvb-frontends/tc90522.c | 11 +-- drivers/media/dvb-frontends/tc90522.h | 11 +-- 2 files changed, 2 insertions(+), 20 deletions(-) diff --git a/drivers/media/dvb-frontends/tc90522.c b/drivers/media/dvb-frontends/tc90522.c index 04fb4922332..7abf6b0916e 100644 --- a/drivers/media/dvb-frontends/tc90522.c +++ b/drivers/media/dvb-frontends/tc90522.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Toshiba TC90522 Demodulator * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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. */ /* diff --git a/drivers/media/dvb-frontends/tc90522.h b/drivers/media/dvb-frontends/tc90522.h index 10e585f3249..ac0e2ab5192 100644 --- a/drivers/media/dvb-frontends/tc90522.h +++ b/drivers/media/dvb-frontends/tc90522.h @@ -1,17 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Toshiba TC90522 Demodulator * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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. */ /* -- 2.16.3
[PATCH 3/4] tuners/mxl301rf: use SPDX License Identifier
From: Akihiro Tsukada Signed-off-by: Akihiro Tsukada --- drivers/media/tuners/mxl301rf.c | 11 +-- drivers/media/tuners/mxl301rf.h | 11 +-- 2 files changed, 2 insertions(+), 20 deletions(-) diff --git a/drivers/media/tuners/mxl301rf.c b/drivers/media/tuners/mxl301rf.c index 1575a5db776..57b0e4862aa 100644 --- a/drivers/media/tuners/mxl301rf.c +++ b/drivers/media/tuners/mxl301rf.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* * MaxLinear MxL301RF OFDM tuner driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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. */ /* diff --git a/drivers/media/tuners/mxl301rf.h b/drivers/media/tuners/mxl301rf.h index d32d4e8dc44..1d5bb10ba07 100644 --- a/drivers/media/tuners/mxl301rf.h +++ b/drivers/media/tuners/mxl301rf.h @@ -1,17 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * MaxLinear MxL301RF OFDM tuner driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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. */ #ifndef MXL301RF_H -- 2.16.3
[PATCH 0/4] dvb: pt3 etc.: SPDX License Identifier
From: Akihiro Tsukada use SPDX License Identifier in the drivers that I wrote initially. Akihiro Tsukada (4): dvb-frontends/tc90522: use SPDX License Identifier dvb/pci/pt3: use SPDX License Identifier tuners/mxl301rf: use SPDX License Identifier tuners/qm1d1c0042: use SPDX License Identifier drivers/media/dvb-frontends/tc90522.c | 11 +-- drivers/media/dvb-frontends/tc90522.h | 11 +-- drivers/media/pci/pt3/pt3.c | 11 +-- drivers/media/pci/pt3/pt3.h | 11 +-- drivers/media/pci/pt3/pt3_dma.c | 11 +-- drivers/media/pci/pt3/pt3_i2c.c | 11 +-- drivers/media/tuners/mxl301rf.c | 11 +-- drivers/media/tuners/mxl301rf.h | 11 +-- drivers/media/tuners/qm1d1c0042.c | 11 +-- drivers/media/tuners/qm1d1c0042.h | 11 +-- 10 files changed, 10 insertions(+), 100 deletions(-) -- 2.16.3
[PATCH 4/4] tuners/qm1d1c0042: use SPDX License Identifier
From: Akihiro Tsukada Signed-off-by: Akihiro Tsukada --- drivers/media/tuners/qm1d1c0042.c | 11 +-- drivers/media/tuners/qm1d1c0042.h | 11 +-- 2 files changed, 2 insertions(+), 20 deletions(-) diff --git a/drivers/media/tuners/qm1d1c0042.c b/drivers/media/tuners/qm1d1c0042.c index 9af2a155cfc..642a065b9a0 100644 --- a/drivers/media/tuners/qm1d1c0042.c +++ b/drivers/media/tuners/qm1d1c0042.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Sharp QM1D1C0042 8PSK tuner driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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. */ /* diff --git a/drivers/media/tuners/qm1d1c0042.h b/drivers/media/tuners/qm1d1c0042.h index 8331f8baa09..b22fa98bf56 100644 --- a/drivers/media/tuners/qm1d1c0042.h +++ b/drivers/media/tuners/qm1d1c0042.h @@ -1,17 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /* * Sharp QM1D1C0042 8PSK tuner driver * * Copyright (C) 2014 Akihiro Tsukada - * - * 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 version 2. - * - * - * 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. */ #ifndef QM1D1C0042_H -- 2.16.3
[PATCH] dvb-core/dvb_frontend: set better default for ISDB-T
From: Akihiro Tsukada
DTV_ISDBT_LAYER_ENABLED parameter should be set to "All" by default,
instead of "None", as described in the API document.
Signed-off-by: Akihiro Tsukada
---
drivers/media/dvb-core/dvb_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index a7ed16e0841..fb10ac9cdd9 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -973,7 +973,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
c->isdbt_sb_subchannel = 0;
c->isdbt_sb_segment_idx = 0;
c->isdbt_sb_segment_count = 0;
- c->isdbt_layer_enabled = 0;
+ c->isdbt_layer_enabled = 7; /* All layers (A,B,C) */
for (i = 0; i < 3; i++) {
c->layer[i].fec = FEC_AUTO;
c->layer[i].modulation = QAM_AUTO;
--
2.16.3
[PATCH v4 2/6] media: uvcvideo: Convert decode functions to use new context structure
The URB completion handlers currently reference the stream context.
Now that each URB has its own context structure, convert the decode (and
one encode) functions to utilise this context for URB management.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- fix checkpatch warning (pre-existing in code)
v3: (none)
v4:
- Rebase on top of linux-media/master (v4.16-rc4, metadata additions)
drivers/media/usb/uvc/uvc_isight.c | 6 --
drivers/media/usb/uvc/uvc_video.c | 26 ++
drivers/media/usb/uvc/uvcvideo.h | 8 +---
3 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_isight.c
b/drivers/media/usb/uvc/uvc_isight.c
index 81e6f2187bfb..39a4e4482b23 100644
--- a/drivers/media/usb/uvc/uvc_isight.c
+++ b/drivers/media/usb/uvc/uvc_isight.c
@@ -99,9 +99,11 @@ static int isight_decode(struct uvc_video_queue *queue,
struct uvc_buffer *buf,
return 0;
}
-void uvc_video_decode_isight(struct urb *urb, struct uvc_streaming *stream,
- struct uvc_buffer *buf, struct uvc_buffer *meta_buf)
+void uvc_video_decode_isight(struct uvc_urb *uvc_urb, struct uvc_buffer *buf,
+ struct uvc_buffer *meta_buf)
{
+ struct urb *urb = uvc_urb->urb;
+ struct uvc_streaming *stream = uvc_urb->stream;
int ret, i;
for (i = 0; i < urb->number_of_packets; ++i) {
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index 93048fbf4e82..0f6d488ab66b 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1237,9 +1237,11 @@ static void uvc_video_next_buffers(struct uvc_streaming
*stream,
*video_buf = uvc_queue_next_buffer(&stream->queue, *video_buf);
}
-static void uvc_video_decode_isoc(struct urb *urb, struct uvc_streaming
*stream,
+static void uvc_video_decode_isoc(struct uvc_urb *uvc_urb,
struct uvc_buffer *buf, struct uvc_buffer *meta_buf)
{
+ struct urb *urb = uvc_urb->urb;
+ struct uvc_streaming *stream = uvc_urb->stream;
u8 *mem;
int ret, i;
@@ -1284,9 +1286,11 @@ static void uvc_video_decode_isoc(struct urb *urb,
struct uvc_streaming *stream,
}
}
-static void uvc_video_decode_bulk(struct urb *urb, struct uvc_streaming
*stream,
+static void uvc_video_decode_bulk(struct uvc_urb *uvc_urb,
struct uvc_buffer *buf, struct uvc_buffer *meta_buf)
{
+ struct urb *urb = uvc_urb->urb;
+ struct uvc_streaming *stream = uvc_urb->stream;
u8 *mem;
int len, ret;
@@ -1352,9 +1356,12 @@ static void uvc_video_decode_bulk(struct urb *urb,
struct uvc_streaming *stream,
}
}
-static void uvc_video_encode_bulk(struct urb *urb, struct uvc_streaming
*stream,
+static void uvc_video_encode_bulk(struct uvc_urb *uvc_urb,
struct uvc_buffer *buf, struct uvc_buffer *meta_buf)
{
+ struct urb *urb = uvc_urb->urb;
+ struct uvc_streaming *stream = uvc_urb->stream;
+
u8 *mem = urb->transfer_buffer;
int len = stream->urb_size, ret;
@@ -1397,7 +1404,8 @@ static void uvc_video_encode_bulk(struct urb *urb, struct
uvc_streaming *stream,
static void uvc_video_complete(struct urb *urb)
{
- struct uvc_streaming *stream = urb->context;
+ struct uvc_urb *uvc_urb = urb->context;
+ struct uvc_streaming *stream = uvc_urb->stream;
struct uvc_video_queue *queue = &stream->queue;
struct uvc_video_queue *qmeta = &stream->meta.queue;
struct vb2_queue *vb2_qmeta = stream->meta.vdev.queue;
@@ -1440,7 +1448,7 @@ static void uvc_video_complete(struct urb *urb)
spin_unlock_irqrestore(&qmeta->irqlock, flags);
}
- stream->decode(urb, stream, buf, buf_meta);
+ stream->decode(uvc_urb, buf, buf_meta);
if ((ret = usb_submit_urb(urb, GFP_ATOMIC)) < 0) {
uvc_printk(KERN_ERR, "Failed to resubmit video URB (%d).\n",
@@ -1518,6 +1526,8 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
*stream,
uvc_free_urb_buffers(stream);
break;
}
+
+ uvc_urb->stream = stream;
}
if (i == UVC_URBS) {
@@ -1616,7 +1626,7 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream,
}
urb->dev = stream->dev->udev;
- urb->context = stream;
+ urb->context = uvc_urb;
urb->pipe = usb_rcvisocpipe(stream->dev->udev,
ep->desc.bEndpointAddress);
#ifndef CONFIG_DMA_NONCOHERENT
@@ -1683,8 +1693,8 @@ static int uvc_init_video_bulk(struct uvc_streaming
*stream,
return -ENOMEM;
}
- usb_fill_bulk_urb(urb, stream->dev->udev, pipe, uvc_urb->buffer,
- size, uvc
[PATCH v4 3/6] media: uvcvideo: Protect queue internals with helper
The URB completion operation obtains the current buffer by reading
directly into the queue internal interface.
Protect this queue abstraction by providing a helper
uvc_queue_get_current_buffer() which can be used by both the decode
task, and the uvc_queue_next_buffer() functions.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- Fix coding style of conditional statements
v3:
- No change
v4:
- Rebase on top of linux-media/master (v4.16-rc4, metadata additions)
drivers/media/usb/uvc/uvc_queue.c | 33 +++-
drivers/media/usb/uvc/uvc_video.c | 6 +-
drivers/media/usb/uvc/uvcvideo.h | 1 +-
3 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index fecccb5e7628..adcc4928fae4 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -429,6 +429,33 @@ void uvc_queue_cancel(struct uvc_video_queue *queue, int
disconnect)
spin_unlock_irqrestore(&queue->irqlock, flags);
}
+/*
+ * uvc_queue_get_current_buffer: Obtain the current working output buffer
+ *
+ * Buffers may span multiple packets, and even URBs, therefore the active
buffer
+ * remains on the queue until the EOF marker.
+ */
+static struct uvc_buffer *
+__uvc_queue_get_current_buffer(struct uvc_video_queue *queue)
+{
+ if (list_empty(&queue->irqqueue))
+ return NULL;
+
+ return list_first_entry(&queue->irqqueue, struct uvc_buffer, queue);
+}
+
+struct uvc_buffer *uvc_queue_get_current_buffer(struct uvc_video_queue *queue)
+{
+ struct uvc_buffer *nextbuf;
+ unsigned long flags;
+
+ spin_lock_irqsave(&queue->irqlock, flags);
+ nextbuf = __uvc_queue_get_current_buffer(queue);
+ spin_unlock_irqrestore(&queue->irqlock, flags);
+
+ return nextbuf;
+}
+
struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *buf)
{
@@ -445,11 +472,7 @@ struct uvc_buffer *uvc_queue_next_buffer(struct
uvc_video_queue *queue,
spin_lock_irqsave(&queue->irqlock, flags);
list_del(&buf->queue);
- if (!list_empty(&queue->irqqueue))
- nextbuf = list_first_entry(&queue->irqqueue, struct uvc_buffer,
- queue);
- else
- nextbuf = NULL;
+ nextbuf = __uvc_queue_get_current_buffer(queue);
spin_unlock_irqrestore(&queue->irqlock, flags);
buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index 0f6d488ab66b..7dd0dcb457f3 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1434,11 +1434,7 @@ static void uvc_video_complete(struct urb *urb)
return;
}
- spin_lock_irqsave(&queue->irqlock, flags);
- if (!list_empty(&queue->irqqueue))
- buf = list_first_entry(&queue->irqqueue, struct uvc_buffer,
- queue);
- spin_unlock_irqrestore(&queue->irqlock, flags);
+ buf = uvc_queue_get_current_buffer(queue);
if (vb2_qmeta) {
spin_lock_irqsave(&qmeta->irqlock, flags);
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index fcf3b0fa1ca9..ba792d91dad7 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -704,6 +704,7 @@ int uvc_queue_streamoff(struct uvc_video_queue *queue, enum
v4l2_buf_type type);
void uvc_queue_cancel(struct uvc_video_queue *queue, int disconnect);
struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *buf);
+struct uvc_buffer *uvc_queue_get_current_buffer(struct uvc_video_queue *queue);
int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma);
__poll_t uvc_queue_poll(struct uvc_video_queue *queue, struct file *file,
--
git-series 0.9.1
[PATCH v4 1/6] media: uvcvideo: Refactor URB descriptors
We currently store three separate arrays for each URB reference we hold.
Objectify the data needed to track URBs into a single uvc_urb structure,
allowing better object management and tracking of the URB.
All accesses to the data pointers through stream, are converted to use a
uvc_urb pointer for consistency.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
---
v2:
- Re-describe URB context structure
- Re-name uvc_urb->{urb_buffer,urb_dma}{buffer,dma}
v3:
- No change
v4:
- Rebase on top of linux-media/master (v4.16-rc4, metadata additions)
drivers/media/usb/uvc/uvc_video.c | 49 +++-
drivers/media/usb/uvc/uvcvideo.h | 18 ++--
2 files changed, 45 insertions(+), 22 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index aa0082fe5833..93048fbf4e82 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1456,14 +1456,16 @@ static void uvc_free_urb_buffers(struct uvc_streaming
*stream)
unsigned int i;
for (i = 0; i < UVC_URBS; ++i) {
- if (stream->urb_buffer[i]) {
+ struct uvc_urb *uvc_urb = &stream->uvc_urb[i];
+
+ if (uvc_urb->buffer) {
#ifndef CONFIG_DMA_NONCOHERENT
usb_free_coherent(stream->dev->udev, stream->urb_size,
- stream->urb_buffer[i], stream->urb_dma[i]);
+ uvc_urb->buffer, uvc_urb->dma);
#else
- kfree(stream->urb_buffer[i]);
+ kfree(uvc_urb->buffer);
#endif
- stream->urb_buffer[i] = NULL;
+ uvc_urb->buffer = NULL;
}
}
@@ -1501,16 +1503,18 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
*stream,
/* Retry allocations until one succeed. */
for (; npackets > 1; npackets /= 2) {
for (i = 0; i < UVC_URBS; ++i) {
+ struct uvc_urb *uvc_urb = &stream->uvc_urb[i];
+
stream->urb_size = psize * npackets;
#ifndef CONFIG_DMA_NONCOHERENT
- stream->urb_buffer[i] = usb_alloc_coherent(
+ uvc_urb->buffer = usb_alloc_coherent(
stream->dev->udev, stream->urb_size,
- gfp_flags | __GFP_NOWARN, &stream->urb_dma[i]);
+ gfp_flags | __GFP_NOWARN, &uvc_urb->dma);
#else
- stream->urb_buffer[i] =
+ uvc_urb->buffer =
kmalloc(stream->urb_size, gfp_flags | __GFP_NOWARN);
#endif
- if (!stream->urb_buffer[i]) {
+ if (!uvc_urb->buffer) {
uvc_free_urb_buffers(stream);
break;
}
@@ -1540,13 +1544,15 @@ static void uvc_uninit_video(struct uvc_streaming
*stream, int free_buffers)
uvc_video_stats_stop(stream);
for (i = 0; i < UVC_URBS; ++i) {
- urb = stream->urb[i];
+ struct uvc_urb *uvc_urb = &stream->uvc_urb[i];
+
+ urb = uvc_urb->urb;
if (urb == NULL)
continue;
usb_kill_urb(urb);
usb_free_urb(urb);
- stream->urb[i] = NULL;
+ uvc_urb->urb = NULL;
}
if (free_buffers)
@@ -1601,6 +1607,8 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream,
size = npackets * psize;
for (i = 0; i < UVC_URBS; ++i) {
+ struct uvc_urb *uvc_urb = &stream->uvc_urb[i];
+
urb = usb_alloc_urb(npackets, gfp_flags);
if (urb == NULL) {
uvc_uninit_video(stream, 1);
@@ -1613,12 +1621,12 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream,
ep->desc.bEndpointAddress);
#ifndef CONFIG_DMA_NONCOHERENT
urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
- urb->transfer_dma = stream->urb_dma[i];
+ urb->transfer_dma = uvc_urb->dma;
#else
urb->transfer_flags = URB_ISO_ASAP;
#endif
urb->interval = ep->desc.bInterval;
- urb->transfer_buffer = stream->urb_buffer[i];
+ urb->transfer_buffer = uvc_urb->buffer;
urb->complete = uvc_video_complete;
urb->number_of_packets = npackets;
urb->transfer_buffer_length = size;
@@ -1628,7 +1636,7 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream,
urb->iso_frame_desc[j].length = psize;
}
- stream->urb[i] = urb;
+ uvc_urb->urb = urb;
}
return 0;
@@ -1667,21 +1675,22 @@ static int uvc_init_video_bulk(struct uvc_streaming
*stream,
[PATCH v4 0/6] Asynchronous UVC
The Linux UVC driver has long provided adequate performance capabilities for web-cams and low data rate video devices in Linux while resolutions were low. Modern USB cameras are now capable of high data rates thanks to USB3 with 1080p, and even 4k capture resolutions supported. Cameras such as the Stereolabs ZED (bulk transfers) or the Logitech BRIO (isochronous transfers) can generate more data than an embedded ARM core is able to process on a single core, resulting in frame loss. A large part of this performance impact is from the requirement to ‘memcpy’ frames out from URB packets to destination frames. This unfortunate requirement is due to the UVC protocol allowing a variable length header, and thus it is not possible to provide the target frame buffers directly. Extra throughput is possible by moving the actual memcpy actions to a work queue, and moving the memcpy out of interrupt context thus allowing work tasks to be scheduled across multiple cores. This series has been tested on both the ZED and BRIO cameras on arm64 platforms, and with thanks to Randy Dunlap, a Dynex 1.3MP Webcam, a Sonix USB2 Camera, and a built in Toshiba Laptop camera, and with thanks to Philipp Zabel for testing on a Lite-On internal Laptop Webcam, Logitech C910 (USB2 isoc), Oculus Sensor (USB3 isoc), and Microsoft HoloLens Sensors (USB3 bulk). As far as I am aware iSight devices, and devices which use UVC to encode data (output device) have not yet been tested - but should find no ill effect (at least not until they are tested of course :D ) Tested-by: Randy Dunlap Tested-by: Philipp Zabel v2: - Fix race reported by Guennadi v3: - Fix similar race reported by Laurent - Only queue work if required (encode/isight do not queue work) - Refactor/Rename variables for clarity v4: - (Yet another) Rework of the uninitialise path. This time to hopefully clean up the shutdown races for good. use usb_poison_urb() to halt all URBs, then flush the work queue before freeing. - Rebase to latest linux-media/master Kieran Bingham (6): media: uvcvideo: Refactor URB descriptors media: uvcvideo: Convert decode functions to use new context structure media: uvcvideo: Protect queue internals with helper media: uvcvideo: queue: Simplify spin-lock usage media: uvcvideo: queue: Support asynchronous buffer handling media: uvcvideo: Move decode processing to process context drivers/media/usb/uvc/uvc_isight.c | 6 +- drivers/media/usb/uvc/uvc_queue.c | 102 + drivers/media/usb/uvc/uvc_video.c | 180 +- drivers/media/usb/uvc/uvcvideo.h | 59 -- 4 files changed, 266 insertions(+), 81 deletions(-) base-commit: a77cfdf6bd06eef0dadea2b541a7c01502b1b4f6 -- git-series 0.9.1
[PATCH v4 6/6] media: uvcvideo: Move decode processing to process context
Newer high definition cameras, and cameras with multiple lenses such as
the range of stereo-vision cameras now available have ever increasing
data rates.
The inclusion of a variable length packet header in URB packets mean
that we must memcpy the frame data out to our destination 'manually'.
This can result in data rates of up to 2 gigabits per second being
processed.
To improve efficiency, and maximise throughput, handle the URB decode
processing through a work queue to move it from interrupt context, and
allow multiple processors to work on URBs in parallel.
Signed-off-by: Kieran Bingham
---
v2:
- Lock full critical section of usb_submit_urb()
v3:
- Fix race on submitting uvc_video_decode_data_work() to work queue.
- Rename uvc_decode_op -> uvc_copy_op (Generic to encode/decode)
- Rename decodes -> copy_operations
- Don't queue work if there is no async task
- obtain copy op structure directly in uvc_video_decode_data()
- uvc_video_decode_data_work() -> uvc_video_copy_data_work()
v4:
- Provide for_each_uvc_urb()
- Simplify fix for shutdown race to flush queue before freeing URBs
- Rebase to v4.16-rc4 (linux-media/master) adjusting for metadata
conflicts.
drivers/media/usb/uvc/uvc_video.c | 107 ---
drivers/media/usb/uvc/uvcvideo.h | 28 -
2 files changed, 111 insertions(+), 24 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index 7dd0dcb457f3..a62e8caf367c 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1042,21 +1042,54 @@ static int uvc_video_decode_start(struct uvc_streaming
*stream,
return data[0];
}
-static void uvc_video_decode_data(struct uvc_streaming *stream,
+/*
+ * uvc_video_decode_data_work: Asynchronous memcpy processing
+ *
+ * Perform memcpy tasks in process context, with completion handlers
+ * to return the URB, and buffer handles.
+ */
+static void uvc_video_copy_data_work(struct work_struct *work)
+{
+ struct uvc_urb *uvc_urb = container_of(work, struct uvc_urb, work);
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < uvc_urb->async_operations; i++) {
+ struct uvc_copy_op *op = &uvc_urb->copy_operations[i];
+
+ memcpy(op->dst, op->src, op->len);
+
+ /* Release reference taken on this buffer */
+ uvc_queue_buffer_release(op->buf);
+ }
+
+ ret = usb_submit_urb(uvc_urb->urb, GFP_ATOMIC);
+ if (ret < 0)
+ uvc_printk(KERN_ERR, "Failed to resubmit video URB (%d).\n",
+ ret);
+}
+
+static void uvc_video_decode_data(struct uvc_urb *uvc_urb,
struct uvc_buffer *buf, const u8 *data, int len)
{
- unsigned int maxlen, nbytes;
- void *mem;
+ unsigned int active_op = uvc_urb->async_operations;
+ struct uvc_copy_op *decode = &uvc_urb->copy_operations[active_op];
+ unsigned int maxlen;
if (len <= 0)
return;
- /* Copy the video data to the buffer. */
maxlen = buf->length - buf->bytesused;
- mem = buf->mem + buf->bytesused;
- nbytes = min((unsigned int)len, maxlen);
- memcpy(mem, data, nbytes);
- buf->bytesused += nbytes;
+
+ /* Take a buffer reference for async work */
+ kref_get(&buf->ref);
+
+ decode->buf = buf;
+ decode->src = data;
+ decode->dst = buf->mem + buf->bytesused;
+ decode->len = min_t(unsigned int, len, maxlen);
+
+ buf->bytesused += decode->len;
/* Complete the current frame if the buffer size was exceeded. */
if (len > maxlen) {
@@ -1064,6 +1097,8 @@ static void uvc_video_decode_data(struct uvc_streaming
*stream,
buf->error = 1;
buf->state = UVC_BUF_STATE_READY;
}
+
+ uvc_urb->async_operations++;
}
static void uvc_video_decode_end(struct uvc_streaming *stream,
@@ -1272,7 +1307,7 @@ static void uvc_video_decode_isoc(struct uvc_urb *uvc_urb,
uvc_video_decode_meta(stream, meta_buf, mem, ret);
/* Decode the payload data. */
- uvc_video_decode_data(stream, buf, mem + ret,
+ uvc_video_decode_data(uvc_urb, buf, mem + ret,
urb->iso_frame_desc[i].actual_length - ret);
/* Process the header again. */
@@ -1334,9 +1369,9 @@ static void uvc_video_decode_bulk(struct uvc_urb *uvc_urb,
* sure buf is never dereferenced if NULL.
*/
- /* Process video data. */
+ /* Prepare video data for processing. */
if (!stream->bulk.skip_payload && buf != NULL)
- uvc_video_decode_data(stream, buf, mem, len);
+ uvc_video_decode_data(uvc_urb, buf, mem, len);
/* Detect the payload end by a URB smaller than the maximum size (or
* a payload size equal to the maximum) and process the header again.
@@ -1422,7 +1457,7 @@ sta
[PATCH v4 4/6] media: uvcvideo: queue: Simplify spin-lock usage
Both uvc_start_streaming(), and uvc_stop_streaming() are called from
userspace context, with interrupts enabled. As such, they do not need to
save the IRQ state, and can use spin_lock_irq() and spin_unlock_irq()
respectively.
Signed-off-by: Kieran Bingham
---
v4:
- Rebase to v4.16 (linux-media/master)
drivers/media/usb/uvc/uvc_queue.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index adcc4928fae4..698d9a5a5aae 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -169,7 +169,6 @@ static int uvc_start_streaming(struct vb2_queue *vq,
unsigned int count)
{
struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
struct uvc_streaming *stream = uvc_queue_to_stream(queue);
- unsigned long flags;
int ret;
queue->buf_used = 0;
@@ -178,9 +177,9 @@ static int uvc_start_streaming(struct vb2_queue *vq,
unsigned int count)
if (ret == 0)
return 0;
- spin_lock_irqsave(&queue->irqlock, flags);
+ spin_lock_irq(&queue->irqlock);
uvc_queue_return_buffers(queue, UVC_BUF_STATE_QUEUED);
- spin_unlock_irqrestore(&queue->irqlock, flags);
+ spin_unlock_irq(&queue->irqlock);
return ret;
}
@@ -188,14 +187,13 @@ static int uvc_start_streaming(struct vb2_queue *vq,
unsigned int count)
static void uvc_stop_streaming(struct vb2_queue *vq)
{
struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
- unsigned long flags;
if (vq->type != V4L2_BUF_TYPE_META_CAPTURE)
uvc_video_enable(uvc_queue_to_stream(queue), 0);
- spin_lock_irqsave(&queue->irqlock, flags);
+ spin_lock_irq(&queue->irqlock);
uvc_queue_return_buffers(queue, UVC_BUF_STATE_ERROR);
- spin_unlock_irqrestore(&queue->irqlock, flags);
+ spin_unlock_irq(&queue->irqlock);
}
static const struct vb2_ops uvc_queue_qops = {
--
git-series 0.9.1
[PATCH v4 5/6] media: uvcvideo: queue: Support asynchronous buffer handling
The buffer queue interface currently operates sequentially, processing
buffers after they have fully completed.
In preparation for supporting parallel tasks operating on the buffers,
we will need to support buffers being processed on multiple CPUs.
Adapt the uvc_queue_next_buffer() such that a reference count tracks the
active use of the buffer, returning the buffer to the VB2 stack at
completion.
Signed-off-by: Kieran Bingham
---
drivers/media/usb/uvc/uvc_queue.c | 61 ++--
drivers/media/usb/uvc/uvcvideo.h | 4 ++-
2 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index 698d9a5a5aae..aefb7d073c2e 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -142,6 +142,7 @@ static void uvc_buffer_queue(struct vb2_buffer *vb)
spin_lock_irqsave(&queue->irqlock, flags);
if (likely(!(queue->flags & UVC_QUEUE_DISCONNECTED))) {
+ kref_init(&buf->ref);
list_add_tail(&buf->queue, &queue->irqqueue);
} else {
/* If the device is disconnected return the buffer to userspace
@@ -454,28 +455,66 @@ struct uvc_buffer *uvc_queue_get_current_buffer(struct
uvc_video_queue *queue)
return nextbuf;
}
-struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
+/*
+ * uvc_queue_requeue: Requeue a buffer on our internal irqqueue
+ *
+ * Reuse a buffer through our internal queue without the need to 'prepare'
+ * The buffer will be returned to userspace through the uvc_buffer_queue call
if
+ * the device has been disconnected
+ */
+static void uvc_queue_requeue(struct uvc_video_queue *queue,
struct uvc_buffer *buf)
{
- struct uvc_buffer *nextbuf;
- unsigned long flags;
+ buf->error = 0;
+ buf->state = UVC_BUF_STATE_QUEUED;
+ buf->bytesused = 0;
+ vb2_set_plane_payload(&buf->buf.vb2_buf, 0, 0);
+
+ uvc_buffer_queue(&buf->buf.vb2_buf);
+}
+
+static void uvc_queue_buffer_complete(struct kref *ref)
+{
+ struct uvc_buffer *buf = container_of(ref, struct uvc_buffer, ref);
+ struct vb2_buffer *vb = &buf->buf.vb2_buf;
+ struct uvc_video_queue *queue = vb2_get_drv_priv(vb->vb2_queue);
if ((queue->flags & UVC_QUEUE_DROP_CORRUPTED) && buf->error) {
- buf->error = 0;
- buf->state = UVC_BUF_STATE_QUEUED;
- buf->bytesused = 0;
- vb2_set_plane_payload(&buf->buf.vb2_buf, 0, 0);
- return buf;
+ uvc_queue_requeue(queue, buf);
+ return;
}
+ buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
+ vb2_set_plane_payload(&buf->buf.vb2_buf, 0, buf->bytesused);
+ vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_DONE);
+}
+
+/*
+ * Release a reference on the buffer. Complete the buffer when the last
+ * reference is released
+ */
+void uvc_queue_buffer_release(struct uvc_buffer *buf)
+{
+ kref_put(&buf->ref, uvc_queue_buffer_complete);
+}
+
+/*
+ * Remove this buffer from the queue. Lifetime will persist while async actions
+ * are still running (if any), and uvc_queue_buffer_release will give the
buffer
+ * back to VB2 when all users have completed.
+ */
+struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
+ struct uvc_buffer *buf)
+{
+ struct uvc_buffer *nextbuf;
+ unsigned long flags;
+
spin_lock_irqsave(&queue->irqlock, flags);
list_del(&buf->queue);
nextbuf = __uvc_queue_get_current_buffer(queue);
spin_unlock_irqrestore(&queue->irqlock, flags);
- buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
- vb2_set_plane_payload(&buf->buf.vb2_buf, 0, buf->bytesused);
- vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_DONE);
+ uvc_queue_buffer_release(buf);
return nextbuf;
}
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index ba792d91dad7..112eed49bf50 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -404,6 +404,9 @@ struct uvc_buffer {
unsigned int bytesused;
u32 pts;
+
+ /* asynchronous buffer handling */
+ struct kref ref;
};
#define UVC_QUEUE_DISCONNECTED (1 << 0)
@@ -705,6 +708,7 @@ void uvc_queue_cancel(struct uvc_video_queue *queue, int
disconnect);
struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *buf);
struct uvc_buffer *uvc_queue_get_current_buffer(struct uvc_video_queue *queue);
+void uvc_queue_buffer_release(struct uvc_buffer *buf);
int uvc_queue_mmap(struct uvc_video_queue *queue,
struct vm_area_struct *vma);
__poll_t uvc_queue_poll(struct uvc_video_queue *queue, struct file *file,
--
git-series 0.9.1
[PATCH] dvb-frontends/tc90522: fix bit shift mistakes
From: Akihiro Tsukada
they were obviously wrong.
Signed-off-by: Akihiro Tsukada
---
drivers/media/dvb-frontends/tc90522.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/tc90522.c
b/drivers/media/dvb-frontends/tc90522.c
index 5572b39614d..04fb4922332 100644
--- a/drivers/media/dvb-frontends/tc90522.c
+++ b/drivers/media/dvb-frontends/tc90522.c
@@ -352,7 +352,7 @@ static int tc90522t_get_frontend(struct dvb_frontend *fe,
mode = 1;
ret = reg_read(state, 0xb0, val, 1);
if (ret == 0) {
- mode = (val[0] & 0xc0) >> 2;
+ mode = (val[0] & 0xc0) >> 6;
c->transmission_mode = tm_conv[mode];
c->guard_interval = (val[0] & 0x30) >> 4;
}
@@ -379,7 +379,7 @@ static int tc90522t_get_frontend(struct dvb_frontend *fe,
}
/* layer B */
- v = (val[3] & 0x03) << 1 | (val[4] & 0xc0) >> 6;
+ v = (val[3] & 0x03) << 2 | (val[4] & 0xc0) >> 6;
if (v == 0x0f)
c->layer[1].segment_count = 0;
else {
--
2.16.3
Re: FM radio (SAA7134)
Output of radio application from xawtv $ radio -f 106.60 Tuning to 106.60 MHz Invalid freq '1705625'. Current freq out of range? On Tue, Mar 27, 2018 at 1:52 PM, P G wrote: > I have tuner card, with radio tuner. > > The modules are loaded fine, no errors in dmesg, but radio is having issues. > I use radio application from xawtv, and also fm tools, but none of > them is working properly. > When i fire up radio, it tunes to 1.04MHZ, and i hear sound noise > (like when radio isn't tuned). If i tune to another frequency, let's > say 88.0Mhz, i hear the radio station sound for 1-2 seconds, and then > the tuner tunes back to 1.04Mhz. > Same applies for fm tools. I tune with command fm 88.0 on, tuner tunes > in the apropriate radio station for a few seconds and then it goes > back to noise. > > You can see it here as well: > Code: > > v4l2-ctl -d /dev/radio0 --all > > Driver Info (not using libv4l2): > Driver name : saa7134 > Card type : ASUSTeK P7131 Hybrid > Bus info : PCI::04:01.0 > Driver version: 3.13.2 > Capabilities : 0x85050015 > Video Capture > Video Overlay > VBI Capture > Tuner > Radio > Read/Write > Streaming > Device Capabilities > Device Caps : 0x0005 > Tuner > Radio > Priority: 2 > Frequency for tuner 0: 16640 (1.04 MHz) > Tuner 0: > Name : Radio > Capabilities : 62.5 Hz stereo freq-bands > Frequency range : 65.000 MHz - 108.000 MHz > Signal strength/AFC : 0%/0 > Current audio mode : stereo > Available subchannels: mono >mute (bool) : default=0 value=0 > > The frequency of the tuner is 1.04 MHz, but the range of the tuner > is between 65 and 108 as it should be. > Does anyone has any idea if is FM driver bug?
Re: [PATCH v3 3/5] dvb-usb/friio, dvb-usb-v2/gl861: decompose friio
Hi Akihiro, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.16-rc7 next-20180327] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/tskd08-gmail-com/dvb-frontends-dvb-pll-add-i2c-driver-support/20180327-194533 base: git://linuxtv.org/media_tree.git master reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/media/usb/dvb-usb-v2/gl861.c:575:34: sparse: symbol 'friio_props' >> was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[RFC PATCH] dvb-usb/friio, dvb-usb-v2/gl861: friio_props can be static
Fixes: 7d9f3a71c6fc ("dvb-usb/friio, dvb-usb-v2/gl861: decompose friio")
Signed-off-by: Fengguang Wu
---
gl861.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c
b/drivers/media/usb/dvb-usb-v2/gl861.c
index bc18ca3..ef64411 100644
--- a/drivers/media/usb/dvb-usb-v2/gl861.c
+++ b/drivers/media/usb/dvb-usb-v2/gl861.c
@@ -572,7 +572,7 @@ static struct dvb_usb_device_properties gl861_props = {
}
};
-struct dvb_usb_device_properties friio_props = {
+static struct dvb_usb_device_properties friio_props = {
.driver_name = KBUILD_MODNAME,
.owner = THIS_MODULE,
.adapter_nr = adapter_nr,
[PATCH 4/5] dvb: earth-pt1: add support for suspend/resume
From: Akihiro Tsukada
Without this patch, re-loading of the module was required after resume.
Signed-off-by: Akihiro Tsukada
---
drivers/media/pci/pt1/pt1.c | 107 +++-
1 file changed, 105 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
index 34a688952e2..1a83a624776 100644
--- a/drivers/media/pci/pt1/pt1.c
+++ b/drivers/media/pci/pt1/pt1.c
@@ -467,12 +467,18 @@ static int pt1_thread(void *data)
{
struct pt1 *pt1;
struct pt1_buffer_page *page;
+ bool was_frozen;
pt1 = data;
set_freezable();
- while (!kthread_should_stop()) {
- try_to_freeze();
+ while (!kthread_freezable_should_stop(&was_frozen)) {
+ if (was_frozen) {
+ int i;
+
+ for (i = 0; i < PT1_NR_ADAPS; i++)
+ pt1_set_stream(pt1, i, !!pt1->adaps[i]->users);
+ }
page = pt1->tables[pt1->table_index].bufs[pt1->buf_index].page;
if (!pt1_filter(pt1, page)) {
@@ -1171,6 +1177,98 @@ static void pt1_i2c_init(struct pt1 *pt1)
pt1_i2c_emit(pt1, i, 0, 0, 1, 1, 0);
}
+#ifdef CONFIG_PM_SLEEP
+
+static int pt1_suspend(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct pt1 *pt1 = pci_get_drvdata(pdev);
+
+ pt1_init_streams(pt1);
+ pt1_disable_ram(pt1);
+ pt1->power = 0;
+ pt1->reset = 1;
+ pt1_update_power(pt1);
+ return 0;
+}
+
+static int pt1_resume(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct pt1 *pt1 = pci_get_drvdata(pdev);
+ int ret;
+ int i;
+
+ pt1->power = 0;
+ pt1->reset = 1;
+ pt1_update_power(pt1);
+
+ pt1_i2c_init(pt1);
+ pt1_i2c_wait(pt1);
+
+ ret = pt1_sync(pt1);
+ if (ret < 0)
+ goto resume_err;
+
+ pt1_identify(pt1);
+
+ ret = pt1_unlock(pt1);
+ if (ret < 0)
+ goto resume_err;
+
+ ret = pt1_reset_pci(pt1);
+ if (ret < 0)
+ goto resume_err;
+
+ ret = pt1_reset_ram(pt1);
+ if (ret < 0)
+ goto resume_err;
+
+ ret = pt1_enable_ram(pt1);
+ if (ret < 0)
+ goto resume_err;
+
+ pt1_init_streams(pt1);
+
+ pt1->power = 1;
+ pt1_update_power(pt1);
+ msleep(20);
+
+ pt1->reset = 0;
+ pt1_update_power(pt1);
+ usleep_range(1000, 2000);
+
+ for (i = 0; i < PT1_NR_ADAPS; i++)
+ dvb_frontend_reinitialise(pt1->adaps[i]->fe);
+
+ pt1_init_table_count(pt1);
+ for (i = 0; i < pt1_nr_tables; i++) {
+ int j;
+
+ for (j = 0; j < PT1_NR_BUFS; j++)
+ pt1->tables[i].bufs[j].page->upackets[PT1_NR_UPACKETS-1]
+ = 0;
+ pt1_increment_table_count(pt1);
+ }
+ pt1_register_tables(pt1, pt1->tables[0].addr >> PT1_PAGE_SHIFT);
+
+ pt1->table_index = 0;
+ pt1->buf_index = 0;
+ for (i = 0; i < PT1_NR_ADAPS; i++) {
+ pt1->adaps[i]->upacket_count = 0;
+ pt1->adaps[i]->packet_count = 0;
+ pt1->adaps[i]->st_count = -1;
+ }
+
+ return 0;
+
+resume_err:
+ dev_info(&pt1->pdev->dev, "failed to resume PT1/PT2.");
+ return 0; /* resume anyway */
+}
+
+#endif /* CONFIG_PM_SLEEP */
+
static void pt1_remove(struct pci_dev *pdev)
{
struct pt1 *pt1;
@@ -1331,11 +1429,16 @@ static const struct pci_device_id pt1_id_table[] = {
};
MODULE_DEVICE_TABLE(pci, pt1_id_table);
+static SIMPLE_DEV_PM_OPS(pt1_pm_ops, pt1_suspend, pt1_resume);
+
static struct pci_driver pt1_driver = {
.name = DRIVER_NAME,
.probe = pt1_probe,
.remove = pt1_remove,
.id_table = pt1_id_table,
+#if CONFIG_PM_SLEEP
+ .driver.pm = &pt1_pm_ops,
+#endif
};
module_pci_driver(pt1_driver);
--
2.16.3
[PATCH 2/5] tuners: add new driver for Sharp qm1d1b0004 ISDB-S tuner
From: Akihiro Tsukada
The tuner is used in Earthsoft PT1/PT2 DVB boards,
and the driver was extraced from (the former) va1j5jf8007s.c of PT1.
it might contain PT1 specific configs.
Signed-off-by: Akihiro Tsukada
---
drivers/media/tuners/Kconfig | 7 +
drivers/media/tuners/Makefile | 1 +
drivers/media/tuners/qm1d1b0004.c | 264 ++
drivers/media/tuners/qm1d1b0004.h | 24
4 files changed, 296 insertions(+)
create mode 100644 drivers/media/tuners/qm1d1b0004.c
create mode 100644 drivers/media/tuners/qm1d1b0004.h
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index 6687514df97..147f3cd0bb9 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -284,4 +284,11 @@ config MEDIA_TUNER_QM1D1C0042
default m if !MEDIA_SUBDRV_AUTOSELECT
help
Sharp QM1D1C0042 trellis coded 8PSK tuner driver.
+
+config MEDIA_TUNER_QM1D1B0004
+ tristate "Sharp QM1D1B0004 tuner"
+ depends on MEDIA_SUPPORT && I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Sharp QM1D1B0004 ISDB-S tuner driver.
endmenu
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index 0ff21f1c7ee..7b4f8423501 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_MEDIA_TUNER_IT913X) += it913x.o
obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
obj-$(CONFIG_MEDIA_TUNER_QM1D1C0042) += qm1d1c0042.o
+obj-$(CONFIG_MEDIA_TUNER_QM1D1B0004) += qm1d1b0004.o
obj-$(CONFIG_MEDIA_TUNER_M88RS6000T) += m88rs6000t.o
obj-$(CONFIG_MEDIA_TUNER_TDA18250) += tda18250.o
diff --git a/drivers/media/tuners/qm1d1b0004.c
b/drivers/media/tuners/qm1d1b0004.c
new file mode 100644
index 000..9dac1b875c1
--- /dev/null
+++ b/drivers/media/tuners/qm1d1b0004.c
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sharp QM1D1B0004 satellite tuner
+ *
+ * Copyright (C) 2014 Akihiro Tsukada
+ *
+ * based on (former) drivers/media/pci/pt1/va1j5jf8007s.c.
+ */
+
+/*
+ * Note:
+ * Since the data-sheet of this tuner chip is not available,
+ * this driver lacks some tuner_ops and config options.
+ * In addition, the implementation might be dependent on the specific use
+ * in the FE module: VA1J5JF8007S and/or in the product: Earthsoft PT1/PT2.
+ */
+
+#include
+#include
+#include
+#include "qm1d1b0004.h"
+
+/*
+ * Tuner I/F (copied from the former va1j5jf8007s.c)
+ * b[0] I2C addr
+ * b[1] "0":1, BG:2, divider_quotient[7:3]:5
+ * b[2] divider_quotient[2:0]:3, divider_remainder:5
+ * b[3] "111":3, LPF[3:2]:2, TM:1, "0":1, REF:1
+ * b[4] BANDX, PSC:1, LPF[1:0]:2, DIV:1, "0":1
+ *
+ * PLL frequency step :=
+ *REF == 0 -> PLL XTL frequency(4MHz) / 8
+ *REF == 1 -> PLL XTL frequency(4MHz) / 4
+ *
+ * PreScaler :=
+ *PSC == 0 -> x32
+ *PSC == 1 -> x16
+ *
+ * divider_quotient := (frequency / PLL frequency step) / PreScaler
+ * divider_remainder := (frequency / PLL frequency step) % PreScaler
+ *
+ * LPF := LPF Frequency / 1000 / 2 - 2
+ * LPF Frequency @ baudrate=28.86Mbps = 3
+ *
+ * band (1..9)
+ * band 1 (freq < 986000) -> DIV:1, BANDX:5, PSC:1
+ * band 2 (freq < 1072000) -> DIV:1, BANDX:6, PSC:1
+ * band 3 (freq < 1154000) -> DIV:1, BANDX:7, PSC:0
+ * band 4 (freq < 1291000) -> DIV:0, BANDX:1, PSC:0
+ * band 5 (freq < 1447000) -> DIV:0, BANDX:2, PSC:0
+ * band 6 (freq < 1615000) -> DIV:0, BANDX:3, PSC:0
+ * band 7 (freq < 1791000) -> DIV:0, BANDX:4, PSC:0
+ * band 8 (freq < 1972000) -> DIV:0, BANDX:5, PSC:0
+ * band 9 (freq < 215) -> DIV:0, BANDX:6, PSC:0
+ */
+
+#define QM1D1B0004_PSC_MASK (1 << 4)
+
+#define QM1D1B0004_XTL_FREQ 4000
+#define QM1D1B0004_LPF_FALLBACK 3
+
+static const struct qm1d1b0004_config default_cfg = {
+ .lpf_freq = QM1D1B0004_CFG_LPF_DFLT,
+ .half_step = false,
+};
+
+struct qm1d1b0004_state {
+ struct qm1d1b0004_config cfg;
+ struct i2c_client *i2c;
+};
+
+
+struct qm1d1b0004_cb_map {
+ u32 frequency;
+ u8 cb;
+};
+
+static const struct qm1d1b0004_cb_map cb_maps[] = {
+ { 986000, 0xb2 },
+ { 1072000, 0xd2 },
+ { 1154000, 0xe2 },
+ { 1291000, 0x20 },
+ { 1447000, 0x40 },
+ { 1615000, 0x60 },
+ { 1791000, 0x80 },
+ { 1972000, 0xa0 },
+};
+
+static u8 lookup_cb(u32 frequency)
+{
+ int i;
+ const struct qm1d1b0004_cb_map *map;
+
+ for (i = 0; i < ARRAY_SIZE(cb_maps); i++) {
+ map = &cb_maps[i];
+ if (frequency < map->frequency)
+ return map->cb;
+ }
+ return 0xc0;
+}
+
+static int qm1d1b0004_set_params(struct dvb_frontend *fe)
+{
+ struct qm1d1b0004_state *state;
+ u32 frequency, pll, lpf_freq;
+ u16 word;
+ u8 buf[4], cb, lpf;
+ int ret;
+
+ state = fe->tuner_priv;
+ frequency = fe->dtv_property_cache.frequency;
+
+
[PATCH 1/5] dvb-frontends/dvb-pll: add tda6651 ISDB-T pll_desc
From: Akihiro Tsukada
This patch adds a PLL "description" of Philips TDA6651 for ISDB-T.
It was extracted from (the former) va1j5jf8007t.c of EarthSoft PT1,
thus the desc might include PT1 specific configs.
Signed-off-by: Akihiro Tsukada
---
drivers/media/dvb-frontends/dvb-pll.c | 23 +++
drivers/media/dvb-frontends/dvb-pll.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/media/dvb-frontends/dvb-pll.c
b/drivers/media/dvb-frontends/dvb-pll.c
index 76c091b2cb1..ba1dc3d1641 100644
--- a/drivers/media/dvb-frontends/dvb-pll.c
+++ b/drivers/media/dvb-frontends/dvb-pll.c
@@ -550,6 +550,28 @@ static const struct dvb_pll_desc dvb_pll_tua6034_friio = {
}
};
+/* Philips TDA6651 ISDB-T, used in Earthsoft PT1 */
+static const struct dvb_pll_desc dvb_pll_tda665x_earth_pt1 = {
+ .name = "Philips TDA6651 ISDB-T (EarthSoft PT1)",
+ .min= 9000,
+ .max= 77000,
+ .iffreq = 5700,
+ .initdata = (u8[]){ 5, 0x0e, 0x7f, 0xc1, 0x80, 0x80 },
+ .count = 10,
+ .entries = {
+ { 14000, 142857, 0xc1, 0x81 },
+ { 17000, 142857, 0xc1, 0xa1 },
+ { 22000, 142857, 0xc1, 0x62 },
+ { 33000, 142857, 0xc1, 0xa2 },
+ { 40200, 142857, 0xc1, 0xe2 },
+ { 45000, 142857, 0xc1, 0x64 },
+ { 55000, 142857, 0xc1, 0x84 },
+ { 6, 142857, 0xc1, 0xa4 },
+ { 7, 142857, 0xc1, 0xc4 },
+ { 77000, 142857, 0xc1, 0xe4 },
+ }
+};
+
/* --- */
static const struct dvb_pll_desc *pll_list[] = {
@@ -574,6 +596,7 @@ static const struct dvb_pll_desc *pll_list[] = {
[DVB_PLL_SAMSUNG_TBDU18132] = &dvb_pll_samsung_tbdu18132,
[DVB_PLL_SAMSUNG_TBMU24112] = &dvb_pll_samsung_tbmu24112,
[DVB_PLL_TUA6034_FRIIO] = &dvb_pll_tua6034_friio,
+ [DVB_PLL_TDA665X_EARTH_PT1] = &dvb_pll_tda665x_earth_pt1,
};
/* --- */
diff --git a/drivers/media/dvb-frontends/dvb-pll.h
b/drivers/media/dvb-frontends/dvb-pll.h
index f1f3ea4c0d5..41b3df36212 100644
--- a/drivers/media/dvb-frontends/dvb-pll.h
+++ b/drivers/media/dvb-frontends/dvb-pll.h
@@ -30,6 +30,7 @@
#define DVB_PLL_TDEE4 18
#define DVB_PLL_THOMSON_DTT7520X 19
#define DVB_PLL_TUA6034_FRIIO 20
+#define DVB_PLL_TDA665X_EARTH_PT1 21
struct dvb_pll_config {
struct dvb_frontend *fe;
--
2.16.3
[PATCH 3/5] dvb: earth-pt1: decompose pt1 driver into sub drivers
From: Akihiro Tsukada
earth-pt1 was a monolithic module and included demod/tuner drivers.
This patch removes those FE parts and attach demod/tuner i2c drivers.
Signed-off-by: Akihiro Tsukada
---
drivers/media/pci/pt1/Kconfig| 3 +
drivers/media/pci/pt1/Makefile | 3 +-
drivers/media/pci/pt1/pt1.c | 335 +++-
drivers/media/pci/pt1/va1j5jf8007s.c | 732 ---
drivers/media/pci/pt1/va1j5jf8007s.h | 42 --
drivers/media/pci/pt1/va1j5jf8007t.c | 532 -
drivers/media/pci/pt1/va1j5jf8007t.h | 42 --
7 files changed, 233 insertions(+), 1456 deletions(-)
delete mode 100644 drivers/media/pci/pt1/va1j5jf8007s.c
delete mode 100644 drivers/media/pci/pt1/va1j5jf8007s.h
delete mode 100644 drivers/media/pci/pt1/va1j5jf8007t.c
delete mode 100644 drivers/media/pci/pt1/va1j5jf8007t.h
diff --git a/drivers/media/pci/pt1/Kconfig b/drivers/media/pci/pt1/Kconfig
index 24501d5bf70..2718b4c6b7c 100644
--- a/drivers/media/pci/pt1/Kconfig
+++ b/drivers/media/pci/pt1/Kconfig
@@ -1,6 +1,9 @@
config DVB_PT1
tristate "PT1 cards"
depends on DVB_CORE && PCI && I2C
+ select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_QM1D1B0004 if MEDIA_SUBDRV_AUTOSELECT
help
Support for Earthsoft PT1 PCI cards.
diff --git a/drivers/media/pci/pt1/Makefile b/drivers/media/pci/pt1/Makefile
index ab873ae088a..bc491e08dd6 100644
--- a/drivers/media/pci/pt1/Makefile
+++ b/drivers/media/pci/pt1/Makefile
@@ -1,5 +1,6 @@
-earth-pt1-objs := pt1.o va1j5jf8007s.o va1j5jf8007t.o
+earth-pt1-objs := pt1.o
obj-$(CONFIG_DVB_PT1) += earth-pt1.o
ccflags-y += -Idrivers/media/dvb-frontends
+ccflags-y += -Idrivers/media/tuners
diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
index 4f6867af831..34a688952e2 100644
--- a/drivers/media/pci/pt1/pt1.c
+++ b/drivers/media/pci/pt1/pt1.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -33,8 +35,9 @@
#include
#include
-#include "va1j5jf8007t.h"
-#include "va1j5jf8007s.h"
+#include "tc90522.h"
+#include "qm1d1b0004.h"
+#include "dvb-pll.h"
#define DRIVER_NAME "earth-pt1"
@@ -63,6 +66,11 @@ struct pt1_table {
struct pt1_buffer bufs[PT1_NR_BUFS];
};
+enum pt1_fe_clk {
+ PT1_FE_CLK_20MHZ, /* PT1 */
+ PT1_FE_CLK_25MHZ, /* PT2 */
+};
+
#define PT1_NR_ADAPS 4
struct pt1_adapter;
@@ -81,6 +89,8 @@ struct pt1 {
struct mutex lock;
int power;
int reset;
+
+ enum pt1_fe_clk fe_clk;
};
struct pt1_adapter {
@@ -97,6 +107,8 @@ struct pt1_adapter {
int users;
struct dmxdev dmxdev;
struct dvb_frontend *fe;
+ struct i2c_client *demod_i2c_client;
+ struct i2c_client *tuner_i2c_client;
int (*orig_set_voltage)(struct dvb_frontend *fe,
enum fe_sec_voltage voltage);
int (*orig_sleep)(struct dvb_frontend *fe);
@@ -106,6 +118,150 @@ struct pt1_adapter {
int sleep;
};
+union pt1_tuner_config {
+ struct qm1d1b0004_config qm1d1b0004;
+ struct dvb_pll_config tda6651;
+};
+
+struct pt1_config {
+ struct i2c_board_info demod_info;
+ struct tc90522_config demod_cfg;
+
+ struct i2c_board_info tuner_info;
+ union pt1_tuner_config tuner_cfg;
+};
+
+static const struct pt1_config pt1_configs[PT1_NR_ADAPS] = {
+ {
+ .demod_info = {
+ I2C_BOARD_INFO(TC90522_I2C_DEV_SAT, 0x1b),
+ },
+ .tuner_info = {
+ I2C_BOARD_INFO("qm1d1b0004", 0x60),
+ },
+ },
+ {
+ .demod_info = {
+ I2C_BOARD_INFO(TC90522_I2C_DEV_TER, 0x1a),
+ },
+ .tuner_info = {
+ I2C_BOARD_INFO("dvb_pll", 0x61),
+ },
+ .tuner_cfg.tda6651 = {
+ .desc_id = DVB_PLL_TDA665X_EARTH_PT1,
+ },
+ },
+ {
+ .demod_info = {
+ I2C_BOARD_INFO(TC90522_I2C_DEV_SAT, 0x19),
+ },
+ .tuner_info = {
+ I2C_BOARD_INFO("qm1d1b0004", 0x60),
+ },
+ },
+ {
+ .demod_info = {
+ I2C_BOARD_INFO(TC90522_I2C_DEV_TER, 0x18),
+ },
+ .tuner_info = {
+ I2C_BOARD_INFO("dvb_pll", 0x61),
+ },
+ .tuner_cfg.tda6651 = {
+ .desc_id = DVB_PLL_TDA665X_EARTH_PT1,
+ },
+ },
+};
+
+static const u8 va1j5jf8007s_20mhz_configs[][2] = {
+ {0x04, 0x02}, {0x0d, 0x55}, {0x11, 0x40}, {0x13, 0x80}, {0x17, 0x01},
+ {0x1c, 0x0a}, {0x1d, 0xaa}, {0x1e, 0x20}, {0x1f, 0x88}, {0x51, 0xb0},
+ {0x52, 0x89}, {0x53, 0xb3}, {
[PATCH 5/5] dvb: earth-pt1: replace schedule_timeout with usleep_range
From: Akihiro Tsukada
As described in Document/timers/timers-howto.txt,
hrtimer-based delay should be used for small sleeps.
Signed-off-by: Akihiro Tsukada
---
drivers/media/pci/pt1/pt1.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
index 1a83a624776..4f84672974d 100644
--- a/drivers/media/pci/pt1/pt1.c
+++ b/drivers/media/pci/pt1/pt1.c
@@ -18,7 +18,10 @@
*/
#include
+#include
#include
+#include
+#include
#include
#include
#include
@@ -327,7 +330,7 @@ static int pt1_unlock(struct pt1 *pt1)
for (i = 0; i < 3; i++) {
if (pt1_read_reg(pt1, 0) & 0x8000)
return 0;
- schedule_timeout_uninterruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
}
dev_err(&pt1->pdev->dev, "could not unlock\n");
return -EIO;
@@ -341,7 +344,7 @@ static int pt1_reset_pci(struct pt1 *pt1)
for (i = 0; i < 10; i++) {
if (pt1_read_reg(pt1, 0) & 0x0001)
return 0;
- schedule_timeout_uninterruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
}
dev_err(&pt1->pdev->dev, "could not reset PCI\n");
return -EIO;
@@ -355,7 +358,7 @@ static int pt1_reset_ram(struct pt1 *pt1)
for (i = 0; i < 10; i++) {
if (pt1_read_reg(pt1, 0) & 0x0002)
return 0;
- schedule_timeout_uninterruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
}
dev_err(&pt1->pdev->dev, "could not reset RAM\n");
return -EIO;
@@ -372,7 +375,7 @@ static int pt1_do_enable_ram(struct pt1 *pt1)
if ((pt1_read_reg(pt1, 0) & 0x0004) != status)
return 0;
}
- schedule_timeout_uninterruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
}
dev_err(&pt1->pdev->dev, "could not enable RAM\n");
return -EIO;
@@ -382,7 +385,7 @@ static int pt1_enable_ram(struct pt1 *pt1)
{
int i, ret;
int phase;
- schedule_timeout_uninterruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
phase = pt1->pdev->device == 0x211a ? 128 : 166;
for (i = 0; i < phase; i++) {
ret = pt1_do_enable_ram(pt1);
@@ -469,6 +472,9 @@ static int pt1_thread(void *data)
struct pt1_buffer_page *page;
bool was_frozen;
+#define PT1_FETCH_DELAY 10
+#define PT1_FETCH_DELAY_DELTA 2
+
pt1 = data;
set_freezable();
@@ -482,7 +488,13 @@ static int pt1_thread(void *data)
page = pt1->tables[pt1->table_index].bufs[pt1->buf_index].page;
if (!pt1_filter(pt1, page)) {
- schedule_timeout_interruptible((HZ + 999) / 1000);
+ ktime_t delay;
+
+ delay = PT1_FETCH_DELAY * NSEC_PER_MSEC;
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_hrtimeout_range(&delay,
+ PT1_FETCH_DELAY_DELTA * NSEC_PER_MSEC,
+ HRTIMER_MODE_REL);
continue;
}
@@ -718,7 +730,7 @@ pt1_update_power(struct pt1 *pt1)
adap = pt1->adaps[i];
switch (adap->voltage) {
case SEC_VOLTAGE_13: /* actually 11V */
- bits |= 1 << 1;
+ bits |= 1 << 2;
break;
case SEC_VOLTAGE_18: /* actually 15V */
bits |= 1 << 1 | 1 << 2;
@@ -772,7 +784,7 @@ static int pt1_wakeup(struct dvb_frontend *fe)
adap = container_of(fe->dvb, struct pt1_adapter, adap);
adap->sleep = 0;
pt1_update_power(adap->pt1);
- schedule_timeout_uninterruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
ret = config_demod(adap->demod_i2c_client, adap->pt1->fe_clk);
if (ret == 0 && adap->orig_init)
@@ -1079,7 +1091,7 @@ static int pt1_i2c_end(struct pt1 *pt1, int addr)
do {
if (signal_pending(current))
return -EINTR;
- schedule_timeout_interruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
} while (pt1_read_reg(pt1, 0) & 0x0080);
return 0;
}
@@ -1382,11 +1394,11 @@ static int pt1_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
pt1->power = 1;
pt1_update_power(pt1);
- schedule_timeout_uninterruptible((HZ + 49) / 50);
+ msleep(20);
pt1->reset = 0;
pt1_update_power(pt1);
- schedule_timeout_uninterruptible((HZ + 999) / 1000);
+ usleep_range(1000, 2000);
ret = pt1_init_frontends(pt1);
if (ret < 0)
--
2.16.3
[PATCH 0/5] dvb/pci/pt1: decompose earth-pt1 into sub drivers
From: Akihiro Tsukada Akihiro Tsukada (5): dvb-frontends/dvb-pll: add tda6651 ISDB-T pll_desc tuners: add new i2c driver for Sharp qm1d1b0004 ISDB-S tuner dvb: earth-pt1: decompose pt1 driver into sub drivers dvb: earth-pt1: add support for suspend/resume dvb: earth-pt1: replace schedule_timeout with usleep_range drivers/media/dvb-frontends/dvb-pll.c | 23 ++ drivers/media/dvb-frontends/dvb-pll.h | 1 + drivers/media/pci/pt1/Kconfig | 3 + drivers/media/pci/pt1/Makefile| 3 +- drivers/media/pci/pt1/pt1.c | 476 -- drivers/media/pci/pt1/va1j5jf8007s.c | 732 -- drivers/media/pci/pt1/va1j5jf8007s.h | 42 -- drivers/media/pci/pt1/va1j5jf8007t.c | 532 drivers/media/pci/pt1/va1j5jf8007t.h | 42 -- drivers/media/tuners/Kconfig | 7 + drivers/media/tuners/Makefile | 1 + drivers/media/tuners/qm1d1b0004.c | 264 drivers/media/tuners/qm1d1b0004.h | 24 ++ 13 files changed, 681 insertions(+), 1469 deletions(-) delete mode 100644 drivers/media/pci/pt1/va1j5jf8007s.c delete mode 100644 drivers/media/pci/pt1/va1j5jf8007s.h delete mode 100644 drivers/media/pci/pt1/va1j5jf8007t.c delete mode 100644 drivers/media/pci/pt1/va1j5jf8007t.h create mode 100644 drivers/media/tuners/qm1d1b0004.c create mode 100644 drivers/media/tuners/qm1d1b0004.h -- 2.16.3
Re: [RFC v2 00/10] Preparing the request API
Status update: Current work-in-progress tree: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=reqv8 v4l2-compliance test code: https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=request It is now working for me with v4l2-compliance and vim2m and vivid. All requests and request objects are correctly freed after doing all the v4l2-compliance tests. It's a fairly decent test coverage, but I'm sure there are some corner cases that can be added. I've frozen my reqv8 branch so that can be used as a starting point for codec drivers. I've started a reqv9 which will be the cleaned-up version of reqv8. My hope is that I can finish that tomorrow and post the patch series to the ML at the end of the day. Regards, Hans
Re: [PATCH v3 2/2] media: ov2680: Add Omnivision OV2680 sensor driver
Hi Sakari,
On Sat 24 Mar 2018 at 10:57, Sakari Ailus wrote:
Hi Rui,
I wanted to go through the code the last time and I'd have a few
review
comments below...
Thanks for the review.
On Tue, Mar 13, 2018 at 11:33:11AM +, Rui Miguel Silva
wrote:
...
+static int ov2680_gain_set(struct ov2680_dev *sensor, bool
auto_gain)
+{
+ struct ov2680_ctrls *ctrls = &sensor->ctrls;
+ u32 gain;
+ int ret;
+
+ ret = ov2680_mod_reg(sensor, OV2680_REG_R_MANUAL, BIT(1),
+auto_gain ? 0 : BIT(1));
+ if (ret < 0)
+ return ret;
+
+ if (auto_gain || !ctrls->gain->is_new)
+ return 0;
+
+ gain = ctrls->gain->val;
+
+ ret = ov2680_write_reg16(sensor, OV2680_REG_GAIN_PK,
gain);
+
+ return 0;
+}
+
+static int ov2680_gain_get(struct ov2680_dev *sensor)
+{
+ u32 gain;
+ int ret;
+
+ ret = ov2680_read_reg16(sensor, OV2680_REG_GAIN_PK,
&gain);
+ if (ret)
+ return ret;
+
+ return gain;
+}
+
+static int ov2680_auto_gain_enable(struct ov2680_dev *sensor)
+{
+ return ov2680_gain_set(sensor, true);
+}
+
+static int ov2680_auto_gain_disable(struct ov2680_dev *sensor)
+{
+ return ov2680_gain_set(sensor, false);
+}
+
+static int ov2680_exposure_set(struct ov2680_dev *sensor, bool
auto_exp)
+{
+ struct ov2680_ctrls *ctrls = &sensor->ctrls;
+ u32 exp;
+ int ret;
+
+ ret = ov2680_mod_reg(sensor, OV2680_REG_R_MANUAL, BIT(0),
+auto_exp ? 0 : BIT(0));
+ if (ret < 0)
+ return ret;
+
+ if (auto_exp || !ctrls->exposure->is_new)
+ return 0;
+
+ exp = (u32)ctrls->exposure->val;
+ exp <<= 4;
+
+ return ov2680_write_reg24(sensor,
OV2680_REG_EXPOSURE_PK_HIGH, exp);
+}
+
+static int ov2680_exposure_get(struct ov2680_dev *sensor)
+{
+ int ret;
+ u32 exp;
+
+ ret = ov2680_read_reg24(sensor,
OV2680_REG_EXPOSURE_PK_HIGH, &exp);
+ if (ret)
+ return ret;
+
+ return exp >> 4;
+}
+
+static int ov2680_auto_exposure_enable(struct ov2680_dev
*sensor)
+{
+ return ov2680_exposure_set(sensor, true);
+}
+
+static int ov2680_auto_exposure_disable(struct ov2680_dev
*sensor)
+{
+ return ov2680_exposure_set(sensor, false);
+}
I still think you could call the function actually doing the
work, and pass
the bool parameter. That'd be much clearer. Please see the
comments below,
too; they're related. Same for gain.
Ok, no problem, will change that in v4.
...
+static int ov2680_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
+ struct ov2680_dev *sensor = to_ov2680_dev(sd);
+ int val;
+
+ if (!sensor->is_enabled)
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_AUTOGAIN:
+ if (!ctrl->val)
+ return 0;
+ val = ov2680_gain_get(sensor);
+ if (val < 0)
+ return val;
+ sensor->ctrls.gain->val = val;
+ break;
+ case V4L2_CID_EXPOSURE_AUTO:
I reckon the purpose of implementing volatile controls here
would be to
provide the exposure and gain values to the user. But the
controls here are
the ones enabling or disabling the automatic behaviour, not the
value of
those settings themselves.
+ if (ctrl->val == V4L2_EXPOSURE_MANUAL)
+ return 0;
+ val = ov2680_exposure_get(sensor);
+ if (val < 0)
+ return val;
+ sensor->ctrls.exposure->val = val;
+ break;
+ }
+
+ return 0;
+}
+
+static int ov2680_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
+ struct ov2680_dev *sensor = to_ov2680_dev(sd);
+
+ if (!sensor->is_enabled)
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_AUTOGAIN:
+ return ov2680_gain_set(sensor, !!ctrl->val);
+ case V4L2_CID_EXPOSURE_AUTO:
+ return ov2680_exposure_set(sensor, !!ctrl->val);
With this, you can enable or disable automatic exposure and
gain, but you
cannot manually set the values. Are such controls useful?
Unless I'm mistaken, exposure or gain are not settable, so you
should make
them read-only controls. Or better, allow setting them if
automatic control
is disabled.
Yeah, I could definitely change the values of exposure and gain
also,
but that may came how the ctrl group work internally. But I will
change
and add them.
+ case V4L2_CID_VFLIP:
+ if (sensor->is_streaming)
+ return -EBUSY;
+ if (ctrl->val)
+ return ov2680_vflip_enable(sensor);
+ else
+ return ov2680_vflip_disable(sensor);
+ case V4L2_CID_HFLIP:
+ if (ctrl->val)
+
Re: FM radio (SAA7134)
I do not know if this is the problem but: As per V4L2 specifications VIDIOC_S_FREQUENCY ioctl expects tuning frequency in units of 62.5 KHz, or if the struct v4l2_tuner or struct v4l2_modulator capabilities flag V4L2_TUNER_CAP_LOW is set, in units of 62.5 Hz. But FM driver presently handling the frequency in units of 1 KHz FM driver is not setting V4L2_TUNER_CAP_LOW flag , but its returning vtun.rangelow and vtun.rangehigh ranges in HZ . This needs to be corrected in FM driver. On Tue, Mar 27, 2018 at 1:52 PM, P G wrote: > I have tuner card, with radio tuner. > > The modules are loaded fine, no errors in dmesg, but radio is having issues. > I use radio application from xawtv, and also fm tools, but none of > them is working properly. > When i fire up radio, it tunes to 1.04MHZ, and i hear sound noise > (like when radio isn't tuned). If i tune to another frequency, let's > say 88.0Mhz, i hear the radio station sound for 1-2 seconds, and then > the tuner tunes back to 1.04Mhz. > Same applies for fm tools. I tune with command fm 88.0 on, tuner tunes > in the apropriate radio station for a few seconds and then it goes > back to noise. > > You can see it here as well: > Code: > > v4l2-ctl -d /dev/radio0 --all > > Driver Info (not using libv4l2): > Driver name : saa7134 > Card type : ASUSTeK P7131 Hybrid > Bus info : PCI::04:01.0 > Driver version: 3.13.2 > Capabilities : 0x85050015 > Video Capture > Video Overlay > VBI Capture > Tuner > Radio > Read/Write > Streaming > Device Capabilities > Device Caps : 0x0005 > Tuner > Radio > Priority: 2 > Frequency for tuner 0: 16640 (1.04 MHz) > Tuner 0: > Name : Radio > Capabilities : 62.5 Hz stereo freq-bands > Frequency range : 65.000 MHz - 108.000 MHz > Signal strength/AFC : 0%/0 > Current audio mode : stereo > Available subchannels: mono >mute (bool) : default=0 value=0 > > The frequency of the tuner is 1.04 MHz, but the range of the tuner > is between 65 and 108 as it should be. > Does anyone has any idea if is FM driver bug?
Re: [PATCH 08/30] media: v4l2-ioctl: fix some "too small" warnings
Hi Mauro,
On Monday, 26 March 2018 23:28:55 EEST Mauro Carvalho Chehab wrote:
> Em Mon, 26 Mar 2018 21:47:33 +0300 Laurent Pinchart escreveu:
> > On Monday, 26 March 2018 13:08:16 EEST Mauro Carvalho Chehab wrote:
> > > Em Fri, 23 Mar 2018 23:53:56 +0200 Sakari Ailus escreveu:
> > > > On Fri, Mar 23, 2018 at 07:56:54AM -0400, Mauro Carvalho Chehab wrote:
> > > >> While the code there is right, it produces three false positives:
> > > >>drivers/media/v4l2-core/v4l2-ioctl.c:2868 video_usercopy()
> > > >> error:
> > > >>copy_from_user() 'parg' too small (128 vs 16383)
> > > >>drivers/media/v4l2-core/v4l2-ioctl.c:2868 video_usercopy()
> > > >> error:
> > > >>copy_from_user() 'parg' too small (128 vs 16383)
> > > >>drivers/media/v4l2-core/v4l2-ioctl.c:2876 video_usercopy()
> > > >> error:
> > > >>memset() 'parg' too small (128 vs 16383)> >
> > > >>
> > > >> Store the ioctl size on a cache var, in order to suppress those.
> > > >
> > > > I have to say I'm not a big fan of changing perfectly fine code in
> > > > order
> > > > to please static analysers.
> > >
> > > Well, there's a side effect of this patch: it allows gcc to better
> > >
> > > optimize the text size, with is good:
> > >text data bss dec hex filename
> > >
> > > 34538 2320 0 36858
> > >
> > > 8ffa old/drivers/media/v4l2-core/v4l2-ioctl.o 34490 2320 0
> > > 368108fca new/drivers/media/v4l2-core/v4l2-ioctl.o
> > >
> > > > What's this, smatch? I wonder if it could be fixed
> > > > instead of changing the code. That'd be presumably a lot more work
> > > > though.
> > >
> > > Yes, the warnings came from smatch. No idea how easy/hard would be to
> > > change it.
> > >
> > > > On naming --- "size" is rather more generic, but it's not a long
> > > > function
> > > > either. I'd be a bit more specific, e.g. ioc_size or arg_size.
> > >
> > > Agreed.
> > >
> > > I'll add the enclosed patch changing it to ioc_size.
> > >
> > >
> > > Thanks,
> > > Mauro
> > >
> > > [PATCH] media: v4l2-ioctl: rename a temp var that stores _IOC_SIZE(cmd)
> > >
> > > Instead of just calling it as "size", let's name it as "ioc_size",
> > > as it reflects better its contents.
> > >
> > > As this is constant along the function, also mark it as const.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab
> >
> > I would have expected a v2 of the original patch, but it seems you pushed
> > it to the public master branch before giving anyone a change to review it
> > (Sakari's review came 10h after the past was posted).
> >
> > Patches need to be reviewed before being applied, and that applies to all
> > patches, regarding of the author. Please refrain from merging future
> > patches before they get reviewed.
>
> It shouldn't have pushed. It happened due to some script errors,
> when I was handling a request from Hans to push upstream some fixes
> for -rc7, as mentioned on IRC:
> https://linuxtv.org/irc/irclogger_log/v4l?date=2018-03-23,Fri
Thank you for the explanation. Bugs happen, luckily it should have less impact
than spectre or meltdown :-)
> As I said there:
>
> "If someone finds an issue on the warning fixes, I can revert or apply a
> fixup I really hate when things like that happens :-("
--
Regards,
Laurent Pinchart
Re: [PATCH 07/18] media: staging: atomisp: fix endianess issues
On Mon, 2018-03-26 at 17:10 -0400, Mauro Carvalho Chehab wrote:
> There are lots of be-related warnings there, as it doesn't properly
> mark what data uses bigendian.
> @@ -107,7 +107,7 @@ mt9m114_write_reg(struct i2c_client *client, u16
> data_length, u16 reg, u32 val)
> int num_msg;
> struct i2c_msg msg;
> unsigned char data[6] = {0};
> - u16 *wreg;
> + __be16 *wreg;
>
> + u16 *wdata = (void *)&data[2];
> +
> + *wdata = be16_to_cpu(*(__be16 *)&data[2]);
> + u32 *wdata = (void *)&data[2];
> +
> + *wdata = be32_to_cpu(*(__be32 *)&data[2]);
For x86 it is okay, though in general it should use get_unaligned().
--
Andy Shevchenko
Intel Finland Oy
FM radio (SAA7134)
I have tuner card, with radio tuner. The modules are loaded fine, no errors in dmesg, but radio is having issues. I use radio application from xawtv, and also fm tools, but none of them is working properly. When i fire up radio, it tunes to 1.04MHZ, and i hear sound noise (like when radio isn't tuned). If i tune to another frequency, let's say 88.0Mhz, i hear the radio station sound for 1-2 seconds, and then the tuner tunes back to 1.04Mhz. Same applies for fm tools. I tune with command fm 88.0 on, tuner tunes in the apropriate radio station for a few seconds and then it goes back to noise. You can see it here as well: Code: v4l2-ctl -d /dev/radio0 --all Driver Info (not using libv4l2): Driver name : saa7134 Card type : ASUSTeK P7131 Hybrid Bus info : PCI::04:01.0 Driver version: 3.13.2 Capabilities : 0x85050015 Video Capture Video Overlay VBI Capture Tuner Radio Read/Write Streaming Device Capabilities Device Caps : 0x0005 Tuner Radio Priority: 2 Frequency for tuner 0: 16640 (1.04 MHz) Tuner 0: Name : Radio Capabilities : 62.5 Hz stereo freq-bands Frequency range : 65.000 MHz - 108.000 MHz Signal strength/AFC : 0%/0 Current audio mode : stereo Available subchannels: mono mute (bool) : default=0 value=0 The frequency of the tuner is 1.04 MHz, but the range of the tuner is between 65 and 108 as it should be. Does anyone has any idea if is FM driver bug?
Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
On Tue, Mar 27, 2018 at 10:06:04AM +0200, Christian König wrote:
> Am 27.03.2018 um 09:53 schrieb Daniel Vetter:
> > [SNIP]
> > > > [SNIP]
> > > > A slightly better solution is using atomic counter:
> > > > driver_range_start() {
> > > > atomic_inc(&mydev->notifier_count);
> > > ...
> > >
> > > Yeah, that is exactly what amdgpu is doing now. Sorry if my description
> > > didn't made that clear.
> > >
> > > > I would like to see driver using same code, as it means one place to fix
> > > > issues. I had for a long time on my TODO list doing the above conversion
> > > > to amd or radeon kernel driver. I am pushing up my todo list hopefully
> > > > in
> > > > next few weeks i can send an rfc so people can have a real sense of how
> > > > it can look.
> > > Certainly a good idea, but I think we might have that separate to HMM.
> > >
> > > TTM suffered really from feature overload, e.g. trying to do everything
> > > in a
> > > single subsystem. And it would be rather nice to have coherent userptr
> > > handling for GPUs as separate feature.
> > TTM suffered from being a midlayer imo, not from doing too much.
>
> Yeah, completely agree.
>
> midlayers work as long as you concentrate on doing exactly one things in
> your midlayer. E.g. in the case of TTM the callback for BO move handling is
> well justified.
>
> Only all the stuff around it like address space handling etc... is really
> wrong designed and should be separated (which is exactly what DRM MM did,
> but TTM still uses this in the wrong way).
Yeah the addres space allocator part of ttm really is backwards and makes
adding quick driver hacks and heuristics for better allocations schemes
really hard to add. Same for tuning how/what exactly you evict.
> > HMM is apparently structured like a toolbox (despite its documentation
> > claiming
> > otherwise), so you can pick&choose freely.
>
> That sounds good, but I would still have a better feeling if userptr
> handling would be separated. That avoids mangling things together again.
Jerome said he wants to do at least one prototype conversion of one of the
"I can't fault" userptr implementation over to the suitable subset of HMM
helpers. I guess we'll see once he's submitting the patches, but it
sounded exactly like what the doctor ordered :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage
On Mon, Mar 26, 2018 at 10:04:24AM +0100, Kieran Bingham wrote:
> Hi Simon,
>
> On 26/03/18 09:31, Simon Horman wrote:
> > On Fri, Mar 23, 2018 at 09:16:13PM +, Kieran Bingham wrote:
> >> Hi Simon,
> >>
> >> On 23/03/18 08:51, Simon Horman wrote:
> >>> On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
> The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
> bus, however in low power mode the ADV7513 will reset it's slave maps to
> use the hardware defined default addresses.
>
> The ADV7511 driver was adapted to allow the two devices to be registered
> correctly - but it did not take into account the fault whereby the
> devices reset the addresses.
>
> This results in an address conflict between the device using the default
> addresses, and the other device if it is in low-power-mode.
>
> Repair this issue by moving both devices away from the default address
> definitions.
> >>>
> >>> Hi Kierean,
> >>>
> >>> as this is a fix
> >>> a) Does it warrant a fixes tag?
> >>>Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> >>> b) Does it warrant being posted as a fix for v4.16;
> >>> c) or v4.17?
> >>
> >> Tricky one, yes it could but this DTS fix, will only actually 'fix' the
> >> issue if
> >> the corresponding driver updates to allow secondary addresses to be parsed
> >> are
> >> also backported.
> >>
> >> It should be safe to back port the dts fix without the driver updates, but
> >> the
> >> addresses specified by this patch will simply be ignored.
> >
> > In that case I think its safe to add the fixes tag and take the DTS patch
> > via the renesas tree. Perhaps applying it for v4.18 and allowing automatic
> > backporting to take its course is the cleanest option.
> >
> >> Thus if this is marked with the fixes tag the corresponding patch "drm:
> >> adv7511:
> >> Add support for i2c_new_secondary_device" should also be marked.
> >>
> >> It looks like that patch has yet to be picked up by the DRM subsystem, so
> >> how
> >> about I bundle both of these two patches together in a repost along with
> >> the
> >> fixes tag.
> >>
> >> In fact, I don't think the ADV7511 dt-bindings update has made any progress
> >> either. (dt-bindings: adv7511: Extend bindings to allow specifying slave
> >> map
> >> addresses). The media tree variants for the adv7604 have already been
> >> picked up
> >> by Mauro I believe though.
> >>
> >> I presume it would be acceptable for this dts patch (or rather all three
> >> patches
> >> mentioned) to get integrated through the DRM tree ?
> >
> > Unless there is a strong reason I would prefer the dts patch to go via
> > my tree. The reason is to avoid merge conflicts bubbling up to Linus,
> > which really is something best avoided.
>
> That's perfectly fine with me.
>
> Feel free to add:
>
> Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
>
> as you suggested when you apply, or alternatively let me know if you need a
> repost.
Thanks, applied for v4.18 with the fixes tag.
Re: [PATCHv2 6/7] cec-pin-error-inj.rst: document CEC Pin Error Injection
> > I'll wait for a v3 with the debugfs ABI documentation in order to merge > > it. Feel free to put it on a separate patch. > > debugfs ABI? Sounds like an oxymoron to me. Heh, thought the same :) signature.asc Description: PGP signature
Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
Am 27.03.2018 um 09:53 schrieb Daniel Vetter:
[SNIP]
[SNIP]
A slightly better solution is using atomic counter:
driver_range_start() {
atomic_inc(&mydev->notifier_count);
...
Yeah, that is exactly what amdgpu is doing now. Sorry if my description
didn't made that clear.
I would like to see driver using same code, as it means one place to fix
issues. I had for a long time on my TODO list doing the above conversion
to amd or radeon kernel driver. I am pushing up my todo list hopefully in
next few weeks i can send an rfc so people can have a real sense of how
it can look.
Certainly a good idea, but I think we might have that separate to HMM.
TTM suffered really from feature overload, e.g. trying to do everything in a
single subsystem. And it would be rather nice to have coherent userptr
handling for GPUs as separate feature.
TTM suffered from being a midlayer imo, not from doing too much.
Yeah, completely agree.
midlayers work as long as you concentrate on doing exactly one things in
your midlayer. E.g. in the case of TTM the callback for BO move handling
is well justified.
Only all the stuff around it like address space handling etc... is
really wrong designed and should be separated (which is exactly what DRM
MM did, but TTM still uses this in the wrong way).
HMM is apparently structured like a toolbox (despite its documentation claiming
otherwise), so you can pick&choose freely.
That sounds good, but I would still have a better feeling if userptr
handling would be separated. That avoids mangling things together again.
Christian.
-Daniel
Re: [PATCHv2 6/7] cec-pin-error-inj.rst: document CEC Pin Error Injection
On Wed, 21 Mar 2018, Mauro Carvalho Chehab wrote: > Please notice that all debugfs/sysfs entries should *also* be > documented at the standard way, e. g. by adding the corresponding > documentation at Documentation/ABI. > > Please see Documentation/ABI/README. > > Additionally, there are a few minor nitpicks on this patch. > See below. > > The remaining patches looked ok on my eyes. > > I'll wait for a v3 with the debugfs ABI documentation in order to merge > it. Feel free to put it on a separate patch. debugfs ABI? Sounds like an oxymoron to me. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
On Tue, Mar 27, 2018 at 09:35:17AM +0200, Christian König wrote:
> Am 26.03.2018 um 17:42 schrieb Jerome Glisse:
> > On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote:
> > > On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote:
> > > > Am 22.03.2018 um 08:18 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > Key take away from that was that you can't take any locks from neither
> > > > the
> > > > MMU notifier nor the shrinker you also take while calling kmalloc (or
> > > > simpler speaking get_user_pages()).
> > > >
> > > > Additional to that in the MMU or shrinker callback all different kinds
> > > > of
> > > > locks might be held, so you basically can't assume that you do thinks
> > > > like
> > > > recursive page table walks or call dma_unmap_anything.
> > > That sounds like a design bug in mmu_notifiers, since it would render them
> > > useless for KVM. And they were developed for that originally. I think I'll
> > > chat with Jerome to understand this, since it's all rather confusing.
> > Doing dma_unmap() during mmu_notifier callback should be fine, it was last
> > time i check. However there is no formal contract that it is ok to do so.
>
> As I said before dma_unmap() isn't the real problem here.
>
> The issues is more that you can't take a lock in the MMU notifier which you
> would also take while allocating memory without GFP_NOIO.
>
> That makes it rather tricky to do any command submission, e.g. you need to
> grab all the pages/memory/resources prehand, then make sure that you don't
> have a MMU notifier running concurrently and do the submission.
>
> If any of the prerequisites isn't fulfilled we need to restart the
> operation.
Yeah we're hitting all that epic amount of fun now, after a chat with
Jerome yesterady. I guess we'll figure out what we're coming up with.
> > [SNIP]
> > A slightly better solution is using atomic counter:
> >driver_range_start() {
> > atomic_inc(&mydev->notifier_count);
> ...
>
> Yeah, that is exactly what amdgpu is doing now. Sorry if my description
> didn't made that clear.
>
> > I would like to see driver using same code, as it means one place to fix
> > issues. I had for a long time on my TODO list doing the above conversion
> > to amd or radeon kernel driver. I am pushing up my todo list hopefully in
> > next few weeks i can send an rfc so people can have a real sense of how
> > it can look.
>
> Certainly a good idea, but I think we might have that separate to HMM.
>
> TTM suffered really from feature overload, e.g. trying to do everything in a
> single subsystem. And it would be rather nice to have coherent userptr
> handling for GPUs as separate feature.
TTM suffered from being a midlayer imo, not from doing too much. HMM is
apparently structured like a toolbox (despite its documentation claiming
otherwise), so you can pick&choose freely.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
Am 26.03.2018 um 17:42 schrieb Jerome Glisse:
On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote:
On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote:
Am 22.03.2018 um 08:18 schrieb Daniel Vetter:
[SNIP]
Key take away from that was that you can't take any locks from neither the
MMU notifier nor the shrinker you also take while calling kmalloc (or
simpler speaking get_user_pages()).
Additional to that in the MMU or shrinker callback all different kinds of
locks might be held, so you basically can't assume that you do thinks like
recursive page table walks or call dma_unmap_anything.
That sounds like a design bug in mmu_notifiers, since it would render them
useless for KVM. And they were developed for that originally. I think I'll
chat with Jerome to understand this, since it's all rather confusing.
Doing dma_unmap() during mmu_notifier callback should be fine, it was last
time i check. However there is no formal contract that it is ok to do so.
As I said before dma_unmap() isn't the real problem here.
The issues is more that you can't take a lock in the MMU notifier which
you would also take while allocating memory without GFP_NOIO.
That makes it rather tricky to do any command submission, e.g. you need
to grab all the pages/memory/resources prehand, then make sure that you
don't have a MMU notifier running concurrently and do the submission.
If any of the prerequisites isn't fulfilled we need to restart the
operation.
[SNIP]
A slightly better solution is using atomic counter:
driver_range_start() {
atomic_inc(&mydev->notifier_count);
...
Yeah, that is exactly what amdgpu is doing now. Sorry if my description
didn't made that clear.
I would like to see driver using same code, as it means one place to fix
issues. I had for a long time on my TODO list doing the above conversion
to amd or radeon kernel driver. I am pushing up my todo list hopefully in
next few weeks i can send an rfc so people can have a real sense of how
it can look.
Certainly a good idea, but I think we might have that separate to HMM.
TTM suffered really from feature overload, e.g. trying to do everything
in a single subsystem. And it would be rather nice to have coherent
userptr handling for GPUs as separate feature.
Regards,
Christian.
