linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: "Andrey Utkin" <andrey.utkin@corp.bluecherry.net>,
	"Mauro Carvalho Chehab" <mchehab@osg.samsung.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Bluecherry Maintainers" <maintainers@bluecherrydvr.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Kalle Valo" <kvalo@codeaurora.org>,
	"Jiri Slaby" <jslaby@suse.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Kozlov Sergey" <serjk@netup.ru>,
	"Ezequiel Garcia" <ezequiel@vanguardiasur.com.ar>,
	"Hans Verkuil" <hans.verkuil@cisco.com>,
	"Krzysztof Hałasa" <khalasa@piap.pl>
Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	devel@driverdev.osuosl.org, linux-pci@vger.kernel.org,
	kernel-mentors@selenic.com,
	Andrey Utkin <andrey_utkin@fastmail.com>
Subject: Re: [PATCH v4] [media] pci: Add tw5864 driver
Date: Mon, 11 Jul 2016 09:40:53 -0700	[thread overview]
Message-ID: <1468255253.8360.142.camel@perches.com> (raw)
In-Reply-To: <20160711151714.5452-1-andrey.utkin@corp.bluecherry.net>

On Mon, 2016-07-11 at 18:17 +0300, Andrey Utkin wrote:
[]
> diff --git a/drivers/media/pci/tw5864/tw5864-core.c b/drivers/media/pci/tw5864/tw5864-core.c
[]
> +static const char * const artifacts_warning =
> +"BEWARE OF KNOWN ISSUES WITH VIDEO QUALITY\n"
> +"\n"
> +"This driver was developed by Bluecherry LLC by deducing behaviour of\n"
> +"original manufacturer's driver, from both source code and execution traces.\n"
> +"It is known that there are some artifacts on output video with this driver:\n"
> +" - on all known hardware samples: random pixels of wrong color (mostly\n"
> +"   white, red or blue) appearing and disappearing on sequences of P-frames;\n"
> +" - on some hardware samples (known with H.264 core version e006:2800):\n"
> +"   total madness on P-frames: blocks of wrong luminance; blocks of wrong\n"
> +"   colors \"creeping\" across the picture.\n"
> +"There is a workaround for both issues: avoid P-frames by setting GOP size\n"
> +"to 1. To do that, run this command on device files created by this driver:\n"
> +"\n"
> +"v4l2-ctl --device /dev/videoX --set-ctrl=video_gop_size=1\n"
> +"\n";
> +
> +static char *artifacts_warning_continued =
> +"These issues are not decoding errors; all produced H.264 streams are decoded\n"
> +"properly. Streams without P-frames don't have these artifacts so it's not\n"
> +"analog-to-digital conversion issues nor internal memory errors; we conclude\n"
> +"it's internal H.264 encoder issues.\n"
> +"We cannot even check the original driver's behaviour because it has never\n"
> +"worked properly at all in our development environment. So these issues may\n"
> +"be actually related to firmware or hardware. However it may be that there's\n"
> +"just some more register settings missing in the driver which would please\n"
> +"the hardware.\n"
> +"Manufacturer didn't help much on our inquiries, but feel free to disturb\n"
> +"again the support of Intersil (owner of former Techwell).\n"
> +"\n";
[]
> +static int tw5864_initdev(struct pci_dev *pci_dev,
> +			  const struct pci_device_id *pci_id)
> +{
[]
> +	dev_warn(&pci_dev->dev, "%s", artifacts_warning);
> +	dev_warn(&pci_dev->dev, "%s", artifacts_warning_continued);

Is all that verbosity useful?

And trivially:

Each of these blocks will start with the dev_<level> prefix
and the subsequent lines will not have the same prefix

Perhaps it'd be better to write this something like:

static const char * const artifacts_warning[] = {
	"BEWARE OF KNOWN ISSUES WITH VIDEO QUALITY",
	"",
	"This driver was developed by Bluecherry LLC by deducing behaviour of",
	"original manufacturer's driver, from both source code and execution traces.",
	"It is known that there are some artifacts on output video with this driver:",
	" - on all known hardware samples: random pixels of wrong color (mostly",
	"   white, red or blue) appearing and disappearing on sequences of P-frames;",
	" - on some hardware samples (known with H.264 core version e006:2800):",
	"   total madness on P-frames: blocks of wrong luminance; blocks of wrong",
	"   colors \"creeping\" across the picture.",
	"There is a workaround for both issues: avoid P-frames by setting GOP size",
	"to 1. To do that, run this command on device files created by this driver:",
	"",
	"v4l2-ctl --device /dev/videoX --set-ctrl=video_gop_size=1",
	"",
	"These issues are not decoding errors; all produced H.264 streams are decoded",
	"properly. Streams without P-frames don't have these artifacts so it's not",
	"analog-to-digital conversion issues nor internal memory errors; we conclude",
	"it's internal H.264 encoder issues.",
	"We cannot even check the original driver's behaviour because it has never",
	"worked properly at all in our development environment. So these issues may",
	"be actually related to firmware or hardware. However it may be that there's",
	"just some more register settings missing in the driver which would please",
	"the hardware.",
	"Manufacturer didn't help much on our inquiries, but feel free to disturb",
	"again the support of Intersil (owner of former Techwell).\n"
};

and use

	for (i = 0; i < ARRAY_SIZE(artifacts_warning), i++)
		dev_warn(&pci_dev->dev, %s\n", artifacts_warning[i]);

so that each line is prefixed.

It also might be better to issue something like a single
line dev_warn referring to the driver code and just leave
this comment in the driver sources.

Something like:

	dev_warn(&pci_dev->dev,
		"This driver has known defects in video quality\n");


  reply	other threads:[~2016-07-11 16:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-11 15:17 [PATCH v4] [media] pci: Add tw5864 driver Andrey Utkin
2016-07-11 16:40 ` Joe Perches [this message]
2016-07-13  1:56   ` Andrey Utkin
2016-07-13  2:05 ` [PATCH v4] [media] pci: Add tw5864 driver - fixed few style nits, going to resubmit soon Andrey Utkin
2016-07-13  7:05   ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1468255253.8360.142.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrey.utkin@corp.bluecherry.net \
    --cc=andrey_utkin@fastmail.com \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hans.verkuil@cisco.com \
    --cc=jslaby@suse.com \
    --cc=kernel-mentors@selenic.com \
    --cc=khalasa@piap.pl \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=maintainers@bluecherrydvr.com \
    --cc=mchehab@osg.samsung.com \
    --cc=serjk@netup.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).