Re: [PATCH 3/4] [media] dvb-frontends/stv0367: SNR DVBv5 statistics for DVB-C and T
On 06/20/2017 08:45 PM, Daniel Scheller wrote:
From: Daniel Scheller
Add signal-to-noise-ratio as provided by the demodulator in decibel scale.
QAM/DVB-C needs some intlog calculation to have usable dB values, OFDM/
DVB-T values from the demod look alright already and are provided as-is.
Signed-off-by: Daniel Scheller
---
drivers/media/dvb-frontends/stv0367.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/media/dvb-frontends/stv0367.c
b/drivers/media/dvb-frontends/stv0367.c
index bb498f942ebd..0b13a407df23 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -25,6 +25,8 @@
#include
#include
+#include "dvb_math.h"
+
#include "stv0367.h"
#include "stv0367_defs.h"
#include "stv0367_regs.h"
@@ -33,6 +35,9 @@
/* Max transfer size done by I2C transfer functions */
#define MAX_XFER_SIZE 64
+/* snr logarithmic calc */
+#define INTLOG10X100(x) ((u32) (((u64) intlog10(x) * 100) >> 24))
+
static int stvdebug;
module_param_named(debug, stvdebug, int, 0644);
@@ -3013,6 +3018,33 @@ static int stv0367ddb_read_status(struct dvb_frontend *fe,
return -EINVAL;
}
+static void stv0367ddb_read_snr(struct dvb_frontend *fe)
+{
+ struct stv0367_state *state = fe->demodulator_priv;
+ struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+ int cab_pwr;
+ u32 regval, tmpval, snrval = 0;
+
+ switch (state->activedemod) {
+ case demod_ter:
+ snrval = stv0367ter_snr_readreg(fe);
+ break;
+ case demod_cab:
+ cab_pwr = stv0367cab_snr_power(fe);
+ regval = stv0367cab_snr_readreg(fe, 0);
+
+ tmpval = (cab_pwr * 320) / regval;
+ snrval = ((tmpval != 0) ? INTLOG10X100(tmpval) : 0) * 100;
How much there will be rounding errors due to that signal/noise
division? I would convert it to calculation of sums (tip logarithm
calculation rules).
Also, that INTLOG10X100 is pretty much useless. Use just what
intlog10/intlog2 offers without yet again another conversion.
+ break;
+ default:
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return;
+ }
+
+ p->cnr.stat[0].scale = FE_SCALE_DECIBEL;
+ p->cnr.stat[0].uvalue = snrval;
+}
+
static void stv0367ddb_read_ucblocks(struct dvb_frontend *fe)
{
struct stv0367_state *state = fe->demodulator_priv;
@@ -3069,6 +3101,7 @@ static int stv0367ddb_get_frontend(struct dvb_frontend
*fe,
}
stv0367ddb_read_ucblocks(fe);
+ stv0367ddb_read_snr(fe);
return 0;
}
regards
Antti
--
http://palosaari.fi/
Re: [PATCH 1/4] [media] dvb-frontends/stv0367: initial DDB DVBv5 stats, implement ucblocks
On 06/20/2017 08:45 PM, Daniel Scheller wrote:
From: Daniel Scheller
This adds the basics to stv0367ddb_get_frontend() to be able to properly
provide signal statistics in DVBv5 format. Also adds UCB readout and
provides those values.
Signed-off-by: Daniel Scheller
---
drivers/media/dvb-frontends/stv0367.c | 59 ---
1 file changed, 55 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv0367.c
b/drivers/media/dvb-frontends/stv0367.c
index e726c2e00460..5374d4eaabd6 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -2997,21 +2997,64 @@ static int stv0367ddb_read_status(struct dvb_frontend
*fe,
return -EINVAL;
}
+static void stv0367ddb_read_ucblocks(struct dvb_frontend *fe)
+{
+ struct stv0367_state *state = fe->demodulator_priv;
+ struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+ u32 ucblocks = 0;
+
+ switch (state->activedemod) {
+ case demod_ter:
+ stv0367ter_read_ucblocks(fe, &ucblocks);
+ break;
+ case demod_cab:
+ stv0367cab_read_ucblcks(fe, &ucblocks);
+ break;
+ default:
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return;
+ }
+
+ p->block_error.stat[0].scale = FE_SCALE_COUNTER;
+ p->block_error.stat[0].uvalue = ucblocks;
+}
+
static int stv0367ddb_get_frontend(struct dvb_frontend *fe,
struct dtv_frontend_properties *p)
{
struct stv0367_state *state = fe->demodulator_priv;
+ int ret = -EINVAL;
+ enum fe_status status = 0;
switch (state->activedemod) {
case demod_ter:
- return stv0367ter_get_frontend(fe, p);
+ ret = stv0367ter_get_frontend(fe, p);
+ break;
case demod_cab:
- return stv0367cab_get_frontend(fe, p);
- default:
+ ret = stv0367cab_get_frontend(fe, p);
break;
+ default:
+ p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return ret;
}
- return -EINVAL;
+ /* read fe lock status */
+ if (!ret)
+ ret = stv0367ddb_read_status(fe, &status);
+
+ /* stop if get_frontend failed or if demod isn't locked */
+ if (ret || !(status & FE_HAS_LOCK)) {
+ p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return ret;
+ }
Requiring LOCK for strength and cnr sounds wrong. Demod usually
calculates strength from IF and RF AGC and those are available even
there is no signal at all (demod set those gains to max on that case).
CNR is pretty often available when inner FEC (viterbi, LDPC) is on sync.
And for ber and per you need outer fec (reed-solomon, bch) too which is
FE_HAS_SYNC flag on api. ber is error bit and count after inner fec, per
is error packet and count after outer fec. Usually ber is counted as a
bits and per is counted as a 204 ts packets.
Also having that statistics stuff updated inside a get_frontend() sounds
wrong. I think that callback is optional and is not called unless
userspace polls it.
+
+ stv0367ddb_read_ucblocks(fe);
+
+ return 0;
}
static int stv0367ddb_sleep(struct dvb_frontend *fe)
@@ -3035,6 +3078,7 @@ static int stv0367ddb_sleep(struct dvb_frontend *fe)
static int stv0367ddb_init(struct stv0367_state *state)
{
struct stv0367ter_state *ter_state = state->ter_state;
+ struct dtv_frontend_properties *p = &state->fe.dtv_property_cache;
stv0367_writereg(state, R367TER_TOPCTRL, 0x10);
@@ -3109,6 +3153,13 @@ static int stv0367ddb_init(struct stv0367_state *state)
ter_state->first_lock = 0;
ter_state->unlock_counter = 2;
+ p->strength.len = 1;
+ p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->cnr.len = 1;
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->block_error.len = 1;
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
return 0;
}
regards
Antti
--
http://palosaari.fi/
Re: [PATCH] [media] ddbridge: use pr_* macros in favor of printk
On 06/20/2017 08:44 PM, Daniel Scheller wrote: From: Daniel Scheller Side effect: KERN_DEBUG messages aren't written to the kernel log anymore. This also improves the tda18212_ping reporting a bit so users know that if pinging wasn't successful, bad things might happen. It is device, not library, thus you should really use dev_ logging instead. With dev_ logging system could print better info, bus id etc. regards Antti -- http://palosaari.fi/
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jun 21 05:00:15 CEST 2017 media-tree git hash:76724b30f222067faf00874dc277f6c99d03d800 media_build git hash: a5ec7f00979b6c866911fb42507770727ff5afd4 v4l-utils git hash: ce237eefc1f6dafafc0e1fe3a5fd9f075d3fd066 gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: OK linux-git-arm-stm32: 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: WARNINGS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: ERRORS linux-4.9.26-i686: ERRORS linux-4.10.14-i686: ERRORS linux-4.11-i686: ERRORS linux-4.12-rc1-i686: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: ERRORS linux-4.9.26-x86_64: ERRORS linux-4.10.14-x86_64: ERRORS linux-4.11-x86_64: ERRORS linux-4.12-rc1-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: WARNINGS 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 v2] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
On Mon, 2017-06-19 at 12:10 +0200, Hans Verkuil wrote: > On 06/19/2017 12:03 PM, Minghsiu Tsai wrote: > > Hi, Hans, > > > > On Fri, 2017-06-16 at 12:42 +0200, Hans Verkuil wrote: > >> On 05/12/17 04:42, Minghsiu Tsai wrote: > >>> From: Daniel Kurtz > >>> > >>> Experiments show that the: > >>> (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT > >> > >> Please drop this, since this no longer applies to this patch. > >> > > > > I will remove it next version > > > > > >>> (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets > >> > >> Are you really certain about this? > >> > >> For m2m devices the output (i.e. memory to hardware) typically crops from > >> memory > >> and the capture side (hardware to memory) composes into memory. > >> > >> I.e.: for the output side you crop the part of the memory buffer that you > >> want > >> to process and on the capture side you compose the result into a memory > >> buffer: > >> i.e. the memory buffer might be 1920x1080, but you compose the decoder > >> output > >> into a rectangle of 640x480 at offset 128x128 within that buffer (just an > >> example). > >> > >> CAPTURE using crop would be if, before the data is DMAed, the hardware > >> decoder > >> output is cropped. E.g. if the stream fed to the decoder is 1920x1080, but > >> you > >> want to only DMA a subselection of that, then that would be cropping, and > >> it > >> would go to a memory buffer of the size of the crop selection. > >> > >> OUTPUT using compose is highly unlikely: that means that the frame you give > >> is composed in a larger internal buffer with generated border data around > >> it. > >> Very rare and really only something that a compositor of some sort would > >> do. > >> > > > > That's strange. In v4l2-ioctl.c, v4l_g_crop() > > OUTPUT is using COMPOSE > > CAPTURE is using CROP > > The old crop API can't be used with most (all?) codec drivers. Codec drivers > do > exactly the opposite of what the old crop API did. > > It is the reason the selection API was created. > > The old crop API was written for SDTV receivers where the hardware would crop > the received video. For output (rarely used) the hardware would compose the > image into a larger (PAL or NTSC sizes) frame. > > Applications have to use the selection API to work with codec drivers. Just > ignore the old crop ioctls, they are not suitable for such hardware. > Hi, Hans, Thanks for your review and comment. Conclusion is application uses wrong ioctls, g/s_crop. > > > > static int v4l_g_crop(const struct v4l2_ioctl_ops *ops, > > struct file *file, void *fh, void *arg) > > ... > > /* crop means compose for output devices */ > > if (V4L2_TYPE_IS_OUTPUT(p->type)) > > s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE; > > else > > s.target = V4L2_SEL_TGT_CROP_ACTIVE; > > > > ret = ops->vidioc_g_selection(file, fh, &s); > > > > > >> What exactly does the hardware do? Both for the encoder and for the decoder > >> case. Perhaps if I knew exactly what that is, then I can advise. > >> > > > > NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M > > > > The usage would be like this: > > For decoder: > > decoder -> MT21 -> MDP -> NV12M/YUV420M > > > > For encoder: > > NV12M/YUV420M -> MDP -> NV12M/YUV420M -> encoder > > That doesn't help. Where in these two chains does the cropping (encoder) or > composing (decoder) take place? I assume it is the DMA engine that read from > a rectangle in the source buffer (encoder) or writes to a rectangle in the > destination buffer (decoder). > Yes. they are only buffer transfer between decoder, mdp and encoder. > And in that case the current driver is correct. Next step, we will try to refine framework in userspace code. > I wonder if the g/s_crop description in the V4L2 Specification should get a > big fat warning that it doesn't apply to codec drivers and that the selection > API should be used instead. A patch for that is welcome! > > Regards, > > Hans
Re: [PATCH] [media] dvb-frontends/lnbh25: improve kernellog output
Looks good for me.
Acked-by: Abylay Ospan
2017-06-20 15:57 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller
>
> Use dev_dbg() in conjunction with the %*ph format macro to print the vmon
> status debug, thus hiding continuous hexdumping from default log levels.
> Also, change the attach success log line from error to info severity.
>
> Signed-off-by: Daniel Scheller
> ---
> drivers/media/dvb-frontends/lnbh25.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/lnbh25.c
> b/drivers/media/dvb-frontends/lnbh25.c
> index ef3021e964be..cb486e879fdd 100644
> --- a/drivers/media/dvb-frontends/lnbh25.c
> +++ b/drivers/media/dvb-frontends/lnbh25.c
> @@ -76,8 +76,8 @@ static int lnbh25_read_vmon(struct lnbh25_priv *priv)
> return ret;
> }
> }
> - print_hex_dump_bytes("lnbh25_read_vmon: ",
> - DUMP_PREFIX_OFFSET, status, sizeof(status));
> + dev_dbg(&priv->i2c->dev, "%s(): %*ph\n",
> + __func__, (int) sizeof(status), status);
> if ((status[0] & (LNBH25_STATUS_OFL | LNBH25_STATUS_VMON)) != 0) {
> dev_err(&priv->i2c->dev,
> "%s(): voltage in failure state, status reg 0x%x\n",
> @@ -178,7 +178,7 @@ struct dvb_frontend *lnbh25_attach(struct dvb_frontend
> *fe,
> fe->ops.release_sec = lnbh25_release;
> fe->ops.set_voltage = lnbh25_set_voltage;
>
> - dev_err(&i2c->dev, "%s(): attached at I2C addr 0x%02x\n",
> + dev_info(&i2c->dev, "%s(): attached at I2C addr 0x%02x\n",
> __func__, priv->i2c_address);
> return fe;
> }
> --
> 2.13.0
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
Re: [media-pci-cx25821] question about value overwrite
Hi Hans,
Quoting Hans Verkuil :
On 05/19/2017 12:07 AM, Gustavo A. R. Silva wrote:
Hello everybody,
While looking into Coverity ID 1226903 I ran into the following piece
of code at drivers/media/pci/cx25821/cx25821-medusa-video.c:393:
393int medusa_set_videostandard(struct cx25821_dev *dev)
394{
395int status = 0;
396u32 value = 0, tmp = 0;
397
398if (dev->tvnorm & V4L2_STD_PAL_BG || dev->tvnorm &
V4L2_STD_PAL_DK)
399status = medusa_initialize_pal(dev);
400else
401status = medusa_initialize_ntsc(dev);
402
403/* Enable DENC_A output */
404value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_A_REG_4, &tmp);
405value = setBitAtPos(value, 4);
406status = cx25821_i2c_write(&dev->i2c_bus[0],
DENC_A_REG_4, value);
407
408/* Enable DENC_B output */
409value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_B_REG_4, &tmp);
410value = setBitAtPos(value, 4);
411status = cx25821_i2c_write(&dev->i2c_bus[0],
DENC_B_REG_4, value);
412
413return status;
414}
The issue is that the value stored in variable _status_ at lines 399
and 401 is overwritten by the one stored at line 406 and then at line
411, before it can be used.
My question is if the original intention was to ORed the return
values, something like in the following patch:
index 0a9db05..226d14f 100644
--- a/drivers/media/pci/cx25821/cx25821-medusa-video.c
+++ b/drivers/media/pci/cx25821/cx25821-medusa-video.c
@@ -403,12 +403,12 @@ int medusa_set_videostandard(struct cx25821_dev *dev)
/* Enable DENC_A output */
value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_A_REG_4, &tmp);
value = setBitAtPos(value, 4);
- status = cx25821_i2c_write(&dev->i2c_bus[0], DENC_A_REG_4, value);
+ status |= cx25821_i2c_write(&dev->i2c_bus[0], DENC_A_REG_4, value);
/* Enable DENC_B output */
value = cx25821_i2c_read(&dev->i2c_bus[0], DENC_B_REG_4, &tmp);
value = setBitAtPos(value, 4);
- status = cx25821_i2c_write(&dev->i2c_bus[0], DENC_B_REG_4, value);
+ status |= cx25821_i2c_write(&dev->i2c_bus[0], DENC_B_REG_4, value);
return status;
}
This is a crappy driver, they just couldn't be bothered to check the
error from
cx25821_i2c_read/write.
Strictly speaking the return value should be checked after every
read/write and
returned in case of an error.
Yeah, the same happens in functions medusa_initialize_pal() and
medusa_initialize_ntsc()
Not sure whether it is worth the effort fixing this.
Thank you for your reply.
--
Gustavo A. R. Silva
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Hello Mauro! > Yeah, it would be great if Ralph would have some time to review > them, or to submit a new series adding all pending features from > DD drivers upstream. I am pretty sure he will not do that. > Both Jasmin and Thomas could have reviewed it, and replied > if they tested it, and on what conditions. I can't test this, I have only S2 cards here, sorry. I will not sign things, which I can't test. BR, Jasmin
[PATCH] [media] dvb-frontends/lnbh25: improve kernellog output
From: Daniel Scheller
Use dev_dbg() in conjunction with the %*ph format macro to print the vmon
status debug, thus hiding continuous hexdumping from default log levels.
Also, change the attach success log line from error to info severity.
Signed-off-by: Daniel Scheller
---
drivers/media/dvb-frontends/lnbh25.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/lnbh25.c
b/drivers/media/dvb-frontends/lnbh25.c
index ef3021e964be..cb486e879fdd 100644
--- a/drivers/media/dvb-frontends/lnbh25.c
+++ b/drivers/media/dvb-frontends/lnbh25.c
@@ -76,8 +76,8 @@ static int lnbh25_read_vmon(struct lnbh25_priv *priv)
return ret;
}
}
- print_hex_dump_bytes("lnbh25_read_vmon: ",
- DUMP_PREFIX_OFFSET, status, sizeof(status));
+ dev_dbg(&priv->i2c->dev, "%s(): %*ph\n",
+ __func__, (int) sizeof(status), status);
if ((status[0] & (LNBH25_STATUS_OFL | LNBH25_STATUS_VMON)) != 0) {
dev_err(&priv->i2c->dev,
"%s(): voltage in failure state, status reg 0x%x\n",
@@ -178,7 +178,7 @@ struct dvb_frontend *lnbh25_attach(struct dvb_frontend *fe,
fe->ops.release_sec = lnbh25_release;
fe->ops.set_voltage = lnbh25_set_voltage;
- dev_err(&i2c->dev, "%s(): attached at I2C addr 0x%02x\n",
+ dev_info(&i2c->dev, "%s(): attached at I2C addr 0x%02x\n",
__func__, priv->i2c_address);
return fe;
}
--
2.13.0
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Tue, 20 Jun 2017 20:41:21 +0200 Daniel Scheller escreveu: > Am Tue, 20 Jun 2017 09:36:45 -0300 > schrieb Mauro Carvalho Chehab : > > Hi Mauro, > > > Em Mon, 19 Jun 2017 22:18:21 +0200 > > Daniel Scheller escreveu: > > > > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge > > > support patches won't make it in time for the 4.13 merge window. > > > > There is time. I just merged this series today. > > Oh. Well, this, together with the other series, came as a (quite > positive) surprise this morning - thank you very very much! Anytime. Sorry again for taking a long time reviewing it. > > > The thing is that we currently have few developers working on > > DVB, and no sub-maintainers. Due to that, I need to review > > them myself, with I usually do after reviewing/applying patches > > from sub-maintainers. > > Understood. Though, and please don't get me wrong - Tearing apart and > under how things in the driver, the vendor driver package, the media and > DVB subsystem aswell as kernel parts, additionally aligning the > patches/commits with all remarks from previous submissions in mind took > quite some spare time for more than a year now, getting no responses at > all honestly started to get frustrating. Yes, I know how frustrating it can be. The real fix for this issue would be to get more people involved on dvb. > > > Also, unfortunately, the original owners and/or maintainers of the > > > affected drivers (besides cxd2841er), namely stv0367 and ddbridge, > > > either are MIA or not interested in reviewing or acking this. > > > > Yeah, it would be great if Ralph would have some time to review > > them, or to submit a new series adding all pending features from > > DD drivers upstream. > > This would of course be the way to go. OTOH, the in-kernel driver > already diverged quite a lot to that what DD publishes and maintains, > and lots of people agree this situation must be improved. Ralph went to a media summit we did in Germany a few years ago. At that time, it sounded that the way to go would be to submit a new version of the DD driver, based on upstream Kernel, and then DD start maintaining it for both DD internal tree and Kernel one. Unfortunately, he never had the required time for such task. We usually don't like this kind of change, as it is disruptive, with regards to bug fixes, but, if we do it only once, and, after that, go to the normal Kernel way, it could be not that bad. > > > I have plenty of more work (patches) done, all building upon this CT > > > and C2T2 hardware support, which - together with the work Jasmin has > > > done regarding the en50221 and cxd2099 support - would finally bring > > > the in-tree ddbridge driver on par with the package Digital Devices' > > > provides, having addressed most of the critics the previous > > > attempts to bump the driver received (incremental changes which are > > > more or less easy to review, from what can be done by tearing > > > tarballs without proper changelogs apart). > > > > Both Jasmin and Thomas could have reviewed it, and replied > > if they tested it, and on what conditions. I tend to give > > people some time to review/test patches, before doing my > > review, as I don't usually have time for testing everything > > myself. > > Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses > such cards. However, for upcoming patches, I'll try to drag people to > the list for some comments, thanks for the pointer. Yeah, if you can drag people to help reviewing/testing (and even coding), that would be really cool, as we'll be able to better do our reviews. > Speaking of patches and pending features (and generally syncing > drivers), this is what I plan to send to the list (in order, mostly > depending on each other): > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of > cards/modules. This mainly involves a new demod driver (stv0910) and > a new tuner driver (stv6111). Permissions for this are cleared with > Ralph already. The glue code needed in ddbridge is rather easy, and > as some ground work (mostly the MachXO2 support from the 2841 series) > is now in, the changes are quite small. Patches are ready so far but > need more cleanup (checkpatch fixes, camel case and such things). Please try to sync it with Ralph, in a way that his code won't diverge from the upstream one, as this will make easier for both sides to keep the Kernel in track with driver improvements. > > - The "big" ddbridge update. I'm thinking of two ways to do this: > > * Do this in one commit, being a huge code bump, bringing ddbridge to > version 0.9.28 (as per vendor versioning). This is mostly ready and > successful in use by many testers and in my Gentoo ddbridge kernel > sources overlay. Should get some more cleanups though (still some > GTL link bits left which are not needed), and all fixes which went > to the in-kernel driver like __user a
DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Am Tue, 20 Jun 2017 09:36:45 -0300 schrieb Mauro Carvalho Chehab : Hi Mauro, > Em Mon, 19 Jun 2017 22:18:21 +0200 > Daniel Scheller escreveu: > > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge > > support patches won't make it in time for the 4.13 merge window. > > There is time. I just merged this series today. Oh. Well, this, together with the other series, came as a (quite positive) surprise this morning - thank you very very much! > The thing is that we currently have few developers working on > DVB, and no sub-maintainers. Due to that, I need to review > them myself, with I usually do after reviewing/applying patches > from sub-maintainers. Understood. Though, and please don't get me wrong - Tearing apart and under how things in the driver, the vendor driver package, the media and DVB subsystem aswell as kernel parts, additionally aligning the patches/commits with all remarks from previous submissions in mind took quite some spare time for more than a year now, getting no responses at all honestly started to get frustrating. > > Also, unfortunately, the original owners and/or maintainers of the > > affected drivers (besides cxd2841er), namely stv0367 and ddbridge, > > either are MIA or not interested in reviewing or acking this. > > Yeah, it would be great if Ralph would have some time to review > them, or to submit a new series adding all pending features from > DD drivers upstream. This would of course be the way to go. OTOH, the in-kernel driver already diverged quite a lot to that what DD publishes and maintains, and lots of people agree this situation must be improved. > > I have plenty of more work (patches) done, all building upon this CT > > and C2T2 hardware support, which - together with the work Jasmin has > > done regarding the en50221 and cxd2099 support - would finally bring > > the in-tree ddbridge driver on par with the package Digital Devices' > > provides, having addressed most of the critics the previous > > attempts to bump the driver received (incremental changes which are > > more or less easy to review, from what can be done by tearing > > tarballs without proper changelogs apart). > > Both Jasmin and Thomas could have reviewed it, and replied > if they tested it, and on what conditions. I tend to give > people some time to review/test patches, before doing my > review, as I don't usually have time for testing everything > myself. Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses such cards. However, for upcoming patches, I'll try to drag people to the list for some comments, thanks for the pointer. Speaking of patches and pending features (and generally syncing drivers), this is what I plan to send to the list (in order, mostly depending on each other): - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of cards/modules. This mainly involves a new demod driver (stv0910) and a new tuner driver (stv6111). Permissions for this are cleared with Ralph already. The glue code needed in ddbridge is rather easy, and as some ground work (mostly the MachXO2 support from the 2841 series) is now in, the changes are quite small. Patches are ready so far but need more cleanup (checkpatch fixes, camel case and such things). - The "big" ddbridge update. I'm thinking of two ways to do this: * Do this in one commit, being a huge code bump, bringing ddbridge to version 0.9.28 (as per vendor versioning). This is mostly ready and successful in use by many testers and in my Gentoo ddbridge kernel sources overlay. Should get some more cleanups though (still some GTL link bits left which are not needed), and all fixes which went to the in-kernel driver like __user annotations need to be put back in. Big drawback: A mess to review. * Try to tear apart most if not all upstream vendor driver tar archives and recreate individual patches out of this. For reference, we need to go from what is in the kernel which is something inbetween v0.5 and v0.8 up to and including version 0.9.29. I'm currently working on this from time to time, and I can assure you that this is an extremely tedious and unthankful thing to do (currently nearly done with 0.9.9b, approx. 20 releases left). This might be better to review, but this will also result in something like 100-200 commits, without guarantee of having everything correct. Reviewers will hate me for this, but I'd personally prefer the first option (less work, verified working on quite some installs, less clutter in GIT, but the drawback of reviewability). - Last bit: DD MaxS4/S8 support. Requires another new demod driver (mxl5xx) and some more bits (not only glue code, but also some operation mode control and LNB handling) in ddbridge. Least work went into this so far an the mxl5xx driver code needs quite some cleanup. Note on the ddbridge update: This is mostly code refactoring and reorganisation, and fe
[PATCH 1/4] [media] dvb-frontends/stv0367: initial DDB DVBv5 stats, implement ucblocks
From: Daniel Scheller
This adds the basics to stv0367ddb_get_frontend() to be able to properly
provide signal statistics in DVBv5 format. Also adds UCB readout and
provides those values.
Signed-off-by: Daniel Scheller
---
drivers/media/dvb-frontends/stv0367.c | 59 ---
1 file changed, 55 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv0367.c
b/drivers/media/dvb-frontends/stv0367.c
index e726c2e00460..5374d4eaabd6 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -2997,21 +2997,64 @@ static int stv0367ddb_read_status(struct dvb_frontend
*fe,
return -EINVAL;
}
+static void stv0367ddb_read_ucblocks(struct dvb_frontend *fe)
+{
+ struct stv0367_state *state = fe->demodulator_priv;
+ struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+ u32 ucblocks = 0;
+
+ switch (state->activedemod) {
+ case demod_ter:
+ stv0367ter_read_ucblocks(fe, &ucblocks);
+ break;
+ case demod_cab:
+ stv0367cab_read_ucblcks(fe, &ucblocks);
+ break;
+ default:
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return;
+ }
+
+ p->block_error.stat[0].scale = FE_SCALE_COUNTER;
+ p->block_error.stat[0].uvalue = ucblocks;
+}
+
static int stv0367ddb_get_frontend(struct dvb_frontend *fe,
struct dtv_frontend_properties *p)
{
struct stv0367_state *state = fe->demodulator_priv;
+ int ret = -EINVAL;
+ enum fe_status status = 0;
switch (state->activedemod) {
case demod_ter:
- return stv0367ter_get_frontend(fe, p);
+ ret = stv0367ter_get_frontend(fe, p);
+ break;
case demod_cab:
- return stv0367cab_get_frontend(fe, p);
- default:
+ ret = stv0367cab_get_frontend(fe, p);
break;
+ default:
+ p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return ret;
}
- return -EINVAL;
+ /* read fe lock status */
+ if (!ret)
+ ret = stv0367ddb_read_status(fe, &status);
+
+ /* stop if get_frontend failed or if demod isn't locked */
+ if (ret || !(status & FE_HAS_LOCK)) {
+ p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return ret;
+ }
+
+ stv0367ddb_read_ucblocks(fe);
+
+ return 0;
}
static int stv0367ddb_sleep(struct dvb_frontend *fe)
@@ -3035,6 +3078,7 @@ static int stv0367ddb_sleep(struct dvb_frontend *fe)
static int stv0367ddb_init(struct stv0367_state *state)
{
struct stv0367ter_state *ter_state = state->ter_state;
+ struct dtv_frontend_properties *p = &state->fe.dtv_property_cache;
stv0367_writereg(state, R367TER_TOPCTRL, 0x10);
@@ -3109,6 +3153,13 @@ static int stv0367ddb_init(struct stv0367_state *state)
ter_state->first_lock = 0;
ter_state->unlock_counter = 2;
+ p->strength.len = 1;
+ p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->cnr.len = 1;
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ p->block_error.len = 1;
+ p->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
return 0;
}
--
2.13.0
[PATCH 0/4] STV0367/DDB DVBv5 signal statistics
From: Daniel Scheller This series adds DVBv5 statistics support to the new DDB codepath of the stv0367 demodulator driver. The changes utilise already existing functionality (in form of register readouts), but wraps the reads in separate functions so the existing relative scale reporting can be kept as-is, while adding the v5 stats in dB scale where appropriate. >From my own testing: Reported values look approx. the same as those reported by the cxd2841er driver for both -C and -T. Daniel Scheller (4): [media] dvb-frontends/stv0367: initial DDB DVBv5 stats, implement ucblocks [media] dvb-frontends/stv0367: split SNR determination into functions [media] dvb-frontends/stv0367: SNR DVBv5 statistics for DVB-C and T [media] dvb-frontends/stv0367: DVB-C signal strength statistics drivers/media/dvb-frontends/stv0367.c | 180 -- 1 file changed, 150 insertions(+), 30 deletions(-) -- 2.13.0
[PATCH 4/4] [media] dvb-frontends/stv0367: DVB-C signal strength statistics
From: Daniel Scheller
Provide QAM/DVB-C signal strength in decibel scale. Values returned from
stv0367cab_get_rf_lvl() are good but need to be multiplied as they're in
1dBm precision.
Signed-off-by: Daniel Scheller
---
drivers/media/dvb-frontends/stv0367.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/media/dvb-frontends/stv0367.c
b/drivers/media/dvb-frontends/stv0367.c
index 0b13a407df23..cf684ba70a3f 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -3018,6 +3018,25 @@ static int stv0367ddb_read_status(struct dvb_frontend
*fe,
return -EINVAL;
}
+static void stv0367ddb_read_signal_strength(struct dvb_frontend *fe)
+{
+ struct stv0367_state *state = fe->demodulator_priv;
+ struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+ s32 signalstrength;
+
+ switch (state->activedemod) {
+ case demod_cab:
+ signalstrength = stv0367cab_get_rf_lvl(state) * 1000;
+ break;
+ default:
+ p->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return;
+ }
+
+ p->strength.stat[0].scale = FE_SCALE_DECIBEL;
+ p->strength.stat[0].uvalue = signalstrength;
+}
+
static void stv0367ddb_read_snr(struct dvb_frontend *fe)
{
struct stv0367_state *state = fe->demodulator_priv;
@@ -3102,6 +3121,7 @@ static int stv0367ddb_get_frontend(struct dvb_frontend
*fe,
stv0367ddb_read_ucblocks(fe);
stv0367ddb_read_snr(fe);
+ stv0367ddb_read_signal_strength(fe);
return 0;
}
--
2.13.0
[PATCH 3/4] [media] dvb-frontends/stv0367: SNR DVBv5 statistics for DVB-C and T
From: Daniel Scheller
Add signal-to-noise-ratio as provided by the demodulator in decibel scale.
QAM/DVB-C needs some intlog calculation to have usable dB values, OFDM/
DVB-T values from the demod look alright already and are provided as-is.
Signed-off-by: Daniel Scheller
---
drivers/media/dvb-frontends/stv0367.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/media/dvb-frontends/stv0367.c
b/drivers/media/dvb-frontends/stv0367.c
index bb498f942ebd..0b13a407df23 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -25,6 +25,8 @@
#include
#include
+#include "dvb_math.h"
+
#include "stv0367.h"
#include "stv0367_defs.h"
#include "stv0367_regs.h"
@@ -33,6 +35,9 @@
/* Max transfer size done by I2C transfer functions */
#define MAX_XFER_SIZE 64
+/* snr logarithmic calc */
+#define INTLOG10X100(x) ((u32) (((u64) intlog10(x) * 100) >> 24))
+
static int stvdebug;
module_param_named(debug, stvdebug, int, 0644);
@@ -3013,6 +3018,33 @@ static int stv0367ddb_read_status(struct dvb_frontend
*fe,
return -EINVAL;
}
+static void stv0367ddb_read_snr(struct dvb_frontend *fe)
+{
+ struct stv0367_state *state = fe->demodulator_priv;
+ struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+ int cab_pwr;
+ u32 regval, tmpval, snrval = 0;
+
+ switch (state->activedemod) {
+ case demod_ter:
+ snrval = stv0367ter_snr_readreg(fe);
+ break;
+ case demod_cab:
+ cab_pwr = stv0367cab_snr_power(fe);
+ regval = stv0367cab_snr_readreg(fe, 0);
+
+ tmpval = (cab_pwr * 320) / regval;
+ snrval = ((tmpval != 0) ? INTLOG10X100(tmpval) : 0) * 100;
+ break;
+ default:
+ p->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ return;
+ }
+
+ p->cnr.stat[0].scale = FE_SCALE_DECIBEL;
+ p->cnr.stat[0].uvalue = snrval;
+}
+
static void stv0367ddb_read_ucblocks(struct dvb_frontend *fe)
{
struct stv0367_state *state = fe->demodulator_priv;
@@ -3069,6 +3101,7 @@ static int stv0367ddb_get_frontend(struct dvb_frontend
*fe,
}
stv0367ddb_read_ucblocks(fe);
+ stv0367ddb_read_snr(fe);
return 0;
}
--
2.13.0
[PATCH 2/4] [media] dvb-frontends/stv0367: split SNR determination into functions
From: Daniel Scheller
The read_snr() functions currently do some magic to return relative scale
values when called. Split out register readouts into separate functions
so the functionality can be reused in some other way.
Signed-off-by: Daniel Scheller
---
drivers/media/dvb-frontends/stv0367.c | 68 +--
1 file changed, 42 insertions(+), 26 deletions(-)
diff --git a/drivers/media/dvb-frontends/stv0367.c
b/drivers/media/dvb-frontends/stv0367.c
index 5374d4eaabd6..bb498f942ebd 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -1437,7 +1437,7 @@ static int stv0367ter_get_frontend(struct dvb_frontend
*fe,
return 0;
}
-static int stv0367ter_read_snr(struct dvb_frontend *fe, u16 *snr)
+static u32 stv0367ter_snr_readreg(struct dvb_frontend *fe)
{
struct stv0367_state *state = fe->demodulator_priv;
u32 snru32 = 0;
@@ -1453,10 +1453,16 @@ static int stv0367ter_read_snr(struct dvb_frontend *fe,
u16 *snr)
cpt++;
}
-
snru32 /= 10;/*average on 10 values*/
- *snr = snru32 / 1000;
+ return snru32;
+}
+
+static int stv0367ter_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ u32 snrval = stv0367ter_snr_readreg(fe);
+
+ *snr = snrval / 1000;
return 0;
}
@@ -2702,51 +2708,61 @@ static int stv0367cab_read_strength(struct dvb_frontend
*fe, u16 *strength)
return 0;
}
-static int stv0367cab_read_snr(struct dvb_frontend *fe, u16 *snr)
+static int stv0367cab_snr_power(struct dvb_frontend *fe)
{
struct stv0367_state *state = fe->demodulator_priv;
- u32 noisepercentage;
enum stv0367cab_mod QAMSize;
- u32 regval = 0, temp = 0;
- int power, i;
QAMSize = stv0367_readbits(state, F367CAB_QAM_MODE);
switch (QAMSize) {
case FE_CAB_MOD_QAM4:
- power = 21904;
- break;
+ return 21904;
case FE_CAB_MOD_QAM16:
- power = 20480;
- break;
+ return 20480;
case FE_CAB_MOD_QAM32:
- power = 23040;
- break;
+ return 23040;
case FE_CAB_MOD_QAM64:
- power = 21504;
- break;
+ return 21504;
case FE_CAB_MOD_QAM128:
- power = 23616;
- break;
+ return 23616;
case FE_CAB_MOD_QAM256:
- power = 21760;
- break;
- case FE_CAB_MOD_QAM512:
- power = 1;
- break;
+ return 21760;
case FE_CAB_MOD_QAM1024:
- power = 21280;
- break;
+ return 21280;
default:
- power = 1;
break;
}
+ return 1;
+}
+
+static int stv0367cab_snr_readreg(struct dvb_frontend *fe, int avgdiv)
+{
+ struct stv0367_state *state = fe->demodulator_priv;
+ u32 regval = 0;
+ int i;
+
for (i = 0; i < 10; i++) {
regval += (stv0367_readbits(state, F367CAB_SNR_LO)
+ 256 * stv0367_readbits(state, F367CAB_SNR_HI));
}
- regval /= 10; /*for average over 10 times in for loop above*/
+ if (avgdiv)
+ regval /= 10;
+
+ return regval;
+}
+
+static int stv0367cab_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ struct stv0367_state *state = fe->demodulator_priv;
+ u32 noisepercentage;
+ u32 regval = 0, temp = 0;
+ int power;
+
+ power = stv0367cab_snr_power(fe);
+ regval = stv0367cab_snr_readreg(fe, 1);
+
if (regval != 0) {
temp = power
* (1 << (3 + stv0367_readbits(state, F367CAB_SNR_PER)));
--
2.13.0
[PATCH] [media] ddbridge: use pr_* macros in favor of printk
From: Daniel Scheller
Side effect: KERN_DEBUG messages aren't written to the kernel log anymore.
This also improves the tda18212_ping reporting a bit so users know that if
pinging wasn't successful, bad things might happen.
Signed-off-by: Daniel Scheller
---
drivers/media/pci/ddbridge/ddbridge-core.c | 64 +++---
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 9420479bee9a..fff03a332e08 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -17,6 +17,8 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -124,10 +126,10 @@ static int ddb_i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32
cmd)
ddbwritel((adr << 9) | cmd, i2c->regs + I2C_COMMAND);
stat = wait_event_timeout(i2c->wq, i2c->done == 1, HZ);
if (stat == 0) {
- printk(KERN_ERR "I2C timeout\n");
+ pr_err("I2C timeout\n");
{ /* MSI debugging*/
u32 istat = ddbreadl(INTERRUPT_STATUS);
- printk(KERN_ERR "IRS %08x\n", istat);
+ pr_err("IRS %08x\n", istat);
ddbwritel(istat, INTERRUPT_ACK);
}
return -EIO;
@@ -533,7 +535,7 @@ static u32 ddb_input_avail(struct ddb_input *input)
off = (stat & 0x7ff) << 7;
if (ctrl & 4) {
- printk(KERN_ERR "IA %d %d %08x\n", idx, off, ctrl);
+ pr_err("IA %d %d %08x\n", idx, off, ctrl);
ddbwritel(input->stat, DMA_BUFFER_ACK(input->nr));
return 0;
}
@@ -619,7 +621,7 @@ static int demod_attach_drxk(struct ddb_input *input)
fe = input->fe = dvb_attach(drxk_attach, &config, i2c);
if (!input->fe) {
- printk(KERN_ERR "No DRXK found!\n");
+ pr_err("No DRXK found!\n");
return -ENODEV;
}
fe->sec_priv = input;
@@ -637,7 +639,7 @@ static int tuner_attach_tda18271(struct ddb_input *input)
input->fe->ops.i2c_gate_ctrl(input->fe, 1);
fe = dvb_attach(tda18271c2dd_attach, input->fe, i2c, 0x60);
if (!fe) {
- printk(KERN_ERR "No TDA18271 found!\n");
+ pr_err("No TDA18271 found!\n");
return -ENODEV;
}
if (input->fe->ops.i2c_gate_ctrl)
@@ -676,7 +678,7 @@ static int demod_attach_stv0367(struct ddb_input *input)
&ddb_stv0367_config[(input->nr & 1)], i2c);
if (!input->fe) {
- printk(KERN_ERR "stv0367ddb_attach failed (not found?)\n");
+ pr_err("stv0367ddb_attach failed (not found?)\n");
return -ENODEV;
}
@@ -693,14 +695,14 @@ static int tuner_tda18212_ping(struct ddb_input *input,
unsigned short adr)
u8 tda_id[2];
u8 subaddr = 0x00;
- printk(KERN_DEBUG "stv0367-tda18212 tuner ping\n");
+ pr_debug("stv0367-tda18212 tuner ping\n");
if (input->fe->ops.i2c_gate_ctrl)
input->fe->ops.i2c_gate_ctrl(input->fe, 1);
if (i2c_read_regs(adapter, adr, subaddr, tda_id, sizeof(tda_id)) < 0)
- printk(KERN_DEBUG "tda18212 ping 1 fail\n");
+ pr_debug("tda18212 ping 1 fail\n");
if (i2c_read_regs(adapter, adr, subaddr, tda_id, sizeof(tda_id)) < 0)
- printk(KERN_DEBUG "tda18212 ping 2 fail\n");
+ pr_warn("tda18212 ping failed, expect problems\n");
if (input->fe->ops.i2c_gate_ctrl)
input->fe->ops.i2c_gate_ctrl(input->fe, 0);
@@ -728,7 +730,7 @@ static int demod_attach_cxd28xx(struct ddb_input *input,
int par, int osc24)
input->fe = dvb_attach(cxd2841er_attach_t_c, &cfg, i2c);
if (!input->fe) {
- printk(KERN_ERR "No Sony CXD28xx found!\n");
+ pr_err("No Sony CXD28xx found!\n");
return -ENODEV;
}
@@ -786,7 +788,7 @@ static int tuner_attach_tda18212(struct ddb_input *input,
u32 porttype)
return 0;
err:
- printk(KERN_INFO "TDA18212 tuner not found. Device is not fully
operational.\n");
+ pr_warn("TDA18212 tuner not found. Device is not fully operational.\n");
return -ENODEV;
}
@@ -853,13 +855,13 @@ static int demod_attach_stv0900(struct ddb_input *input,
int type)
(input->nr & 1) ? STV090x_DEMODULATOR_1
: STV090x_DEMODULATOR_0);
if (!input->fe) {
- printk(KERN_ERR "No STV0900 found!\n");
+ pr_err("No STV0900 found!\n");
return -ENODEV;
}
if (!dvb_attach(lnbh24_attach, input->fe, i2c, 0,
0, (input->nr & 1) ?
(0x09 - type) : (0x0b - type))) {
- printk
[PATCH v4 0/4] Synopsys Designware HDMI Video Capture Controller + PHY
The Synopsys Designware HDMI RX controller is an HDMI receiver controller that is responsible to process digital data that comes from a phy. The final result is a stream of raw video data that can then be connected to a video DMA, for example, and transfered into RAM so that it can be displayed. The controller + phy available in this series natively support all HDMI 1.4 and HDMI 2.0 modes, including deep color. Although, the driver is quite in its initial stage and unfortunatelly only non deep color modes are supported. Also, audio is not yet supported in the driver (the controller has several audio output interfaces). Version 4 addresses review comments from Sylwester Nawrocki that were mainly regarding the phy initialization and bindings in the DT. We switched to V4L2 async API so that we don't have to wait for phy to be initialized. This series was tested in a FPGA platform. Jose Abreu (4): [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver [media] platform: Add Synopsys Designware HDMI RX Controller Driver MAINTAINERS: Add entry for Synopsys Designware HDMI drivers dt-bindings: media: Document Synopsys Designware HDMI RX Cc: Carlos Palminha Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Rob Herring Cc: Mark Rutland Cc: Sylwester Nawrocki .../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 70 + MAINTAINERS|7 + drivers/media/platform/Kconfig |2 + drivers/media/platform/Makefile|2 + drivers/media/platform/dwc/Kconfig | 23 + drivers/media/platform/dwc/Makefile|2 + drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 832 + drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 + drivers/media/platform/dwc/dw-hdmi-rx.c| 1862 drivers/media/platform/dwc/dw-hdmi-rx.h| 441 + include/media/dwc/dw-hdmi-phy-pdata.h | 128 ++ include/media/dwc/dw-hdmi-rx-pdata.h | 97 + 12 files changed, 3529 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt create mode 100644 drivers/media/platform/dwc/Kconfig create mode 100644 drivers/media/platform/dwc/Makefile create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h -- 1.9.1
[PATCH v4 1/4] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver
This adds support for the Synopsys Designware HDMI RX PHY e405. This phy receives and decodes HDMI video that is delivered to a controller. Main features included in this driver are: - Equalizer algorithm that chooses the phy best settings according to the detected HDMI cable characteristics. - Support for scrambling - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz). The driver was implemented as a standalone V4L2 subdevice and the phy interface with the controller was implemented using V4L2 ioctls. I do not know if this is the best option but it is not possible to use the existing API functions directly as we need specific functions that will be called by the controller at specific configuration stages. There is also a bidirectional communication between controller and phy: The phy must provide functions that the controller will call (i.e. configuration functions) and the controller must provide read/write callbacks, as well as other specific functions. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Changes from v3: - Use v4l2 async API (Sylwester) - Use clock API (Sylwester) - Add compatible string (Sylwester) Changes from RFC: - Remove a bunch of functions that can be collapsed into a single config() function - Add comments for the callbacks and structures (Hans) --- drivers/media/platform/Kconfig| 2 + drivers/media/platform/Makefile | 2 + drivers/media/platform/dwc/Kconfig| 8 + drivers/media/platform/dwc/Makefile | 1 + drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 832 ++ drivers/media/platform/dwc/dw-hdmi-phy-e405.h | 63 ++ include/media/dwc/dw-hdmi-phy-pdata.h | 128 7 files changed, 1036 insertions(+) create mode 100644 drivers/media/platform/dwc/Kconfig create mode 100644 drivers/media/platform/dwc/Makefile create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 1313cd5..47d4a50 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig" source "drivers/media/platform/blackfin/Kconfig" +source "drivers/media/platform/dwc/Kconfig" + config VIDEO_SH_VOU tristate "SuperH VOU video output driver" depends on MEDIA_CAMERA_SUPPORT diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 9beadc7..e6a55fb 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/ obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk-jpeg/ obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/ + +obj-y += dwc/ diff --git a/drivers/media/platform/dwc/Kconfig b/drivers/media/platform/dwc/Kconfig new file mode 100644 index 000..361d38d --- /dev/null +++ b/drivers/media/platform/dwc/Kconfig @@ -0,0 +1,8 @@ +config VIDEO_DWC_HDMI_PHY_E405 + tristate "Synopsys Designware HDMI RX PHY e405 driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + help + Support for Synopsys Designware HDMI RX PHY. Version is e405. + + To compile this driver as a module, choose M here. The module + will be called dw-hdmi-phy-e405. diff --git a/drivers/media/platform/dwc/Makefile b/drivers/media/platform/dwc/Makefile new file mode 100644 index 000..fc3b62c --- /dev/null +++ b/drivers/media/platform/dwc/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c new file mode 100644 index 000..d8856f6 --- /dev/null +++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c @@ -0,0 +1,832 @@ +/* + * Synopsys Designware HDMI PHY E405 driver + * + * This Synopsys dw-phy-e405 software and associated documentation + * (hereinafter the "Software") is an unsupported proprietary work of + * Synopsys, Inc. unless otherwise expressly agreed to in writing between + * Synopsys and you. The Software IS NOT an item of Licensed Software or a + * Licensed Product under any End User Software License Agreement or + * Agreement for Licensed Products with Synopsys or any supplement thereto. + * Synopsys is a registered trademark of Synopsys, Inc. Other names included + * in the SOFTWARE may be the trademarks of their respective owners. + * + * The contents of this file are dual-licensed; you may select either version 2 + * of the GNU General Public License (“GPL”) or the MIT license (“MIT”). + * + * Copyright (c) 2017 Synopsys, Inc. and/or its affiliates. + * + * THIS SOFTWARE IS PROVIDED "AS IS" WIT
[PATCH v4 3/4] MAINTAINERS: Add entry for Synopsys Designware HDMI drivers
Add a entry for Synopsys Designware HDMI Receivers drivers and phys. Signed-off-by: Jose Abreu Cc: Carlos Palminha --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c4be6d4..7ebc6dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11354,6 +11354,13 @@ L: net...@vger.kernel.org S: Supported F: drivers/net/ethernet/synopsys/ +SYNOPSYS DESIGNWARE HDMI RECEIVERS AND PHY DRIVERS +M: Jose Abreu +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/platform/dwc/* +F: include/media/dwc/* + SYNOPSYS DESIGNWARE I2C DRIVER M: Jarkko Nikula R: Andy Shevchenko -- 1.9.1
[PATCH v4 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver
This is an initial submission for the Synopsys Designware HDMI RX Controller Driver. This driver interacts with a phy driver so that a communication between them is created and a video pipeline is configured. The controller + phy pipeline can then be integrated into a fully featured system that can be able to receive video up to 4k@60Hz with deep color 48bit RGB, depending on the platform. Although, this initial version does not yet handle deep color modes. This driver was implemented as a standard V4L2 subdevice and its main features are: - Internal state machine that reconfigures phy until the video is not stable - JTAG communication with phy - Inter-module communication with phy driver - Debug write/read ioctls Some notes: - RX sense controller (cable connection/disconnection) must be handled by the platform wrapper as this is not integrated into the controller RTL - The same goes for EDID ROM's - ZCAL calibration is needed only in FPGA platforms, in ASIC this is not needed - The state machine is not an ideal solution as it creates a kthread but it is needed because some sources might not be very stable at sending the video (i.e. we must react accordingly). Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Sylwester Nawrocki Changes from v3: - Use v4l2 async API (Sylwester) - Do not block waiting for phy - Do not use busy waiting delays (Sylwester) - Simplify dw_hdmi_power_on (Sylwester) - Use clock API (Sylwester) - Use compatible string (Sylwester) - Minor fixes (Sylwester) Changes from v2: - Address review comments from Hans regarding CEC - Use CEC notifier - Enable SCDC Changes from v1: - Add support for CEC - Correct typo errors - Correctly detect interlaced video modes - Correct VIC parsing Changes from RFC: - Add support for HDCP 1.4 - Fixup HDMI_VIC not being parsed (Hans) - Send source change signal when powering off (Hans) - Add a "wait stable delay" - Detect interlaced video modes (Hans) - Restrain g/s_register from reading/writing to HDCP regs (Hans) --- drivers/media/platform/dwc/Kconfig | 15 + drivers/media/platform/dwc/Makefile |1 + drivers/media/platform/dwc/dw-hdmi-rx.c | 1862 +++ drivers/media/platform/dwc/dw-hdmi-rx.h | 441 include/media/dwc/dw-hdmi-rx-pdata.h| 97 ++ 5 files changed, 2416 insertions(+) create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.c create mode 100644 drivers/media/platform/dwc/dw-hdmi-rx.h create mode 100644 include/media/dwc/dw-hdmi-rx-pdata.h diff --git a/drivers/media/platform/dwc/Kconfig b/drivers/media/platform/dwc/Kconfig index 361d38d..3ddccde 100644 --- a/drivers/media/platform/dwc/Kconfig +++ b/drivers/media/platform/dwc/Kconfig @@ -6,3 +6,18 @@ config VIDEO_DWC_HDMI_PHY_E405 To compile this driver as a module, choose M here. The module will be called dw-hdmi-phy-e405. + +config VIDEO_DWC_HDMI_RX + tristate "Synopsys Designware HDMI Receiver driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + help + Support for Synopsys Designware HDMI RX controller. + + To compile this driver as a module, choose M here. The module + will be called dw-hdmi-rx. + +config VIDEO_DWC_HDMI_RX_CEC + bool + depends on VIDEO_DWC_HDMI_RX + select CEC_CORE + select CEC_NOTIFIER diff --git a/drivers/media/platform/dwc/Makefile b/drivers/media/platform/dwc/Makefile index fc3b62c..cd04ca9 100644 --- a/drivers/media/platform/dwc/Makefile +++ b/drivers/media/platform/dwc/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o +obj-$(CONFIG_VIDEO_DWC_HDMI_RX) += dw-hdmi-rx.o diff --git a/drivers/media/platform/dwc/dw-hdmi-rx.c b/drivers/media/platform/dwc/dw-hdmi-rx.c new file mode 100644 index 000..22ee51d --- /dev/null +++ b/drivers/media/platform/dwc/dw-hdmi-rx.c @@ -0,0 +1,1862 @@ +/* + * Synopsys Designware HDMI Receiver controller driver + * + * This Synopsys dw-hdmi-rx software and associated documentation + * (hereinafter the "Software") is an unsupported proprietary work of + * Synopsys, Inc. unless otherwise expressly agreed to in writing between + * Synopsys and you. The Software IS NOT an item of Licensed Software or a + * Licensed Product under any End User Software License Agreement or + * Agreement for Licensed Products with Synopsys or any supplement thereto. + * Synopsys is a registered trademark of Synopsys, Inc. Other names included + * in the SOFTWARE may be the trademarks of their respective owners. + * + * The contents of this file are dual-licensed; you may select either version 2 + * of the GNU General Public License (“GPL”) or the MI
[PATCH v4 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX
Document the bindings for the Synopsys Designware HDMI RX.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Rob Herring
Cc: Mark Rutland
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: Sylwester Nawrocki
Changes from v3:
- Document the new DT bindings suggested by Sylwester
Changes from v2:
- Document edid-phandle property
---
.../devicetree/bindings/media/snps,dw-hdmi-rx.txt | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
new file mode 100644
index 000..efb0ac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.txt
@@ -0,0 +1,70 @@
+Synopsys DesignWare HDMI RX Decoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+RX Decoder (DWC HDMI RX). It doesn't constitute a device tree binding
+specification by itself but is meant to be referenced by platform-specific
+device tree bindings.
+
+When referenced from platform device tree bindings the properties defined in
+this document are defined as follows.
+
+- compatible: Shall be "snps,dw-hdmi-rx".
+
+- reg: Memory mapped base address and length of the DWC HDMI RX registers.
+
+- interrupts: Reference to the DWC HDMI RX interrupt and 5v sense interrupt.
+
+- clocks: Phandle to the config clock block.
+
+- clock-names: Shall be "cfg-clk".
+
+- edid-phandle: phandle to the EDID handler block.
+
+- #address-cells: Shall be 1.
+
+- #size-cells: Shall be 0.
+
+You also have to create a subnode for phy driver. Phy properties are as
follows.
+
+- compatible: Shall be "snps,dw-hdmi-phy-e405".
+
+- reg: Shall be JTAG address of phy.
+
+- clocks: Phandle for cfg clock.
+
+- clock-names:Shall be "cfg-clk".
+
+A sample binding is now provided. The compatible string is for a SoC which has
+has a Synopsys Designware HDMI RX decoder inside.
+
+Example:
+
+dw_hdmi_soc: dw-hdmi-soc@0 {
+ compatible = "snps,dw-hdmi-soc";
+ reg = <0x11c00 0x1000>; /* EDIDs */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dw_hdmi_rx@0 {
+ compatible = "snps,dw-hdmi-rx";
+ reg = <0x0 0x1>;
+ interrupts = <1 2>;
+ edid-phandle = <&dw_hdmi_soc>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg-clk";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dw_hdmi_phy_e405@fc {
+ compatible = "snps,dw-hdmi-phy-e405";
+ reg = <0xfc>;
+
+ clocks = <&dw_hdmi_refclk>;
+ clock-names = "cfg-clk";
+ };
+ };
+};
--
1.9.1
Re: [PATCH v2 5/6] [media] s5p-jpeg: Add support for resolution change event
Hi Andrzej, On 20/06/2017 12:51, Andrzej Pietrasiewicz wrote: Hi Thierry, W dniu 19.06.2017 o 15:50, Thierry Escande pisze: Hi Andrzej, On 16/06/2017 17:38, Andrzej Pietrasiewicz wrote: Hi Thierry, Thank you for the patch. Can you give a use case for resolution change event? Unfortunately, the original commit does not mention any clear use case. I've asked to the patch author for more information. Can you please share what you learn about it if the author gets back to you? Now that we don't know why to apply a patch I guess we should not do it. This event is used in Chromium by the V4L2 jpeg decode accelerator to allocate output buffer. Please see: https://cs.chromium.org/chromium/src/media/gpu/v4l2_jpeg_decode_accelerator.cc?rcl=91793c6ef94f05e93d258db8c7f3cad59819c6b8&l=585 I'll add a note in the commit message. @@ -2510,43 +2567,18 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb) return; } -q_data = &ctx->out_q; -q_data->w = tmp.w; -q_data->h = tmp.h; -q_data->sos = tmp.sos; -memcpy(q_data->dht.marker, tmp.dht.marker, - sizeof(tmp.dht.marker)); -memcpy(q_data->dht.len, tmp.dht.len, sizeof(tmp.dht.len)); -q_data->dht.n = tmp.dht.n; -memcpy(q_data->dqt.marker, tmp.dqt.marker, - sizeof(tmp.dqt.marker)); -memcpy(q_data->dqt.len, tmp.dqt.len, sizeof(tmp.dqt.len)); -q_data->dqt.n = tmp.dqt.n; -q_data->sof = tmp.sof; -q_data->sof_len = tmp.sof_len; - -q_data = &ctx->cap_q; -q_data->w = tmp.w; -q_data->h = tmp.h; Why is this part removed? This has not been removed. The &tmp s5p_jpeg_q_data struct was passed to s5p_jpeg_parse_hdr() and then copied field-by-field into ctx->out_q (through q_data pointer). With this change ctx->out_q is passed to s5p_jpeg_parse_hdr() and this avoids the copy. It seems that changing field-by-field copying to passing a pointer directly to s5p_jpeg_parse_hdr() is an unrelated change and as such should be in a separate patch. Will do. Regards, Thierry
Re: [git:media_tree/master] foo
Em Tue, 20 Jun 2017 11:19:56 + Mauro Carvalho Chehab escreveu: > This is an automatic generated email to let you know that the following patch > were queued: > > Subject: foo > Author: Mauro Carvalho Chehab > Date:Tue Jun 20 08:19:56 2017 -0300 This one was just to see if people are paying atention... It turns that people were, as I got two reports already about it! :-D Seriously, I was doing a test with gcc warnings, before writing a real fix for double const. Once I noticed I merged it by mistake, I folded it with the right fix and rebased, before applying other patches at the tree. So, hopefully, no harm done (except that sfr pulled from my tree on that time, so, we may have some noise on today's -next). Thanks, Mauro
Re: [PATCH 2/2] media/uapi/v4l: clarify cropcap/crop/selection behavior
On 06/19/2017 03:49 PM, Hans Verkuil wrote: From: Hans Verkuil Unfortunately the use of 'type' was inconsistent for multiplanar buffer types. Starting with 4.14 both the normal and _MPLANE variants are allowed, thus making it possible to write sensible code. Yes, we messed up:-( Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki -- Thanks, Sylwester
[PATCH v2] media: venus: enable building with COMPILE_TEST
We want all media drivers to build with COMPILE_TEST, as the Coverity instance we use on Kernel works only for x86. Also, our test workflow relies on it, in order to identify git bisect breakages. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Stanimir Varbanov --- Changes since v1: - select QCOM_MDT_LOADER and QCOM_SCM conditionally. drivers/media/platform/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 6027dbd4e04d..b7381a4722e2 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -467,8 +467,9 @@ config VIDEO_TI_VPE_DEBUG config VIDEO_QCOM_VENUS tristate "Qualcomm Venus V4L2 encoder/decoder driver" depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA - depends on ARCH_QCOM && IOMMU_DMA - select QCOM_MDT_LOADER + depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST + select QCOM_MDT_LOADER if (ARM || ARM64) + select QCOM_SCM if (ARM || ARM64) select VIDEOBUF2_DMA_SG select V4L2_MEM2MEM_DEV ---help--- -- 2.7.4
Re: [PATCH] [media] davinci/dm644x: work around ccdc_update_raw_params trainwreck
Hi Arnd, Thanks for the patch. On Fri, Jun 9, 2017 at 10:36 PM, Arnd Bergmann wrote: > Now that the davinci drivers can be enabled in compile tests on other > architectures, I ran into this warning on a 64-bit build: > > drivers/media/platform/davinci/dm644x_ccdc.c: In function > 'ccdc_update_raw_params': > drivers/media/platform/davinci/dm644x_ccdc.c:279:7: error: cast to pointer > from integer of different size [-Werror=int-to-pointer-cast] > > While that looks fairly harmless (it would be fine on 32-bit), it was > just the tip of the iceberg: > > - The function constantly mixes up pointers and phys_addr_t numbers > - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is > described as an 'experimental ioctl that will change in future kernels', > but if we have users that probably won't happen. > - The code to allocate the table never gets called after we copy_from_user > the user input over the kernel settings, and then compare them > for inequality. > - We then go on to use an address provided by user space as both the > __user pointer for input and pass it through phys_to_virt to come up > with a kernel pointer to copy the data to. This looks like a trivially > exploitable root hole. > > This patch disables all the obviously broken code, by zeroing out the > sensitive data provided by user space. I also fix the type confusion > here. If we think the ioctl has no stable users, we could consider > just removing it instead. > I suspect there shouldn’t be possible users of this IOCTL, better of removing the IOCTL itself. Sekhar your call, as the latest PSP releases for 644x use the media controller framework. Cheers, --Prabhakar Lad
Re: [PATCH v2] [media] davinci: vpif: adaptions for DT support
On Fri, Jun 9, 2017 at 5:10 PM, Kevin Hilman wrote: > The davinci VPIF is a single hardware block, but the existing driver > is broken up into a common library (vpif.c), output (vpif_display.c) and > intput (vpif_capture.c). > > When migrating to DT, to better model the hardware, and because > registers, interrupts, etc. are all common,it was decided to > have a single VPIF hardware node[1]. > > Because davinci uses legacy, non-DT boot on several SoCs still, the > platform_drivers need to remain. But they are also needed in DT boot. > Since there are no DT nodes for the display/capture parts in DT > boot (there is a single node for the parent/common device) we need to > create platform_devices somewhere to instansiate the platform_drivers. > > When VPIF display/capture are needed for a DT boot, the VPIF node > will have endpoints defined for its subdevs. Therefore, vpif_probe() > checks for the presence of endpoints, and if detected manually creates > the platform_devices for the display and capture platform_drivers. > > [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt > > Signed-off-by: Kevin Hilman Acked-by: Lad, Prabhakar Cheers, --Prabhakar Lad
Re: [GIT PULL FOR v4.13] Add qcom venus driver
Hi Mauro, On 06/20/2017 02:59 PM, Mauro Carvalho Chehab wrote: > Em Fri, 16 Jun 2017 10:19:46 +0200 > Hans Verkuil escreveu: > >> Hi Mauro, >> >> Second attempt to add the venus driver. >> >> Regards, >> >> Hans >> >> The following changes since commit acec3630155763c170c7ae6508cf973355464508: >> >>[media] s3c-camif: fix arguments position in a function call (2017-06-13 >> 14:21:24 -0300) >> >> are available in the git repository at: >> >>git://linuxtv.org/hverkuil/media_tree.git venus >> >> for you to fetch changes up to 3bf1c3aacb172db8fcbd25c62b042fc265c5a494: >> >>media: venus: enable building with COMPILE_TEST (2017-06-16 09:59:36 >> +0200) >> >> >> Stanimir Varbanov (19): >>media: v4l2-mem2mem: extend m2m APIs for more accurate buffer >> management >>doc: DT: venus: binding document for Qualcomm video driver >>MAINTAINERS: Add Qualcomm Venus video accelerator driver >>media: venus: adding core part and helper functions >>media: venus: vdec: add video decoder files >>media: venus: venc: add video encoder files >>media: venus: hfi: add Host Firmware Interface (HFI) >>media: venus: hfi: add Venus HFI files >>media: venus: enable building of Venus video driver >>media: venus: hfi: fix mutex unlock >>media: venus: hfi_cmds: fix variable dereferenced before check >>media: venus: helpers: fix variable dereferenced before check >>media: venus: hfi_venus: fix variable dereferenced before check >>media: venus: hfi_msgs: fix set but not used variables >>media: venus: vdec: fix compile error in vdec_close >>media: venus: venc: fix compile error in venc_close >>media: venus: vdec: add support for min buffers for capture >>media: venus: update firmware path with linux-firmware place > > >>media: venus: enable building with COMPILE_TEST > > It is too early for this patch. I merged from 4.12-rc6, and it > still complains about those missing symbols: > > WARNING: "qcom_scm_is_available" > [drivers/media/platform/qcom/venus/venus-core.ko] undefined! > WARNING: "qcom_scm_pas_shutdown" > [drivers/media/platform/qcom/venus/venus-core.ko] undefined! > WARNING: "qcom_scm_set_remote_state" > [drivers/media/platform/qcom/venus/venus-core.ko] undefined! > > Probably, some patch is needed somewhere to replace those functions > by stubs if not the right arch, in order to make it build with > COMPILE_TEST. > > For now, I'm excluding this patch on today's pull. It seems that the patch for the qcom_scm will be delayed, so I have to fix this in the Venus Kconfig, which doesn't seem too bad because we want to allow compile test for the venus driver itself not for its dependencies. diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index f9bbba5c5dd6..b7381a4722e2 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -468,7 +468,8 @@ config VIDEO_QCOM_VENUS tristate "Qualcomm Venus V4L2 encoder/decoder driver" depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST - select QCOM_MDT_LOADER + select QCOM_MDT_LOADER if (ARM || ARM64) + select QCOM_SCM if (ARM || ARM64) select VIDEOBUF2_DMA_SG select V4L2_MEM2MEM_DEV ---help--- So if you are fine with the above change I can cook a patch? -- regards, Stan
Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware
Em Mon, 19 Jun 2017 22:18:21 +0200 Daniel Scheller escreveu: > Am Sun, 28 May 2017 23:45:37 +0200 > schrieb Daniel Scheller : > > > Am Sun, 7 May 2017 17:42:12 +0200 > > schrieb Daniel Scheller : > > > > > Am Wed, 12 Apr 2017 21:23:27 +0200 > > > schrieb Daniel Scheller : > > > > > > > Am Wed, 29 Mar 2017 18:43:00 +0200 > > > > schrieb Daniel Scheller : > > > > > > > > > From: Daniel Scheller > > > > > > > > > > Third iteration of the DD CineCTv6/FlexCT support patches with > > > > > mostly all things cleaned up that popped up so far. Obsoletes V1 > > > > > and V2 series. > > > > > > > > > > These patches enhance the functionality of dvb-frontends/stv0367 > > > > > to work with Digital Devices hardware driven by the ST STV0367 > > > > > demodulator chip and adds probe & attach bits to ddbridge to > > > > > make use of them, effectively enabling full support for > > > > > CineCTv6 PCIe bridges and (older) DuoFlex CT addon > > > > > modules. > > > > > > > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really > > > > like to get this upstreamed. > > > > > > Don't want to sound impatient, but V1 nears nine weeks, so: Second > > > Ping. > > > > Friendly third time Ping on this - Really, I'd like to have this > > merged so those quite aging (but still fine) DD CineCTv6 boards > > finally are supported without having to install out-of-tree drivers > > which even break the V4L-DVB subsystem... > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge > support patches won't make it in time for the 4.13 merge window. There is time. I just merged this series today. The thing is that we currently have few developers working on DVB, and no sub-maintainers. Due to that, I need to review them myself, with I usually do after reviewing/applying patches from sub-maintainers. > Also, unfortunately, the original owners and/or maintainers of the > affected drivers (besides cxd2841er), namely stv0367 and ddbridge, > either are MIA or not interested in reviewing or acking this. Yeah, it would be great if Ralph would have some time to review them, or to submit a new series adding all pending features from DD drivers upstream. > I have plenty of more work (patches) done, all building upon this CT > and C2T2 hardware support, which - together with the work Jasmin has > done regarding the en50221 and cxd2099 support - would finally bring > the in-tree ddbridge driver on par with the package Digital Devices' > provides, having addressed most of the critics the previous attempts to > bump the driver received (incremental changes which are more or less > easy to review, from what can be done by tearing tarballs without > proper changelogs apart). Both Jasmin and Thomas could have reviewed it, and replied if they tested it, and on what conditions. I tend to give people some time to review/test patches, before doing my review, as I don't usually have time for testing everything myself. > > The original series of this will be four(!) months old soon :/ > > Is there anything wrong with this? How to proceed with this? > > (Cc Hans since you also seem to be reviewing patches) Hans is focused at V4L2 side. > > That said, fourth ping. Btw, while you're here, it would be great if you could take a look on those warnings (that comes via smatch): drivers/media/pci/ddbridge/ddbridge-core.c:1009 input_tasklet() warn: this loop depends on readl() succeeding drivers/media/pci/ddbridge/ddbridge-core.c:1353 flashio() warn: this loop depends on readl() succeeding drivers/media/pci/ddbridge/ddbridge-core.c:1373 flashio() warn: this loop depends on readl() succeeding Regards, Mauro
Re: Shawn Guo: your attetion is needed here Re: [PATCH v8 00/34] i.MX Media Driver
On Tue 2017-06-20 08:05:05, Fabio Estevam wrote: > On Tue, Jun 20, 2017 at 5:29 AM, Pavel Machek wrote: > > > Hmm. I changed the subject to grab Shawn's attetion. > > > > But his acks should not be needed for forward progress. Yes, it would > > be good, but he does not react -- so just reorder the series so that > > dts changes come last, then apply the parts you can apply: driver can > > go in. > > > > And actually... if maintainer does not respond at all, there are ways > > to deal with that, too... > > Shawn has already applied the dts part of the series and they show up > in linux-next. Aha, sorry about the noise. I see videomux parts being merged by Mauro. Good :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [GIT PULL FOR v4.13] Add qcom venus driver
Em Fri, 16 Jun 2017 10:19:46 +0200 Hans Verkuil escreveu: > Hi Mauro, > > Second attempt to add the venus driver. > > Regards, > > Hans > > The following changes since commit acec3630155763c170c7ae6508cf973355464508: > >[media] s3c-camif: fix arguments position in a function call (2017-06-13 > 14:21:24 -0300) > > are available in the git repository at: > >git://linuxtv.org/hverkuil/media_tree.git venus > > for you to fetch changes up to 3bf1c3aacb172db8fcbd25c62b042fc265c5a494: > >media: venus: enable building with COMPILE_TEST (2017-06-16 09:59:36 +0200) > > > Stanimir Varbanov (19): >media: v4l2-mem2mem: extend m2m APIs for more accurate buffer > management >doc: DT: venus: binding document for Qualcomm video driver >MAINTAINERS: Add Qualcomm Venus video accelerator driver >media: venus: adding core part and helper functions >media: venus: vdec: add video decoder files >media: venus: venc: add video encoder files >media: venus: hfi: add Host Firmware Interface (HFI) >media: venus: hfi: add Venus HFI files >media: venus: enable building of Venus video driver >media: venus: hfi: fix mutex unlock >media: venus: hfi_cmds: fix variable dereferenced before check >media: venus: helpers: fix variable dereferenced before check >media: venus: hfi_venus: fix variable dereferenced before check >media: venus: hfi_msgs: fix set but not used variables >media: venus: vdec: fix compile error in vdec_close >media: venus: venc: fix compile error in venc_close >media: venus: vdec: add support for min buffers for capture >media: venus: update firmware path with linux-firmware place >media: venus: enable building with COMPILE_TEST It is too early for this patch. I merged from 4.12-rc6, and it still complains about those missing symbols: WARNING: "qcom_scm_is_available" [drivers/media/platform/qcom/venus/venus-core.ko] undefined! WARNING: "qcom_scm_pas_shutdown" [drivers/media/platform/qcom/venus/venus-core.ko] undefined! WARNING: "qcom_scm_set_remote_state" [drivers/media/platform/qcom/venus/venus-core.ko] undefined! Probably, some patch is needed somewhere to replace those functions by stubs if not the right arch, in order to make it build with COMPILE_TEST. For now, I'm excluding this patch on today's pull. Thanks, Mauro
Re: [PATCH v2 4/6] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format
Hi Thierry, W dniu 12.06.2017 o 19:13, Thierry Escande pisze: From: Tony K Nadackal This patch adds support for decoding 4:1:1 chroma subsampling in the jpeg header parsing function. Signed-off-by: Tony K Nadackal Signed-off-by: Thierry Escande --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c index 0d935f5..7ef7173 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c @@ -1236,6 +1236,9 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result, case 0x33: ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY; break; + case 0x41: + ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_411; + break; Merely parsing 4:1:1 subsampling is not enough. Now the s5p_jpeg_parse_hdr() sometimes returns false, among others it does so when unsupported subsampling is encountered in the header. As far as I know 4:1:1 is supported only on some variants (3250, 5420, 5433) of the hardware, so the kind of change intended by the patch author must take hardware variants into account. In the above function ctx is available, so accessing hardware variant information is possible. The s5p_jpeg_parse_hdr() is a lengthy function, so probably the switch (subsampling) part should be factored out to a separate function and extended appropriately. Andrzej
[GIT PULL 4.13] af9015/af9013 changes
The following changes since commit 3622d3e77ecef090b5111e3c5423313f11711dfa: [media] ov2640: print error if devm_*_optional*() fails (2017-04-25 07:08:21 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git af9015_pull for you to fetch changes up to 2a32db020ab01e3ac99febad90a42112aa28b2ee: af9013: refactor power control (2017-06-18 05:42:25 +0300) Antti Palosaari (15): af9015: use correct 7-bit i2c addresses af9013: move config values directly under driver state af9013: add i2c client bindings af9013: use kernel 64-bit division af9013: fix logging af9013: convert to regmap api af9013: fix error handling af9013: add dvbv5 cnr af9015: fix and refactor i2c adapter algo logic af9015: enable 2nd TS flow control when dual mode af9013: add configurable TS output pin af9013: remove unneeded register writes af9015: move 2nd demod power-up wait different location af9013: refactor firmware download routine af9013: refactor power control Gustavo A. R. Silva (1): af9013: add check on af9013_wr_regs() return value drivers/media/dvb-frontends/Kconfig |1 + drivers/media/dvb-frontends/af9013.c | 1185 ++- drivers/media/dvb-frontends/af9013.h | 86 +-- drivers/media/dvb-frontends/af9013_priv.h |2 + drivers/media/usb/dvb-usb-v2/af9015.c | 198 +--- drivers/media/usb/dvb-usb-v2/af9015.h |4 +- 6 files changed, 752 insertions(+), 724 deletions(-) -- http://palosaari.fi/
[PATCH] [media] ov13858: remove duplicated const declaration
As reported by gcc:
drivers/media/i2c/ov13858.c:953:20: warning: duplicate const
drivers/media/i2c/ov13858.c:953:14: warning: duplicate 'const' declaration
specifier [-Wduplicate-decl-specifier]
static const const s64 link_freq_menu_items[OV13858_NUM_OF_LINK_FREQS] = {
^
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/i2c/ov13858.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
index 7ebcf6763866..86550d8ddfee 100644
--- a/drivers/media/i2c/ov13858.c
+++ b/drivers/media/i2c/ov13858.c
@@ -950,7 +950,7 @@ static const char * const ov13858_test_pattern_menu[] = {
#define OV13858_LINK_FREQ_INDEX_1 1
/* Menu items for LINK_FREQ V4L2 control */
-static const s64 const link_freq_menu_items[OV13858_NUM_OF_LINK_FREQS] = {
+static const s64 link_freq_menu_items[OV13858_NUM_OF_LINK_FREQS] = {
OV13858_LINK_FREQ_1080MBPS,
OV13858_LINK_FREQ_540MBPS
};
--
2.9.4
Re: [PATCH v2 10/19] media: camss: Enable building
Hi,
(for everyone's information:)
This error is caused by a missing patch [1] which is needed by this patchset.
The relevant patch has been reviewed and accepted but merging was delayed
until there is a driver actually using the formats which the patch adds.
I'll include the relevant patch in my next version of the patchset so we
will avoid this error next time.
[1]
https://git.linuxtv.org/sailus/media_tree.git/commit/?h=packed12-postponed&id=549c02da6eed8dc4566632a9af9233bf99ba99d8
Best regards,
Todor
On 06/20/2017 01:30 PM, kbuild test robot wrote:
> Hi Todor,
>
> [auto build test ERROR on linuxtv-media/master]
> [also build test ERROR on v4.12-rc6 next-20170620]
> [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/Todor-Tomov/Qualcomm-8x16-Camera-Subsystem-driver/20170620-132806
> base: git://linuxtv.org/media_tree.git master
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 6.2.0
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/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=ia64
>
> All errors (new ones prefixed by >>):
>
>>> drivers/media/platform/qcom/camss-8x16/video.c:53:32: error:
>>> 'V4L2_PIX_FMT_SRGGB12P' undeclared here (not in a function)
> { MEDIA_BUS_FMT_SBGGR12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 },
>^
>>> drivers/media/platform/qcom/camss-8x16/video.c:54:32: error:
>>> 'V4L2_PIX_FMT_SGBRG12P' undeclared here (not in a function)
> { MEDIA_BUS_FMT_SGBRG12_1X12, V4L2_PIX_FMT_SGBRG12P, 12 },
>^
>>> drivers/media/platform/qcom/camss-8x16/video.c:55:32: error:
>>> 'V4L2_PIX_FMT_SGRBG12P' undeclared here (not in a function)
> { MEDIA_BUS_FMT_SGRBG12_1X12, V4L2_PIX_FMT_SGRBG12P, 12 },
>^
>
> vim +/V4L2_PIX_FMT_SRGGB12P +53 drivers/media/platform/qcom/camss-8x16/video.c
>
> 58991044 Todor Tomov 2017-06-19 47 { MEDIA_BUS_FMT_SGRBG8_1X8,
> V4L2_PIX_FMT_SGRBG8, 8 },
> 58991044 Todor Tomov 2017-06-19 48 { MEDIA_BUS_FMT_SRGGB8_1X8,
> V4L2_PIX_FMT_SRGGB8, 8 },
> 58991044 Todor Tomov 2017-06-19 49 { MEDIA_BUS_FMT_SBGGR10_1X10,
> V4L2_PIX_FMT_SBGGR10P, 10 },
> 58991044 Todor Tomov 2017-06-19 50 { MEDIA_BUS_FMT_SGBRG10_1X10,
> V4L2_PIX_FMT_SGBRG10P, 10 },
> 58991044 Todor Tomov 2017-06-19 51 { MEDIA_BUS_FMT_SGRBG10_1X10,
> V4L2_PIX_FMT_SGRBG10P, 10 },
> 58991044 Todor Tomov 2017-06-19 52 { MEDIA_BUS_FMT_SRGGB10_1X10,
> V4L2_PIX_FMT_SRGGB10P, 10 },
> 58991044 Todor Tomov 2017-06-19 @53 { MEDIA_BUS_FMT_SBGGR12_1X12,
> V4L2_PIX_FMT_SRGGB12P, 12 },
> 58991044 Todor Tomov 2017-06-19 @54 { MEDIA_BUS_FMT_SGBRG12_1X12,
> V4L2_PIX_FMT_SGBRG12P, 12 },
> 58991044 Todor Tomov 2017-06-19 @55 { MEDIA_BUS_FMT_SGRBG12_1X12,
> V4L2_PIX_FMT_SGRBG12P, 12 },
> 58991044 Todor Tomov 2017-06-19 56 { MEDIA_BUS_FMT_SRGGB12_1X12,
> V4L2_PIX_FMT_SRGGB12P, 12 }
> 58991044 Todor Tomov 2017-06-19 57 };
> 58991044 Todor Tomov 2017-06-19 58
>
> :: The code at line 53 was first introduced by commit
> :: 589910444c8d657c5d9992f6ebf1c0bf5a75e68a media: camss: Add files which
> handle the video device nodes
>
> :: TO: Todor Tomov
> :: CC: 0day robot
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
--
Best regards,
Todor Tomov
Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors
> One thing I was able to determine is that it appears to be related to > Intel VT-d/VT-x or whatever Intel's IOMMU/x86 virtualisation tech > thing is called. > > I tried the card in a different older Intel i7 board and it worked > flawlessly. I then started to wonder if it was some new > incompatibility introduced with Kaby Lake. I had tweaked the UEFI > settings on the new Kaby Lake board to enable VT-d/VT-x since I wanted > to run Linux as a host OS with Windows 10 running on top of qemu/KVM. > Upon resetting the UEFI settings to their defaults (VT-d/VT-x > disabled) the card worked without issue. Nice follow up, thx. That probably explains why I never saw the issues during my testing a few weeks ago then. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: Shawn Guo: your attetion is needed here Re: [PATCH v8 00/34] i.MX Media Driver
On Tue, Jun 20, 2017 at 5:29 AM, Pavel Machek wrote: > Hmm. I changed the subject to grab Shawn's attetion. > > But his acks should not be needed for forward progress. Yes, it would > be good, but he does not react -- so just reorder the series so that > dts changes come last, then apply the parts you can apply: driver can > go in. > > And actually... if maintainer does not respond at all, there are ways > to deal with that, too... Shawn has already applied the dts part of the series and they show up in linux-next.
Re: [PATCH 1/2] v4l2-ioctl/exynos: fix G/S_SELECTION's type handling
On 06/19/2017 03:49 PM, Hans Verkuil wrote: From: Hans Verkuil The type field in struct v4l2_selection is supposed to never use the _MPLANE variants. E.g. if the driver supports V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, then userspace should still pass V4L2_BUF_TYPE_VIDEO_CAPTURE. The reasons for this are lost in the mists of time, but it is really annoying. In addition, the exynos drivers didn't follow this rule and instead expected the _MPLANE type. To fix that code is added to the v4l2 core that maps the _MPLANE buffer types to their regular equivalents before calling the driver. Effectively this allows for userspace to use either _MPLANE or the regular buffer type. This keeps backwards compatibility while making things easier for userspace. Since drivers now never see the _MPLANE buffer types the exynos drivers had to be adapted as well. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Acked-by: Sylwester Nawrocki -- Thanks, Sylwester
Re: [PATCH v2 5/6] [media] s5p-jpeg: Add support for resolution change event
Hi Thierry, W dniu 19.06.2017 o 15:50, Thierry Escande pisze: Hi Andrzej, On 16/06/2017 17:38, Andrzej Pietrasiewicz wrote: Hi Thierry, Thank you for the patch. Can you give a use case for resolution change event? Unfortunately, the original commit does not mention any clear use case. I've asked to the patch author for more information. Can you please share what you learn about it if the author gets back to you? Now that we don't know why to apply a patch I guess we should not do it. @@ -2510,43 +2567,18 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb) return; } -q_data = &ctx->out_q; -q_data->w = tmp.w; -q_data->h = tmp.h; -q_data->sos = tmp.sos; -memcpy(q_data->dht.marker, tmp.dht.marker, - sizeof(tmp.dht.marker)); -memcpy(q_data->dht.len, tmp.dht.len, sizeof(tmp.dht.len)); -q_data->dht.n = tmp.dht.n; -memcpy(q_data->dqt.marker, tmp.dqt.marker, - sizeof(tmp.dqt.marker)); -memcpy(q_data->dqt.len, tmp.dqt.len, sizeof(tmp.dqt.len)); -q_data->dqt.n = tmp.dqt.n; -q_data->sof = tmp.sof; -q_data->sof_len = tmp.sof_len; - -q_data = &ctx->cap_q; -q_data->w = tmp.w; -q_data->h = tmp.h; Why is this part removed? This has not been removed. The &tmp s5p_jpeg_q_data struct was passed to s5p_jpeg_parse_hdr() and then copied field-by-field into ctx->out_q (through q_data pointer). With this change ctx->out_q is passed to s5p_jpeg_parse_hdr() and this avoids the copy. It seems that changing field-by-field copying to passing a pointer directly to s5p_jpeg_parse_hdr() is an unrelated change and as such should be in a separate patch. Andrzej
Re: [PATCH v2 10/19] media: camss: Enable building
Hi Todor,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.12-rc6 next-20170620]
[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/Todor-Tomov/Qualcomm-8x16-Camera-Subsystem-driver/20170620-132806
base: git://linuxtv.org/media_tree.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/01org/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=ia64
All errors (new ones prefixed by >>):
>> drivers/media/platform/qcom/camss-8x16/video.c:53:32: error:
>> 'V4L2_PIX_FMT_SRGGB12P' undeclared here (not in a function)
{ MEDIA_BUS_FMT_SBGGR12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 },
^
>> drivers/media/platform/qcom/camss-8x16/video.c:54:32: error:
>> 'V4L2_PIX_FMT_SGBRG12P' undeclared here (not in a function)
{ MEDIA_BUS_FMT_SGBRG12_1X12, V4L2_PIX_FMT_SGBRG12P, 12 },
^
>> drivers/media/platform/qcom/camss-8x16/video.c:55:32: error:
>> 'V4L2_PIX_FMT_SGRBG12P' undeclared here (not in a function)
{ MEDIA_BUS_FMT_SGRBG12_1X12, V4L2_PIX_FMT_SGRBG12P, 12 },
^
vim +/V4L2_PIX_FMT_SRGGB12P +53 drivers/media/platform/qcom/camss-8x16/video.c
58991044 Todor Tomov 2017-06-19 47 { MEDIA_BUS_FMT_SGRBG8_1X8,
V4L2_PIX_FMT_SGRBG8, 8 },
58991044 Todor Tomov 2017-06-19 48 { MEDIA_BUS_FMT_SRGGB8_1X8,
V4L2_PIX_FMT_SRGGB8, 8 },
58991044 Todor Tomov 2017-06-19 49 { MEDIA_BUS_FMT_SBGGR10_1X10,
V4L2_PIX_FMT_SBGGR10P, 10 },
58991044 Todor Tomov 2017-06-19 50 { MEDIA_BUS_FMT_SGBRG10_1X10,
V4L2_PIX_FMT_SGBRG10P, 10 },
58991044 Todor Tomov 2017-06-19 51 { MEDIA_BUS_FMT_SGRBG10_1X10,
V4L2_PIX_FMT_SGRBG10P, 10 },
58991044 Todor Tomov 2017-06-19 52 { MEDIA_BUS_FMT_SRGGB10_1X10,
V4L2_PIX_FMT_SRGGB10P, 10 },
58991044 Todor Tomov 2017-06-19 @53 { MEDIA_BUS_FMT_SBGGR12_1X12,
V4L2_PIX_FMT_SRGGB12P, 12 },
58991044 Todor Tomov 2017-06-19 @54 { MEDIA_BUS_FMT_SGBRG12_1X12,
V4L2_PIX_FMT_SGBRG12P, 12 },
58991044 Todor Tomov 2017-06-19 @55 { MEDIA_BUS_FMT_SGRBG12_1X12,
V4L2_PIX_FMT_SGRBG12P, 12 },
58991044 Todor Tomov 2017-06-19 56 { MEDIA_BUS_FMT_SRGGB12_1X12,
V4L2_PIX_FMT_SRGGB12P, 12 }
58991044 Todor Tomov 2017-06-19 57 };
58991044 Todor Tomov 2017-06-19 58
:: The code at line 53 was first introduced by commit
:: 589910444c8d657c5d9992f6ebf1c0bf5a75e68a media: camss: Add files which
handle the video device nodes
:: TO: Todor Tomov
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3 2/4] [media] platform: Add Synopsys Designware HDMI RX Controller Driver
HI Sylwester,
On 19-06-2017 23:10, Sylwester Nawrocki wrote:
> On 06/19/2017 11:33 AM, Jose Abreu wrote:
>> On 18-06-2017 19:04, Sylwester Nawrocki wrote:
>>> On 06/16/2017 06:38 PM, Jose Abreu wrote:
This is an initial submission for the Synopsys Designware HDMI RX
Controller Driver. This driver interacts with a phy driver so that
a communication between them is created and a video pipeline is
configured.
The controller + phy pipeline can then be integrated into a fully
featured system that can be able to receive video up to 4k@60Hz
with deep color 48bit RGB, depending on the platform. Although,
this initial version does not yet handle deep color modes.
Signed-off-by: Jose Abreu
+static int dw_hdmi_phy_init(struct dw_hdmi_dev *dw_dev)
+{
+ request_module(pdevinfo.name);
+
+ dw_dev->phy_pdev = platform_device_register_full(&pdevinfo);
+ if (IS_ERR(dw_dev->phy_pdev)) {
+ dev_err(dw_dev->dev, "failed to register phy device\n");
+ return PTR_ERR(dw_dev->phy_pdev);
+ }
+
+ if (!dw_dev->phy_pdev->dev.driver) {
+ dev_err(dw_dev->dev, "failed to initialize phy driver\n");
+ goto err;
+ }
>>> I think this is not safe because there is nothing preventing unbinding
>>> or unloading the driver at this point.
>>>
+ if (!try_module_get(dw_dev->phy_pdev->dev.driver->owner)) {
>>> So dw_dev->phy_pdev->dev.driver may be already NULL here.
>> How can I make sure it wont be NULL? Because I've seen other
>> media drivers do this and I don't think they do any kind of
>> locking, but they do this mainly for I2C subdevs.
> You could do device_lock(dev)/device_unlock(dev) to avoid possible races.
> And setting 'suppress_bind_attrs' field in the sub-device drivers would
> disable sysfs unbind attributes, so sub-device driver wouldn't get unbound
> unexpectedly trough sysfs.
Hmm, ok. I changed this, now I'm using driver_find() +
driver_for_each_device(). Its working but I'm starting to think
about whether this should go into v4l2 core because I've seen
other drivers also do this.
>
+ dev_err(dw_dev->dev, "failed to get phy module\n");
+ goto err;
+ }
+
+ dw_dev->phy_sd = dev_get_drvdata(&dw_dev->phy_pdev->dev);
+ if (!dw_dev->phy_sd) {
+ dev_err(dw_dev->dev, "failed to get phy subdev\n");
+ goto err_put;
+ }
+
+ if (v4l2_device_register_subdev(&dw_dev->v4l2_dev, dw_dev->phy_sd)) {
+ dev_err(dw_dev->dev, "failed to register phy subdev\n");
+ goto err_put;
+ }
>>> I'd suggest usign v4l2-async API, so we use a common pattern for sub-device
>>> registration. And with recent change [1] you could handle this PHY subdev
>>> in a standard way. That might be more complicated than it is now but should
>>> make any future platform integration easier.
>> So I will instantiate phy driver and then wait for phy driver to
>> register into v4l2 core?
> Yes, for instance the RX controller driver registers a notifier, instantiates
> the child PHY device and then waits until the PHY driver completes
> initialization.
>
+ module_put(dw_dev->phy_pdev->dev.driver->owner);
+ return 0;
+
+err_put:
+ module_put(dw_dev->phy_pdev->dev.driver->owner);
+err:
+ platform_device_unregister(dw_dev->phy_pdev);
+ return -EINVAL;
+}
+static int dw_hdmi_power_on(struct dw_hdmi_dev *dw_dev, u32 input)
+{
+ struct dw_hdmi_work_data *data;
+ unsigned long flags;
+
+ data = devm_kzalloc(dw_dev->dev, sizeof(*data), GFP_KERNEL);
>>> Why use devm_{kzalloc, kfree} when dw_hdmi_power_on() is not only called
>>> in the device's probe() callback, but in other places, including interrupt
>>> handler? devm_* API is normally used when life time of a resource is more
>>> or less equal to life time of struct device or its matched driver. Were
>>> there any specific reasons to not just use kzalloc()/kfree() ?
>> No specific reason, I just thought it would be safer because if I
>> cancel a work before it started then memory will remain
>> allocated. But I will change to kzalloc().
> OK, I overlooked such situation. Since you allow one job queued maybe
> just embed struct work_struct in struct dw_hdmi_dev and retrieve it with
> container_of() macro in the work handler and use additional field in
> struct dw_hdmi_dev protected with dw_dev->lock for passing the input
> index?
Yes, seems ok. As I'm already locking before queuing work and
also checking if theres is a pending work I can just overwrite
configured_input earlier.
Best regards,
Jose Miguel Abreu
>
+ if (!data)
+ return -ENOMEM;
+
+ INIT_WORK(&data->work, dw_hdmi_work_handler);
+ data->dw_dev = dw_dev;
+ data->input = input;
+
+ spin_lock_irqsave(&dw_dev->lock, flags);
+ if
[PATCH] [media] max2175: remove an useless comparision
load is an unsigned integer. So, it is always bigger or equal
to zero, as reported by gcc:
drivers/media/i2c/max2175.c: In function 'max2175_refout_load_to_bits':
drivers/media/i2c/max2175.c:1272:11: warning: comparison of unsigned
expression >= 0 is always true [-Wtype-limits]
if (load >= 0 && load <= 40)
^~
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/i2c/max2175.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/max2175.c b/drivers/media/i2c/max2175.c
index 0d28a80f8ed2..a4736a8a7792 100644
--- a/drivers/media/i2c/max2175.c
+++ b/drivers/media/i2c/max2175.c
@@ -1269,7 +1269,7 @@ static const struct v4l2_ctrl_config max2175_na_rx_mode =
{
static int max2175_refout_load_to_bits(struct i2c_client *client, u32 load,
u32 *bits)
{
- if (load >= 0 && load <= 40)
+ if (load <= 40)
*bits = load / 10;
else if (load >= 60 && load <= 70)
*bits = load / 10 - 1;
--
2.9.4
Re: [PATCH v3 4/4] dt-bindings: media: Document Synopsys Designware HDMI RX
Hi Sylwester,
On 19-06-2017 22:18, Sylwester Nawrocki wrote:
> On 06/19/2017 11:01 AM, Jose Abreu wrote:
>> Using fixed-clock was already in my todo list. Regarding phy I
>> need to pass pdata so that the callbacks between controller and
>> phy are established. I also need to make sure that phy driver
>> will be loaded by the controller driver. Hmm, and also address of
>> the phy on th JTAG bus is fed to the controller driver not to the
>> phy driver. Maybe leave the property as is (the
>> "snps,hdmi-phy-jtag-addr") or parse it from the phy node?
> I think the RX controller can parse it's child phy node to retrieve JTAG
> address from the reg property. That seems better than creating custom
> property for device address on the bus.
Ok, will do that.
>
> Does the PHY support any other type of control bus, e.g. I2C or SPI?
It supports I2C but its all done by controller regbank.
>
>> I also need to pass pdata to the controller driver (the callbacks
>> for 5v handling) which are agnostic of the controller. These
> Is this about detecting +5V coming from the HDMI connector? Or some
> other voltage supply?
Yes, 5v signal from HDMI source.
>
>> reasons prevented me from adding compatible strings to both
>> drivers and just use a wrapper driver instead. This way i do
> If you add struct of_device_id instance to your module and define
> MODULE_DEVICE_ALIAS(of, ...) there, it will allow the module to be loaded
> when device with matching compatible string is created in the kernel.
> User space is notified with uevent about device creation.
Hmm, I used another approach. I have a list of supported phys in
the controller driver and the corresponding driver name, then I
just match the node, get the driver name and do a request module
the of_platform_populate. Maybe its not the best option?
>
>> "modprobe wrapper_driver" and I get all the drivers loaded via
>> request_module(). Still, I like your approach much better. I saw
>> that I can pass pdata using of_platform_populate, could you
>> please confirm if I can still maintain this architecture (i.e.
>> prevent modules from loading until I get all the chain setup)?
> You could try to pass platform data this way, that should work. But
> I doubt it's the right directions, I would rather see things done
> in the V4L2 layer.
But this doesn't exist right? We would need something similar to
v4l2_i2c_new_subdev_board() but for platform devices.
>
>> Following your approach I could get something like this:
>>
>> hdmi_system@ {
>> compatible = "snps,dw-hdmi-rx-wrapper";
> This would need to refer to some hardware block, we should avoid virtual
> device nodes in DT.
By wrapper I mean the SoC, i.e. the whole integration of the
controller + phy + EDID + 5v + ...
>
>> reg = <0x 0x>;
>> interrupts = <3>;
>> #address-cells = <1>;
>> #size-cells = <1>;
> You would need also an (empty) 'ranges' property here.
Yes, I already added it here locally.
>
>> hdmi_controller@0 {
>> compatible = "snps,dw-hdmi-rx-controller";
>> reg = <0x0 0x1>;
>> interrupts = <1>;
>> edid-phandle = <&hdmi_system>;
>> clocks = <&refclk>;
>> clock-names = "ref-clk";
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> hdmi_phy@f3 {
>> compatible = "snps,dw-hdmi-phy-e405";
>> reg = <0xf3>;
>> clocks = <&cfgclk>;
>> clock-names = "cfg-clk";
>> }
>> }
>> };
>>
>> And then snps,dw-hdmi-rx-wrapper would call of_platform_populate
>> for controller which would instead call of_platform_populate for
>> phy. Is this possible, and maintainable? Isn't the controller
>> driver get auto loaded because of the compatible string match?
> As I mentioned above, auto loading should work if you have instance
> of MODULE_DEVICE_TABLE() defined in the module, but the module might
> not be available immediately after creating devices with
> of_platform_populate(). You may want to have a look at the v4l2-async
> API (drivers/media/v4l2-core/v4l2-async.c). It allows one driver
> to register a notifier for its sub-devices. And the parent driver
> can complete initialization when it gets all its v4l2 subdevs
> registered.
>
> But I'm not sure about calls from the PHY back to the RX controller,
> possibly v4l2_set_subdev_hostdata()/v4l2_get_subdev_hostdata() could
> be used for passing the ops.
Ok, I will move to the async API then.
>
>> And one more thing: The reg address of the hdmi_controller: Isn't
>> this relative to the parent node? I mean isn't this going to be
>> 0x + 0x0? Because I don't want that :/
> Address space of child nodes doesn't need to be relative to 'reg' range
> of parent node, these can be entirely distinct address ranges. See for
> example I2C bus controllers, the I2C addresses of slave devices are not
> much related to the memory mapped IO registers region of the bus controller.
Yes, I a
Shawn Guo: your attetion is needed here Re: [PATCH v8 00/34] i.MX Media Driver
Hi! > >> But as Pavel pointed out, in fact we are missing many > >> Acks still, for all of the dts source changes (patches > >> 4-14), as well as really everything else (imx-media staging > >> driver patches). > > > > No Acks needed for the staging part. It's staging, so not held > > to the same standards as non-staging parts. That doesn't mean > > Acks aren't welcome, of course. > > Acks are wanted for particular i.MX DTS changes including device > tree binding descriptions. > > Shawn, please bless the series. Hmm. I changed the subject to grab Shawn's attetion. But his acks should not be needed for forward progress. Yes, it would be good, but he does not react -- so just reorder the series so that dts changes come last, then apply the parts you can apply: driver can go in. And actually... if maintainer does not respond at all, there are ways to deal with that, too... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
