Re: [PATCH v2 18/31] gp8psk: don't do DMA on stack

[Johannes Stezenbach]

On Sun, Nov 06, 2016 at 11:51:14AM -0800, VDR User wrote:
> I applied this patch to the 4.8.4 kernel driver (that I'm currently
> running) and it caused nothing but "frontend 0/0 timed out while
> tuning". Is there another patch that should be used in conjunction
> with this? If not, this patch breaks the gp8psk driver.
> 
> Thanks.

Thanks for testing.  "If it's not tested it's broken"...

> On Tue, Oct 11, 2016 at 3:09 AM, Mauro Carvalho Chehab
>  wrote:

> > index 5d0384dd45b5..fa215ad37f7b 100644
> > --- a/drivers/media/usb/dvb-usb/gp8psk.c
> > +++ b/drivers/media/usb/dvb-usb/gp8psk.c

> >  int gp8psk_usb_in_op(struct dvb_usb_device *d, u8 req, u16 value, u16 
> > index, u8 *b, int blen)
> >  {
> > +   struct gp8psk_state *st = d->priv;
> > int ret = 0,try = 0;
> >
> > if ((ret = mutex_lock_interruptible(>usb_mutex)))
> > return ret;
> >
> > while (ret >= 0 && ret != blen && try < 3) {
> > +   memcpy(st->data, b, blen);
> > ret = usb_control_msg(d->udev,
> > usb_rcvctrlpipe(d->udev,0),
> > req,
> > USB_TYPE_VENDOR | USB_DIR_IN,
> > -   value,index,b,blen,
> > +   value, index, st->data, blen,
> > 2000);

I guess for usb_in the memcpy should be after the usb_control_msg
and from st->data to b.

Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Staging: media: radio-bcm2048: Fix alignment issues

[Johannes Stezenbach]

On Wed, Oct 19, 2016 at 07:17:12PM +0200, Jean-Baptiste Abbadie wrote:
> Signed-off-by: Jean-Baptiste Abbadie 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index 188d045d44ad..f66bea631e8e 100644
> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> @@ -997,7 +997,7 @@ static int bcm2048_set_fm_search_tune_mode(struct 
> bcm2048_device *bdev,
>   timeout = BCM2048_AUTO_SEARCH_TIMEOUT;
>  
>   if (!wait_for_completion_timeout(>compl,
> - msecs_to_jiffies(timeout)))
> +  msecs_to_jiffies(timeout)))
>   dev_err(>client->dev, "IRQ timeout.\n");
>  
>   if (value)
> @@ -2202,7 +2202,7 @@ static ssize_t bcm2048_fops_read(struct file *file, 
> char __user *buf,
>   }
>   /* interruptible_sleep_on(>read_queue); */
>   if (wait_event_interruptible(bdev->read_queue,
> - bdev->rds_data_available) < 0) {
> +  bdev->rds_data_available) < 0) {

FWIW, a better Subject: would be "fix indentation" because
"alignment issue" usually means some address not
aligned to some border.

HTH,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

[Johannes Stezenbach]

On Tue, Oct 11, 2016 at 07:09:17AM -0300, Mauro Carvalho Chehab wrote:
> --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> @@ -41,6 +41,8 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  
>  struct cinergyt2_state {
>   u8 rc_counter;
> + unsigned char data[64];
> + struct mutex data_mutex;
>  };

Sometimes my thinking is slow but it just occured to me
that this creates a potential issue with cache line sharing.
On an architecture which manages cache coherence in software
(ARM, MIPS etc.) a write to e.g. rc_counter in this example
would dirty the cache line, and a later writeback from the
cache could overwrite parts of data[] which was received via DMA.
In contrast, if the DMA buffer is allocated seperately via
kmalloc it is guaranteed to be safe wrt cache line sharing.
(see bottom of Documentation/DMA-API-HOWTO.txt).

But of course DMA on stack also had the same issue
and no one ever noticed so it's apparently not critical...


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with VMAP_STACK=y

[Johannes Stezenbach]

On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote:
>  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>  {
> - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> - char state[3];
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
>   int ret;
>  
>   adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>  
> - ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
> - sizeof(state), 0);

it seems to miss this:

st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;

> + ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
>   if (ret < 0) {
>   deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
>   "state info\n");
> @@ -141,13 +147,14 @@ static int repeatable_keys[] = {
>  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int 
> *state)
>  {
>   struct cinergyt2_state *st = d->priv;
> - u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
>   int i;
>  
>   *state = REMOTE_NO_KEY_PRESSED;
>  
> - dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> - if (key[4] == 0xff) {
> + st->data[0] = CINERGYT2_EP1_SLEEP_MODE;

should probably be

st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;

> +
> + dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);


HTH,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Johannes Stezenbach]

On Mon, Mar 07, 2016 at 12:29:08AM +0100, Johannes Stezenbach wrote:
> On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> > 
> > I converted one of the big tables to CSV. At least now it recognized
> > it as a table. Yet, the table was very badly formated:
> > 
> > https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
> > 
> > This is how this table should look like:
> > https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
> > 
> > Also, as this table has merged cells at the legend. I've no idea how
> > to tell sphinx to do that on csv format.
> > 
> > The RST files are on this git tree:
> > https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/
> 
> Yeah, seems it can't do merged cells in csv.  Attached patch converts it
> back to grid table format and fixes the table definition.
> The html output looks usable, but clearly it is no fun to
> work with tables in Sphinx.
> 
> Sphinx' latex writer can't handle nested tables, though.
> Python's docutils rst2latex can, but that doesn't help here.
> rst2pdf also supports it.  But I have doubts such a large
> table would render OK in pdf without using landscape orientation.
> I have not tried because I used python3-sphinx but rst2pdf
> is only availble for Python2 in Debian so it does not integrate
> with Sphinx.

Just a quick idea:
Perhaps one alternative would be to use Graphviz to render
the problematic tables, it supports a HTML-like syntax
and can be embedded in Spinx documents:

http://www.sphinx-doc.org/en/stable/ext/graphviz.html
http://www.graphviz.org/content/node-shapes#html
http://stackoverflow.com/questions/13890568/graphviz-html-nested-tables


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Johannes Stezenbach]

On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote:
> 
> I converted one of the big tables to CSV. At least now it recognized
> it as a table. Yet, the table was very badly formated:
>   
> https://mchehab.fedorapeople.org/media-kabi-docs-test/rst_tests/packed-rgb.html
> 
> This is how this table should look like:
>   https://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html
> 
> Also, as this table has merged cells at the legend. I've no idea how
> to tell sphinx to do that on csv format.
> 
> The RST files are on this git tree:
>   https://git.linuxtv.org/mchehab/v4l2-docs-poc.git/

Yeah, seems it can't do merged cells in csv.  Attached patch converts it
back to grid table format and fixes the table definition.
The html output looks usable, but clearly it is no fun to
work with tables in Sphinx.

Sphinx' latex writer can't handle nested tables, though.
Python's docutils rst2latex can, but that doesn't help here.
rst2pdf also supports it.  But I have doubts such a large
table would render OK in pdf without using landscape orientation.
I have not tried because I used python3-sphinx but rst2pdf
is only availble for Python2 in Debian so it does not integrate
with Sphinx.


Johannes
>From 61674b398e778bd5ff644ffd493d5ff1cfaca0ef Mon Sep 17 00:00:00 2001
From: Johannes Stezenbach <j...@sig21.net>
Date: Sun, 6 Mar 2016 23:55:19 +0100
Subject: [PATCH] some progress for html output

---
 _static/borderless.css |  3 --
 _static/v4l2tables.css |  9 +
 _templates/layout.html |  9 +
 packed-rgb.rst | 88 +-
 pixfmt-yuyv.rst|  2 +-
 v4l-table-within-table.rst | 72 +++--
 6 files changed, 105 insertions(+), 78 deletions(-)
 delete mode 100644 _static/borderless.css
 create mode 100644 _static/v4l2tables.css

diff --git a/_static/borderless.css b/_static/borderless.css
deleted file mode 100644
index bfd4b01..000
--- a/_static/borderless.css
+++ /dev/null
@@ -1,3 +0,0 @@
-table#table-borderless {
-border: 1px solid black;
-}
diff --git a/_static/v4l2tables.css b/_static/v4l2tables.css
new file mode 100644
index 000..c045e45
--- /dev/null
+++ b/_static/v4l2tables.css
@@ -0,0 +1,9 @@
+table.noborder {
+border: 1px solid black;
+background: white;
+white-space: nowrap;
+}
+
+table.noborder td, table.noborder th {
+padding: 0px;
+}
diff --git a/_templates/layout.html b/_templates/layout.html
index b6bf12b..637332d 100644
--- a/_templates/layout.html
+++ b/_templates/layout.html
@@ -1,9 +1,2 @@
 {% extends "!layout.html" %}
-{% block tables %}
-
-table#table-borderless {
-border: 1px solid black;
-}
-
-{{ super() }}
-{% endblock %}
+{% set css_files = css_files + ["_static/v4l2tables.css"] %}
diff --git a/packed-rgb.rst b/packed-rgb.rst
index 352b91c..b4fcf3e 100644
--- a/packed-rgb.rst
+++ b/packed-rgb.rst
@@ -9,25 +9,46 @@ graphics frame buffers. They occupy 8, 16, 24 or 32 bits per pixel.
 These are all packed-pixel formats, meaning all the data for a pixel lie
 next to each other in memory.
 
-.. csv-table:: Table: Packed RGB Image Formats
-  :header: Identifier,Code, ,Byte 0 in memory,Byte 1,Byte 2,Byte 3
+.. table:: Packed RGB Image Formats
+   :class: noborder
 
-  ``V4L2_PIX_FMT_RGB332``,'RGB1',,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`1`,b\ :sub:`0`
-  ``V4L2_PIX_FMT_ARGB444``,'AR12',,g\ :sub:`3`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,a\ :sub:`3`,a\ :sub:`2`,a\ :sub:`1`,a\ :sub:`0`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`
-  ``V4L2_PIX_FMT_XRGB444``,'XR12',,g\ :sub:`3`,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,-,-,-,-,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`
-  ``V4L2_PIX_FMT_ARGB555``,'AR15',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,a,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`
-  ``V4L2_PIX_FMT_XRGB555``,'XR15',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,-,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`
-  ``V4L2_PIX_FMT_RGB565``,'RGBP',,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`,,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`5`,g\ :sub:`4`,g\ :sub:`3`
-  ``V4L2_PIX_FMT_ARGB555X``,'AR15' | (1<<31),,a,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`,,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4`,b\ :sub:`3`,b\ :sub:`2`,b\ :sub:`1`,b\ :sub:`0`
-  ``V4L2_PIX_FMT_XRGB555X``,'XR15' | (1<<31),,-,r\ :sub:`4`,r\ :sub:`3`,r\ :sub:`2`,r\ :sub:`1`,r\ :sub:`0`,g\ :sub:`4`,g\ :sub:`3`,,g\ :sub:`2`,g\ :sub:`1`,g\ :sub:`0`,b\ :sub:`4

Re: Kernel docs: muddying the waters a bit

[Johannes Stezenbach]

On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote:
> 
> 3) I tried to use a .. cssclass, as Johannes suggested, but
> I was not able to include the CSS file. I suspect that this is
> easy to fix, but I want to see if the cssclass will also work for
> the pdf output as well.

"cssclass" was (I think) a custom role defined in the example,
unless you also have defined a custom role you can use plain "class".
I have not looked deeper into the theming and template stuff.

> 4) It seems that it can't produce nested tables in pdf:
> 
> Markup is unsupported in LaTeX:
> v4l-table-within-table:: nested tables are not yet implemented.
> Makefile:115: recipe for target 'latexpdf' failed

This:
http://www.sphinx-doc.org/en/stable/markup/misc.html#tables

suggests you need to add the tabularcolumns directive
for complex tables.

BTW, as an alternative to the ASCII-art input
there is also support for CSV and list tables:
http://docutils.sourceforge.net/docs/ref/rst/directives.html#table


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel docs: muddying the waters a bit

[Johannes Stezenbach]

On Fri, Mar 04, 2016 at 10:29:08AM +0200, Jani Nikula wrote:
> On Fri, 04 Mar 2016, Mauro Carvalho Chehab  wrote:
> >
> > If, on the other hand, we decide to use RST, we'll very likely need to
> > patch it to fulfill our needs in order to add proper table support.
> > I've no idea how easy/difficult would be to do that, nor if Sphinx
> > upstream would accept such changes.
> >
> > So, at the end of the day, we may end by having to carry on our own
> > version of Sphinx inside our tree, with doesn't sound good, specially
> > since it is not just a script, but a package with hundreds of
> > files.
> 
> If we end up having to modify Sphinx, it has a powerful extension
> mechanism for this. We wouldn't have to worry about getting it merged to
> Sphinx upstream, and we wouldn't have to carry a local version of all of
> Sphinx. (In fact, the extension mechanism provides a future path for
> doing kernel-doc within Sphinx instead of as a preprocessing step.)
> 
> I know none of this alleviates your concerns with table supports right
> now. I'll try to have a look at that a bit more.

FWIW, I think table formatting in Sphinx works via style sheets.
The mechanism is documented in the Python docutils docs that
Sphinx is built upon.
Basically you use the "class" or "role" directive and define
the corresponding CSS or LaTeX (or rst2pdf) style.

Here is one example (using a custom "cssclass" role):
https://pythonhosted.org/sphinxjp.themes.basicstrap/sample.html

Directives (especially role and class):
http://www.sphinx-doc.org/en/stable/rest.html#directives

LaTeX styling:
http://docutils.readthedocs.org/en/sphinx-docs/user/latex.html#custom-interpreted-text-roles


HTH,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linuxtv.org downtime around Mon Nov 30 12:00 UTC

[Johannes Stezenbach]

On Mon, Nov 30, 2015 at 03:24:16PM +0100, Hans Verkuil wrote:
> On 11/30/2015 02:35 PM, Johannes Stezenbach wrote:
> > On Sun, Nov 29, 2015 at 05:11:45PM +0100, Johannes Stezenbach wrote:
> >> the linuxtv.org server will move to a new, freshly installed
> >> machine tomorrow.  Expect some downtime while we do the
> >> final rsync and database export+import.  I'm planning
> >> to start disabling services on the old server about
> >> 30min before 12:00 UTC (13:00 CET) on Mon Nov 30.
> >> If all goes well the new server will be available
> >> soon after 12:00 UTC.  The IP address will not change.
> > 
> > Done.  The new ssh host key:
> > RSA   SHA256:UY3VeEO8B/F7D/zghHGj46ioWcOqcpnGYCeEfVhTP1Q.
> > ECDSA key fingerprint is SHA256:xUEF4X6LaZeXMNiRkmLWx7Wj4jnIPB8+UsDLC35t8ik.
> 
> Hmm, git was working for a bit, but now it's gone again.

Now git-daemon is running, too, and it should be stable.

If not, please let me know.


Thanks,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linuxtv.org downtime around Mon Nov 30 12:00 UTC

[Johannes Stezenbach]

On Sun, Nov 29, 2015 at 05:11:45PM +0100, Johannes Stezenbach wrote:
> the linuxtv.org server will move to a new, freshly installed
> machine tomorrow.  Expect some downtime while we do the
> final rsync and database export+import.  I'm planning
> to start disabling services on the old server about
> 30min before 12:00 UTC (13:00 CET) on Mon Nov 30.
> If all goes well the new server will be available
> soon after 12:00 UTC.  The IP address will not change.

Done.  The new ssh host key:
RSA   SHA256:UY3VeEO8B/F7D/zghHGj46ioWcOqcpnGYCeEfVhTP1Q.
ECDSA key fingerprint is SHA256:xUEF4X6LaZeXMNiRkmLWx7Wj4jnIPB8+UsDLC35t8ik.


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linuxtv.org downtime around Mon Nov 30 12:00 UTC

[Johannes Stezenbach]

Hi,

the linuxtv.org server will move to a new, freshly installed
machine tomorrow.  Expect some downtime while we do the
final rsync and database export+import.  I'm planning
to start disabling services on the old server about
30min before 12:00 UTC (13:00 CET) on Mon Nov 30.
If all goes well the new server will be available
soon after 12:00 UTC.  The IP address will not change.


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add support for TechniSat Skystar S2

[Johannes Stezenbach]

(add Mauro)

On Sun, Apr 19, 2015 at 11:19:43PM +0200, Patrick Boettcher wrote:
 On Fri, 17 Apr 2015 11:06:30 +0200
 Patrick Boettcher patrick.boettc...@posteo.de wrote:
  http://git.linuxtv.org/cgit.cgi/pb/media_tree.git/ cx24120-v2
 
 Jannis pointed out, that my repository on linuxtv.org was not
 fetchable...
 
 I put one onto github, this should work:
 
 https://github.com/pboettch/linux.git cx24120-v2
 
 It is the same commits as I was pushing to the linuxtv.org .

Patrick, can you point out why your repository is
not fetchable?  Any error messages?

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] xc5000: tuner firmware update

[Johannes Stezenbach]

On Mon, Oct 27, 2014 at 01:57:27PM -0200, Mauro Carvalho Chehab wrote:
 Em Mon, 27 Oct 2014 10:25:48 -0400
 Michael Ira Krufky mkru...@linuxtv.org escreveu:
 
  I like the idea of supporting older firmware revisions if the new one
  is not present, but, the established president for this sort of thing
  has always been to replace older firmware with newer firmware without
  backward compatibility support for older binaries.
 
 No, we're actually adding backward support. There are some drivers
 already with it. See for example xc4000 (changeset da7bfa2c5df).
 
  Although the current driver can work with both old and new firmware
  versions, this hasn't been the case in the past, and won't always be
  the case with future firmware revisions.
 
 Yeah, we did a very crap job breaking backward firmware compat in
 the past. We're not doing it anymore ;)
 
  Hauppauge has provided links to the new firmware for both the XC5000
  and XC5000C chips along with licensing.  Maybe instead, we can just
  upstream those into the linux-firmware packages for distribution.
 
 Upstreaming to linux-firmware was done already for the previous firmwares.
 The firmwares at linux-firmware for xc5000 and xc5000c were merged back 
 there for 3.17 a few weeks ago.
 
 Feel free to submit them a new version.
 
  I don't think supporting two different firmware versions is a good
  idea for the case of the xc5000 driver.
 
 Why not? It should work as-is with either version. We can always add
 some backward compat code if needed.

FWIW, Linus recently addressed the topic wrt wireless firmware:
http://article.gmane.org/gmane.linux.kernel.wireless.general/126794


HTH,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] some fixes and cleanups for the em28xx-based HVR-930C

[Johannes Stezenbach]

On Mon, Sep 29, 2014 at 08:44:28PM +0200, Johannes Stezenbach wrote:
 On Mon, Sep 29, 2014 at 03:30:18PM -0300, Mauro Carvalho Chehab wrote:
  Em Mon, 29 Sep 2014 19:44:30 +0200
  Johannes Stezenbach j...@linuxtv.org escreveu:
  
   Disregarding your mails from the em28xx breaks after hibernate
   that hibernate doesn't work for you, I decided to give these
   changes a try on top of today's media_tree.git
   (cf3167c - 3.17.0-rc5-00741-g9a3fbd8), still inside qemu
   (can't upgrade/reboot my main machine right now).
  
  Well, I think I was not clear: It doesn't work for me when 
  I power down the USB or the machine after suspended. If I keep
  the device energized, it works ;)
 
 Ah, OK.  I'll try to test with power removed tomorrow.

I test again in qemu, but this time rmmod and blacklist em28xx
on the host, and unplug HVR-930C during hibernate.  As you
said, it breaks.  Log fter resume:

[   83.308267] usb 1-1: reset high-speed USB device number 2 using ehci-pci
[   83.598182] em2884 #0: Resuming extensions
[   83.599187] em2884 #0: Resuming video extensionem2884 #0: Resuming DVB 
extension
[   83.604115] xc5000: I2C read failed
[   83.607091] xc5000: I2C write failed (len=3)
[   83.607985] xc5000: firmware upload failed...
[   83.608766]  - too many retries. Giving up
[   83.609553] em2884 #0: fe0 resume -22
[   83.615533] PM: restore of devices complete after 937.567 msecs
[   83.617278] PM: Image restored successfully.
[   83.618262] PM: Basic memory bitmaps freed
[   83.619097] Restarting tasks ... done.
[   83.622320] xc5000: I2C read failed
[   83.623197] xc5000: I2C write failed (len=3)
[   83.623198] xc5000: firmware upload failed...
[   83.623198]  - too many retries. Giving up
[   83.624071] drxk: i2c read error at addr 0x29
[   83.624072] drxk: Error -6 on mpegts_stop
[   83.624073] drxk: Error -6 on start
[   84.621531] drxk: i2c read error at addr 0x29
[   84.623426] drxk: Error -6 on get_dvbt_lock_status
[   84.625477] drxk: Error -6 on get_lock_status


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] some fixes and cleanups for the em28xx-based HVR-930C

[Johannes Stezenbach]

Hi Mauro,

On Sun, Sep 28, 2014 at 11:23:17PM -0300, Mauro Carvalho Chehab wrote:
 This patch series addresses some issues with suspend2ram of devices
 based on DRX-K.
 
 With this patch series, it is now possible to suspend to ram while
 streaming. At resume, the stream will continue to play.
 
 While doing that, I added a few other changes:
 
 - I moved the init code to .init. That is an initial step to fix
   suspend to disk;
 
 - There's a fix to an issue that happens at xc5000 removal (sent
   already as a RFC patch);
 
 - A dprintk change at his logic to not require both a boot parameter and
   a dynamic_printk enablement. It also re-adds __func__ to the printks,
   that got previously removed;
 
 - It removes the unused mfe_sharing var from the dvb attach logic.
 
 Mauro Carvalho Chehab (6):
   [media] em28xx: remove firmware before releasing xc5000 priv state
   [media] drxk: Fix debug printks
   [media] em28xx-dvb: remove unused mfe_sharing
   [media] em28xx-dvb: handle to stop/start streaming at PM
   [media] em28xx: move board-specific init code
   [media] drxk: move device init code to .init callback
 
  drivers/media/dvb-frontends/drxk_hard.c | 117 
 
  drivers/media/tuners/xc5000.c   |   2 +-
  drivers/media/usb/em28xx/em28xx-dvb.c   |  45 
  3 files changed, 92 insertions(+), 72 deletions(-)


Disregarding your mails from the em28xx breaks after hibernate
that hibernate doesn't work for you, I decided to give these
changes a try on top of today's media_tree.git
(cf3167c - 3.17.0-rc5-00741-g9a3fbd8), still inside qemu
(can't upgrade/reboot my main machine right now).

Works!  For hibernate, using echo reboot /sys/power/disk, so
the host driver cannot interfere with the qemu driver during hibernate.
Qemu causes several USB resets to the device during
hibernate - resume, but the USB power is not cut.
It works even while running dvbv5-zap and streaming to mplayer.

I tried both suspend-to-ram and hibernate a couple of times,
at least in Qemu it all works.

There are a lot of drxk debug prints now enabled by default,
not sure if that was intentional.


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] some fixes and cleanups for the em28xx-based HVR-930C

[Johannes Stezenbach]

On Mon, Sep 29, 2014 at 03:30:18PM -0300, Mauro Carvalho Chehab wrote:
 Em Mon, 29 Sep 2014 19:44:30 +0200
 Johannes Stezenbach j...@linuxtv.org escreveu:
 
  Disregarding your mails from the em28xx breaks after hibernate
  that hibernate doesn't work for you, I decided to give these
  changes a try on top of today's media_tree.git
  (cf3167c - 3.17.0-rc5-00741-g9a3fbd8), still inside qemu
  (can't upgrade/reboot my main machine right now).
 
 Well, I think I was not clear: It doesn't work for me when 
 I power down the USB or the machine after suspended. If I keep
 the device energized, it works ;)

Ah, OK.  I'll try to test with power removed tomorrow.

  Works!  For hibernate, using echo reboot /sys/power/disk, so
  the host driver cannot interfere with the qemu driver during hibernate.
  Qemu causes several USB resets to the device during
  hibernate - resume, but the USB power is not cut.
  It works even while running dvbv5-zap and streaming to mplayer.
 
 Thanks for testing it! it is great to have a separate test for
 the patches.
 
 Could I add a tested-by tag on those patches?

sure

  I tried both suspend-to-ram and hibernate a couple of times,
  at least in Qemu it all works.
  
  There are a lot of drxk debug prints now enabled by default,
  not sure if that was intentional.
 
 You're probably probing the device with debug=1, right?

right, forgot I had added this to the kernel command line
in my qemu start script


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 12:43:09PM -0300, Mauro Carvalho Chehab wrote:
 Em Fri, 26 Sep 2014 17:22:28 +0200
 Johannes Stezenbach j...@linuxtv.org escreveu:
 
  On Fri, Sep 26, 2014 at 05:06:02PM +0200, Johannes Stezenbach wrote:
   
   [   20.212162] usb 1-1: reset high-speed USB device number 2 using 
   ehci-pci
   [   20.503868] em2884 #0: Resuming extensions
   [   20.505275] em2884 #0: Resuming video extensionem2884 #0: Resuming DVB 
   extension
   [   20.533513] drxk: status = 0x439130d9
   [   20.534282] drxk: detected a drx-3913k, spin A2, xtal 20.250 MHz
   [   23.008852] em2884 #0: writing to i2c device at 0x52 failed (error=-5)
   [   23.011408] drxk: i2c write error at addr 0x29
   [   23.013187] drxk: write_block: i2c write error at addr 0x8303b4
   [   23.015440] drxk: Error -5 while loading firmware
   [   23.017291] drxk: Error -5 on init_drxk
   [   23.018835] em2884 #0: fe0 resume 0
   
   Any idea on this?
  
  I backed out Mauro's test patch, now it seems to work
  (v3.17-rc5-734-g214635f, no patches, em28xx as modules).
  But I'm not 100% sure the above was related to this,
  it seemed the 930C got upset during all the testing
  and I had to unplug it to get it back working.
 
 Could you please test again with the patch? Without it, I suspect that,
 if you suspend while streaming, the frontend won't relock again after
 resume. Of course, I may be wrong ;)

I tried again both with and without the patch.  The issue above
odesn't reproduce, but after hibernate it fails to tune
(while it works after suspend-to-ram).  Restarting dvbv5-zap
does not fix it.  All I get is:

[  500.299216] drxk: Error -22 on dvbt_sc_command
[  500.301012] drxk: Error -22 on set_dvbt
[  500.301967] drxk: Error -22 on start

There are no other errors messages during hibernate + resume.
It happens whether I let dvbv5-zap run during hibernate
or stop it first.  On rmmod it Oopsed:

root@debian:~# rmmod em28xx_dvb em28xx_v4l drxk em28xx
[ 1992.790039] em2884 #0: Closing DVB extension
[ 1992.797623] xc5000 2-0061: destroying instance
[ 1992.799595] general protection fault:  [#1] PREEMPT SMP
[ 1992.800032] Modules linked in: drxk em28xx_dvb(-) em28xx_v4l 
videobuf2_vmalloc videobuf2_memops videobuf2_core em28xx tveeprom
[ 1992.800032] CPU: 3 PID: 2095 Comm: rmmod Not tainted 
3.17.0-rc5-00734-g214635f-dirty #91
[ 1992.800032] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[ 1992.800032] task: 88003cf700d0 ti: 88003c398000 task.ti: 
88003c398000
[ 1992.800032] RIP: 0010:[81320721]  [81320721] 
release_firmware+0x2c/0x52
[ 1992.800032] RSP: :88003c39be58  EFLAGS: 00010246
[ 1992.800032] RAX: 8188d408 RBX: 6b6b6b6b6b6b6b6b RCX: 0006
[ 1992.800032] RDX: 0004 RSI: 88003cf70860 RDI: 6b6b6b6b6b6b6b6b
[ 1992.800032] RBP: 88003c39be60 R08: 0200 R09: 0001
[ 1992.800032] R10: 88003c39bcc0 R11: 82ac6100 R12: 88003bc5a000
[ 1992.800032] R13: 88003d6a81c8 R14: 7fd6e977d090 R15: 0800
[ 1992.800032] FS:  7fd6e8633700() GS:88003e20() 
knlGS:
[ 1992.800032] CS:  0010 DS:  ES:  CR0: 8005003b
[ 1992.800032] CR2: 00400184 CR3: 3b996000 CR4: 06a0
[ 1992.800032] Stack:
[ 1992.800032]  88003befcc00 88003c39be80 813cbd36 
88003bc5a000
[ 1992.800032]  88003baa2000 88003c39bea0 813e2f75 
88003d6a8000
[ 1992.800032]  88003baa2000 88003c39bec8 a0046804 
88003baa2000
[ 1992.800032] Call Trace:
[ 1992.800032]  [813cbd36] xc5000_release+0xa0/0xbf
[ 1992.800032]  [813e2f75] dvb_frontend_detach+0x35/0x7d
[ 1992.800032]  [a0046804] em28xx_dvb_fini+0x195/0x1d0 [em28xx_dvb]
[ 1992.800032]  [a0009211] em28xx_unregister_extension+0x3d/0x79 
[em28xx]
[ 1992.800032]  [a0048e20] em28xx_dvb_unregister+0x10/0x1f0 
[em28xx_dvb]
[ 1992.800032]  [810942e8] SyS_delete_module+0x141/0x19e
[ 1992.800032]  [81488792] system_call_fastpath+0x16/0x1b
[ 1992.800032] Code: 48 85 ff 48 c7 c0 08 d4 88 81 48 89 e5 53 48 89 fb 74 3b 
48 3d 08 d4 88 81 74 10 48 8b 50 08 48 39 53 08 74 18 48 83 c0 18 eb e8 48 8b 
7b 18 48 85 ff 75 13 48 8b 7b 08 e8 32 16 de ff 48 89 df
[ 1992.800032] RIP  [81320721] release_firmware+0x2c/0x52
[ 1992.800032]  RSP 88003c39be58
[ 1992.867774] ---[ end trace 499f4df0704fd661 ]---

(xc5000 is non-modular because it is autoselected by some dependency)


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Sun, Sep 28, 2014 at 08:12:11AM -0300, Mauro Carvalho Chehab wrote:
 Em Sun, 28 Sep 2014 12:55:40 +0200
 Johannes Stezenbach j...@linuxtv.org escreveu:
 
  I tried again both with and without the patch.  The issue above
  odesn't reproduce, but after hibernate it fails to tune
  (while it works after suspend-to-ram).  Restarting dvbv5-zap
  does not fix it.  All I get is:
  
  [  500.299216] drxk: Error -22 on dvbt_sc_command
  [  500.301012] drxk: Error -22 on set_dvbt
  [  500.301967] drxk: Error -22 on start
 
 Just to be 100% sure if I understood well: you're having exactly
 the same behavior with and without my patch, right?

Yes, no observable difference in my tests.

 I'll see if I can work on another patch for you today. If not,
 I won't be able to touch on it until the end of the week, as I'm
 traveling next week.

no need to hurry

(BTW, I still think you should make sure the hang-on-resume fix,
revert of b89193e0b06f, goes into 3.17, but it's your call.)

  On rmmod it Oopsed:
...
 Please try this change:
 
 [media] em28xx: remove firmware before releasing xc5000 priv state
 
 hybrid_tuner_release_state() can free the priv state, so we need to
 release the firmware before calling it.
 
 Signed-off-by: Mauro Carvalho Chehab
 
 diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
 index e44c8aba6074..803a0e63d47e 100644
 --- a/drivers/media/tuners/xc5000.c
 +++ b/drivers/media/tuners/xc5000.c
 @@ -1333,9 +1333,9 @@ static int xc5000_release(struct dvb_frontend *fe)
  
   if (priv) {
   cancel_delayed_work(priv-timer_sleep);
 - hybrid_tuner_release_state(priv);
   if (priv-firmware)
   release_firmware(priv-firmware);
 + hybrid_tuner_release_state(priv);
   }
  
   mutex_unlock(xc5000_list_mutex);
 

Works.  And after module reload, dvbv5-zap can work again.


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

Hi Shuah,

On Thu, Sep 25, 2014 at 01:03:30PM -0600, Shuah Khan wrote:
 On 09/25/2014 12:45 PM, Shuah Khan wrote:
 
  ok now I know why the second path didn't
  apply. It depends on another change that added resume
  function
  
  7ab1c07614b984778a808dc22f84b682fedefea1
  
  You don't need the second patch. The first patch applied
  to 3.17 and fails on 3.16
  
  http://patchwork.linuxtv.org/patch/26073/
  
  I am working on 3.16 back-port for the first one to 3.16
  and send one shortly for you to test.
  
 
 The first patch depends the work done in 3.17, I don't
 see it meeting the stable rules to go into 3.16.
 
 Johannes! Do you need the request_firmware patch for
 3.16?? Are you seeing problems there. 3.16 doesn't
 have b89193e0b06f

3.16.3 has two issues:

- 6eb5e3399e8 em28xx-dvb - fix em28xx_dvb_resume() to not unregister i2c and 
dvb
  is not in 3.16.3
- the request_firmware issue

Locally I applied 6eb5e3399e8 and my dvb_frontend_resume() change,
which improves it but it is not fully working.  After the
frontend device is opened:

Sep 26 08:29:31 abc kernel: xc5000: I2C read failed
Sep 26 08:29:31 abc kernel: xc5000: waiting for firmware upload 
(dvb-fe-xc5000-1.6.114.fw)...
Sep 26 08:29:31 abc kernel: xc5000: firmware read 12401 bytes.
Sep 26 08:29:31 abc kernel: xc5000: firmware uploading...
Sep 26 08:29:31 abc kernel: xc5000: I2C write failed (len=3)
Sep 26 08:29:31 abc kernel: xc5000: firmware upload failed...
Sep 26 08:29:31 abc kernel: xc5000: Unable to initialise tuner
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: drxk: Error -6 on get_dvbt_lock_status
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: drxk: Error -6 on get_dvbt_lock_status
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: drxk: Error -6 on get_dvbt_lock_status
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: xc5000: I2C read failed
Sep 26 08:29:31 abc kernel: xc5000: waiting for firmware upload 
(dvb-fe-xc5000-1.6.114.fw)...
Sep 26 08:29:31 abc kernel: xc5000: firmware read 12401 bytes.
Sep 26 08:29:31 abc kernel: xc5000: firmware uploading...
Sep 26 08:29:31 abc kernel: xc5000: I2C write failed (len=3)
Sep 26 08:29:31 abc kernel: xc5000: firmware upload failed...
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: drxk: Error -6 on mpegts_stop
Sep 26 08:29:31 abc kernel: drxk: Error -6 on start
Sep 26 08:29:31 abc kernel: drxk: i2c read error at addr 0x29
Sep 26 08:29:31 abc kernel: drxk: Error -6 on get_dvbt_lock_status
...

I have to unload and reload the em28xx modules to recover.
So it would be good to have an xc5000 patch backport from
you instead of my dvb_frontend_resume() change.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Thu, Sep 25, 2014 at 12:45:24PM -0600, Shuah Khan wrote:
 
 Revert is good. Just checked 3.16 and we are good
 on that. It needs to be reverted from 3.17 for sure.
 
 ok now I know why the second path didn't
 apply. It depends on another change that added resume
 function
 
 7ab1c07614b984778a808dc22f84b682fedefea1
 
 You don't need the second patch. The first patch applied
 to 3.17 and fails on 3.16
 
 http://patchwork.linuxtv.org/patch/26073/

I'm not sure I understand correctly.  I applied the
b89193e0b06f revert plus the 26073 patchwork patch
on top of yesterday's git master (v3.17-rc6-247-g005f800),
the xc5000 request_firmware issue still happens, additionally
a drxk_attach request_firmware warning is printed after resume.

I should mention I just test boot - hibernate - resume,
the device is not opened before hibernate.

The drxk warning trace is:

[3.762776]  [81320e96] request_firmware+0x30/0x42
[3.764538]  [813f2f58] drxk_attach+0x546/0x656
[3.766094]  [814ba9d2] em28xx_dvb_init.part.3+0xa1c/0x1cc6
[3.767879]  [8106555c] ? trace_hardirqs_on_caller+0x183/0x19f
[3.769825]  [814be27d] ? mutex_unlock+0x9/0xb
[3.771379]  [814b96a1] ? em28xx_v4l2_init.part.11+0xcbd/0xd04
[3.773342]  [8141b7e7] em28xx_dvb_init+0x1d/0x1f
[3.774982]  [81415740] em28xx_init_extension+0x51/0x67
[3.776670]  [81416d38] request_module_async+0x19/0x1b

[3.793013] usb 1-1: firmware: dvb-usb-hauppauge-hvr930c-drxk.fw will not be 
loaded


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 10:00:30AM +0200, Johannes Stezenbach wrote:
 On Thu, Sep 25, 2014 at 12:45:24PM -0600, Shuah Khan wrote:
  
  Revert is good. Just checked 3.16 and we are good
  on that. It needs to be reverted from 3.17 for sure.
  
  ok now I know why the second path didn't
  apply. It depends on another change that added resume
  function
  
  7ab1c07614b984778a808dc22f84b682fedefea1
  
  You don't need the second patch. The first patch applied
  to 3.17 and fails on 3.16
  
  http://patchwork.linuxtv.org/patch/26073/
 
 I'm not sure I understand correctly.  I applied the
 b89193e0b06f revert plus the 26073 patchwork patch
 on top of yesterday's git master (v3.17-rc6-247-g005f800),
 the xc5000 request_firmware issue still happens, additionally
 a drxk_attach request_firmware warning is printed after resume.
 
 I should mention I just test boot - hibernate - resume,
 the device is not opened before hibernate.

If I run dvb-fe-tool to load the xc5000 firmware before
hibernate then the xc5000 issue seems fixed, but the
drxk firmware issue still happens.

Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

Hi Mauro,

On Fri, Sep 26, 2014 at 07:14:11AM -0300, Mauro Carvalho Chehab wrote:
 
 I just pushed the pending patched and added a reverted patch for
 b89193e0b06f at the media_tree.git. Could you please use it to compile
 or, if you prefer to keep using 3.16, you can use the media_build.git[1]
 tree to just use the newest media stack on the top of 3.16.
 
 [1] 
 http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
 
 I updated the today's tarball for it to have all the patches there.
 
   I should mention I just test boot - hibernate - resume,
   the device is not opened before hibernate.
  
  If I run dvb-fe-tool to load the xc5000 firmware before
  hibernate then the xc5000 issue seems fixed, but the
  drxk firmware issue still happens.
 
 Please check if the xc5000 issue disappears with the current patches.

I compiled media_tree.git v3.17-rc5-734-g214635f, the
xc5000 issue is fixed.  I tested both boot - hibernate -resume
and boot - dvb-fe-tool - hibernate -resume in qemu.

 The drxk issue will likely need a similar fix to the one that Shuah
 did to drxj.

The drx-k issue is still present:

[3.758318] WARNING: CPU: 0 PID: 59 at drivers/base/firmware_class.c:1124 
_request_firmware+0x205/0x568()
[3.760266] Modules linked in:
[3.760828] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.17.0-rc5+ #82
[3.762002] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[3.763890] Workqueue: events request_module_async
[3.764890]   88003c90fb38 814bcac8 

[3.766267]  88003c90fb70 81032d75 81320b3c 
fff5
[3.767596]  880039ea1b00 88003ca2be80 8853c900 
88003c90fb80
[3.768941] Call Trace:
[3.769414]  [814bcac8] dump_stack+0x4e/0x7a
[3.770285]  [81032d75] warn_slowpath_common+0x7a/0x93
[3.771281]  [81320b3c] ? _request_firmware+0x205/0x568
[3.772289]  [81032e32] warn_slowpath_null+0x15/0x17
[3.773235]  [81320b3c] _request_firmware+0x205/0x568
[3.774162]  [81065585] ? trace_hardirqs_on+0xd/0xf
[3.775064]  [81063c2c] ? lockdep_init_map+0xc4/0x13f
[3.775973]  [81320ecf] request_firmware+0x30/0x42
[3.776854]  [813f974f] drxk_attach+0x546/0x656
[3.777675]  [814c22a3] em28xx_dvb_init.part.3+0xa3e/0x1cdf
[3.778652]  [8106555c] ? trace_hardirqs_on_caller+0x183/0x19f
[3.779690]  [81065585] ? trace_hardirqs_on+0xd/0xf
[3.780615]  [814c5b45] ? mutex_unlock+0x9/0xb
[3.781428]  [814c0f50] ? em28xx_v4l2_init.part.11+0xcbd/0xd04
[3.782487]  [814230cf] em28xx_dvb_init+0x1d/0x1f
[3.783335]  [8141cfcb] em28xx_init_extension+0x51/0x67
[3.784276]  [8141e5c3] request_module_async+0x19/0x1b
[3.785207]  [8104585c] process_one_work+0x1d2/0x38a
[3.786133]  [810462f0] worker_thread+0x1f6/0x2a3
[3.786982]  [810460fa] ? rescuer_thread+0x214/0x214
[3.787863]  [81049c09] kthread+0xc7/0xcf
[3.788616]  [8125d487] ? debug_smp_processor_id+0x17/0x19
[3.789594]  [8106555c] ? trace_hardirqs_on_caller+0x183/0x19f
[3.790617]  [81049b42] ? __kthread_parkme+0x62/0x62
[3.791559]  [814c866c] ret_from_fork+0x7c/0xb0
[3.792399]  [81049b42] ? __kthread_parkme+0x62/0x62
[3.793314] ---[ end trace 001212d1d98f03c2 ]---
[3.794014] usb 1-1: firmware: dvb-usb-hauppauge-hvr930c-drxk.fw will not be 
loaded
[3.795218] drxk: Could not load firmware file 
dvb-usb-hauppauge-hvr930c-drxk.fw.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 08:42:15AM -0300, Mauro Carvalho Chehab wrote:
 Could you please try this patch (untested):
 
 [media] drxk: load firmware again at resume

No joy.  I think you need to keep the firmware around
for reuse after resume instead of requesting it again.

[2.521597] PM: Image loading progress:  80%
[2.535627] PM: Image loading progress:  90%
[2.552505] PM: Image loading done.
[2.553169] PM: Read 107920 kbytes in 0.50 seconds (215.84 MB/s)
[2.562310] em2884 #0: Suspending extensions
[2.969484] Switched to clocksource tsc
[3.792296] [ cut here ]
[3.794177] WARNING: CPU: 0 PID: 38 at drivers/base/firmware_class.c:1124 
_request_firmware+0x205/0x568()
[3.796157] Modules linked in:
[3.796723] CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 
3.17.0-rc5-00734-g214635f-dirty #84
[3.798197] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[3.800121] Workqueue: events request_module_async
[3.801115]   88003dfefb38 814bcae8 

[3.802533]  88003dfefb70 81032d75 81320b3c 
fff5
[3.803900]  880039e63de0 88003cfaf880 8800363aa900 
88003dfefb80
[3.805283] Call Trace:
[3.805723]  [814bcae8] dump_stack+0x4e/0x7a
[3.806617]  [81032d75] warn_slowpath_common+0x7a/0x93
[3.807636]  [81320b3c] ? _request_firmware+0x205/0x568
[3.808673]  [81032e32] warn_slowpath_null+0x15/0x17
[3.809638]  [81320b3c] _request_firmware+0x205/0x568
[3.810611]  [81065585] ? trace_hardirqs_on+0xd/0xf
[3.811545]  [81063c2c] ? lockdep_init_map+0xc4/0x13f
[3.812477]  [81320ecf] request_firmware+0x30/0x42
[3.813399]  [813f974f] drxk_attach+0x546/0x651
[3.814233]  [814c22c3] em28xx_dvb_init.part.3+0xa3e/0x1cdf
[3.815235]  [8106555c] ? trace_hardirqs_on_caller+0x183/0x19f
[3.816341]  [81065585] ? trace_hardirqs_on+0xd/0xf
[3.817280]  [814c5b65] ? mutex_unlock+0x9/0xb
[3.818127]  [814c0f70] ? em28xx_v4l2_init.part.11+0xcbd/0xd04
[3.819176]  [814230f4] em28xx_dvb_init+0x1d/0x1f
[3.820078]  [8141cff0] em28xx_init_extension+0x51/0x67
[3.821026]  [8141e5e8] request_module_async+0x19/0x1b
[3.821966]  [8104585c] process_one_work+0x1d2/0x38a
[3.822884]  [810462f0] worker_thread+0x1f6/0x2a3
[3.823752]  [810460fa] ? rescuer_thread+0x214/0x214
[3.824697]  [81049c09] kthread+0xc7/0xcf
[3.825451]  [8125d487] ? debug_smp_processor_id+0x17/0x19
[3.826430]  [8106555c] ? trace_hardirqs_on_caller+0x183/0x19f
[3.827501]  [81049b42] ? __kthread_parkme+0x62/0x62
[3.828449]  [814c866c] ret_from_fork+0x7c/0xb0
[3.829315]  [81049b42] ? __kthread_parkme+0x62/0x62
[3.830228] ---[ end trace 9c556ab09f9d1814 ]---
[3.830932] usb 1-1: firmware: dvb-usb-hauppauge-hvr930c-drxk.fw will not be 
loaded
[3.832134] drxk: Could not load firmware file 
dvb-usb-hauppauge-hvr930c-drxk.fw.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 09:03:16AM -0300, Mauro Carvalho Chehab wrote:
 
 The patch I sent you (or some fixed version of it) is part of the
 solution, but this still bothers me:
 
   [3.776854]  [813f974f] drxk_attach+0x546/0x656
   [3.777675]  [814c22a3] em28xx_dvb_init.part.3+0xa3e/0x1cdf
   [3.778652]  [8106555c] ? 
   trace_hardirqs_on_caller+0x183/0x19f
   [3.779690]  [81065585] ? trace_hardirqs_on+0xd/0xf
   [3.780615]  [814c5b45] ? mutex_unlock+0x9/0xb
   [3.781428]  [814c0f50] ? 
   em28xx_v4l2_init.part.11+0xcbd/0xd04
   [3.782487]  [814230cf] em28xx_dvb_init+0x1d/0x1f
 
 Why em28xx_dvb_init() is being called?
 
 That should only happen if the device is re-probed again, but
 the reset_resume code should have been preventing it.

Well, I stuck a WARN_ON(1) into drxk_release(), it is not called
during hibernate+resume.
Do you have a better suggestion to debug it?

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 10:12:22AM -0300, Mauro Carvalho Chehab wrote:
 Try to add a WARN_ON or printk at em28xx_usb_resume().

It is called two times, once during hibernate and once during resume:

root@debian:~# echo disk /sys/power/state
[  107.108149] PM: Syncing filesystems ... done.
[  107.270300] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  107.274762] PM: Marking nosave pages: [mem 0x0009f000-0x000f]
[  107.276921] PM: Basic memory bitmaps created
[  107.278508] PM: Preallocating image memory... done (allocated 27340 pages)
[  107.345275] PM: Allocated 109360 kbytes in 0.06 seconds (1822.66 MB/s)
[  107.346826] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[  107.351116] em2884 #0: Suspending extensions
[  107.352087] em2884 #0: Suspending video extensionem2884 #0: Suspending DVB 
extension
[  107.363558] em2884 #0: fe0 suspend 0[  107.365163] PM: freeze of devices 
complete after 14.358 msecs
[  107.367346] PM: late freeze of devices complete after 0.911 msecs
[  107.370100] PM: noirq freeze of devices complete after 1.382 msecs
[  107.371198] ACPI: Preparing to enter system sleep state S4
[  107.372302] PM: Saving platform NVS memory
[  107.373029] Disabling non-boot CPUs ...
[  107.377630] smpboot: CPU 1 is now offline
[  107.382106] smpboot: CPU 2 is now offline
[  107.385268] smpboot: CPU 3 is now offline
[  107.387263] PM: Creating hibernation image:
[  107.389233] PM: Need to copy 26730 pages
[  107.389233] PM: Normal pages needed: 26730 + 1024, available pages: 235257
[  107.389233] PM: Hibernation image created (26730 pages copied)
[  107.389233] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State 
[\_S0_] (20140724/hwxface-580)
[  107.389233] PM: Restoring platform NVS memory
[  107.389233] Enabling non-boot CPUs ...
[  107.389233] x86: Booting SMP configuration:
[  107.389648] smpboot: Booting Node 0 Processor 1 APIC 0x1
[  107.422489] CPU1 is up
[  107.423580] smpboot: Booting Node 0 Processor 2 APIC 0x2
[  107.456293] CPU2 is up
[  107.457454] smpboot: Booting Node 0 Processor 3 APIC 0x3
[  107.490161] CPU3 is up
[  107.490928] ACPI: Waking up from system sleep state S4
[  107.492909] PM: noirq thaw of devices complete after 0.941 msecs
[  107.494763] PM: early thaw of devices complete after 0.675 msecs
[  107.501301] rtc_cmos 00:00: System wakeup disabled by ACPI
[  107.535741] [ cut here ]
[  107.536648] WARNING: CPU: 2 PID: 2055 at 
drivers/media/usb/em28xx/em28xx-cards.c:3505 em28xx_usb_resume+0x19/0x2f()
[  107.538554] Modules linked in:
[  107.539131] CPU: 2 PID: 2055 Comm: kworker/u8:11 Not tainted 
3.17.0-rc5-00734-g214635f-dirty #87
[  107.540719] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[  107.542559] Workqueue: events_unbound async_run_entry_fn
[  107.543541]   880034227bf8 814bc918 

[  107.544954]  880034227c30 81032d75 8141e3d1 
88003cb84000
[  107.546329]   813688d6  
880034227c40
[  107.547742] Call Trace:
[  107.548189]  [814bc918] dump_stack+0x4e/0x7a
[  107.549093]  [81032d75] warn_slowpath_common+0x7a/0x93
[  107.550097]  [8141e3d1] ? em28xx_usb_resume+0x19/0x2f
[  107.551082]  [813688d6] ? usb_dev_restore+0x10/0x10
[  107.551993]  [81032e32] warn_slowpath_null+0x15/0x17
[  107.552948]  [8141e3d1] em28xx_usb_resume+0x19/0x2f
[  107.553924]  [813749a5] usb_resume_interface.isra.6+0x9e/0xc1
[  107.555017]  [81374c3e] usb_resume_both+0xe3/0x103
[  107.555904]  [813755c2] usb_resume+0x16/0x5b
[  107.556745]  [813688e4] usb_dev_thaw+0xe/0x10
[  107.557572]  [8131d564] dpm_run_callback+0x3f/0x76
[  107.558458]  [8131e194] device_resume+0x155/0x17f
[  107.559334]  [8131e1d6] async_resume+0x18/0x3e
[  107.560224]  [8104c526] async_run_entry_fn+0x5c/0x106
[  107.561170]  [8104585c] process_one_work+0x1d2/0x38a
[  107.562104]  [81062d20] ? trace_hardirqs_off_caller+0x40/0xad
[  107.563155]  [810462f0] worker_thread+0x1f6/0x2a3
[  107.564050]  [810460fa] ? rescuer_thread+0x214/0x214
[  107.564984]  [81049c09] kthread+0xc7/0xcf
[  107.565736]  [8125d297] ? debug_smp_processor_id+0x17/0x19
[  107.566750]  [8106555c] ? trace_hardirqs_on_caller+0x183/0x19f
[  107.567816]  [81049b42] ? __kthread_parkme+0x62/0x62
[  107.568793]  [814c84ac] ret_from_fork+0x7c/0xb0
[  107.569649]  [81049b42] ? __kthread_parkme+0x62/0x62
[  107.570564] ---[ end trace e08bef2cbd6b29cf ]---
[  107.571274] em2884 #0: Resuming extensions
[  107.571921] em2884 #0: Resuming video extensionem2884 #0: Resuming DVB 
extension
[  107.597838] drxk: status = 0x439130d9
[  107.598599] drxk: detected a drx-3913k, spin A2, xtal 20.250 MHz
[  107.656843] ata2.01: NODEV after 

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 03:25:13PM +0200, Johannes Stezenbach wrote:
 
 (snipped some irrelevant part of resume)

Looking closer, I snipped too much:

[1.646784] Freeing unused kernel memory: 1080K (8800018f2000 - 
880001a0)
Loading, please wait...
[1.655328] busybox (67) used greatest stack depth: 13832 bytes left
[1.675777] udevd[80]: starting version 175
[1.714891] udevadm (81) used greatest stack depth: 13704 bytes left
[1.755582] ata_id (156) used greatest stack depth: 13512 bytes left
[1.805306] ata_id (163) used greatest stack depth: 12360 bytes left
[2.000165] tsc: Refined TSC clocksource calibration: 3299.998 MHz
[2.052171] usb 1-1: new high-speed USB device number 2 using ehci-pci
[2.095571] PM: Starting manual resume from disk
[2.096737] PM: Hibernation image partition 8:2 present
[2.097770] PM: Looking for hibernation image.
[2.099942] PM: Image signature found, resuming
[2.258955] PM: Preparing processes for restore.
[2.262675] Freezing user space processes ... (elapsed 0.003 seconds) done.
[2.262676] PM: Loading hibernation image.
[2.262732] PM: Marking nosave pages: [mem 0x0009f000-0x000f]
[2.262734] PM: Basic memory bitmaps created
[2.280526] PM: Using 3 thread(s) for decompression.
[2.280526] PM: Loading and decompressing image data (26873 pages)...
[2.325975] PM: Image loading progress:   0%

(this is from a different boot but suffient to show the problem)

 [2.294251] PM: Image loading progress:   0%
 [2.351260] usb 1-1: New USB device found, idVendor=2040, idProduct=1605
 [2.352679] usb 1-1: New USB device strings: Mfr=0, Product=1, 
 SerialNumber=2
 [2.354050] usb 1-1: Product: WinTV HVR-930C
 [2.354912] usb 1-1: SerialNumber: 4034209007
 [2.357962] em28xx: New device  WinTV HVR-930C @ 480 Mbps (2040:1605, 
 interface 0, class 0)
 [2.359568] em28xx: Audio interface 0 found (Vendor Class)
 [2.360700] em28xx: Video interface 0 found: isoc
 [2.361590] em28xx: DVB interface 0 found: isoc
 [2.362961] em28xx: chip ID is em2884
 [2.426081] PM: Image loading progress:  10%
 [2.436945] em2884 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x33f006aa
 [2.438478] em2884 #0: EEPROM info:
 [2.439412] em2884 #0:   microcode start address = 0x0004, boot 
 configuration = 0x01
 [2.452383] PM: Image loading progress:  20%
 [2.461029] em2884 #0:   I2S audio, 5 sample rates
 [2.461990] em2884 #0:   500mA max power
 [2.462711] em2884 #0:   Table at offset 0x24, strings=0x1e82, 0x186a, 
 0x
 [2.464248] em2884 #0: Identified as Hauppauge WinTV HVR 930C (card=81)
 [2.465443] tveeprom 2-0050: Hauppauge model 16009, rev B1F0, serial# 
 7677167
 [2.466813] tveeprom 2-0050: MAC address is 00:0d:fe:75:24:ef
 [2.467856] tveeprom 2-0050: tuner model is Xceive XC5000 (idx 150, type 
 76)
 [2.469650] tveeprom 2-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') 
 PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4)
 [2.471753] tveeprom 2-0050: audio processor is unknown (idx 45)
 [2.473053] tveeprom 2-0050: decoder processor is unknown (idx 44)
 [2.474484] tveeprom 2-0050: has no radio, has IR receiver, has no IR 
 transmitter
 [2.476172] em2884 #0: analog set to isoc mode.
 [2.477250] em2884 #0: dvb set to isoc mode.
 [2.478407] em2884 #0: Registering V4L2 extension
 [2.483092] em2884 #0: Config register raw data: 0xc3
 [2.489036] PM: Image loading progress:  30%
 [2.503024] em2884 #0: V4L2 video device registered as video0
 [2.504239] em2884 #0: V4L2 extension successfully initialized
 [2.505670] em2884 #0: Binding DVB extension
 [2.509139] input: ImExPS/2 Generic Explorer Mouse as 
 /devices/platform/i8042/serio1/input/input3
 [2.515851] PM: Image loading progress:  40%
 [2.537861] PM: Image loading progress:  50%
 [2.555687] PM: Image loading progress:  60%
 [2.574087] PM: Image loading progress:  70%
 [2.595687] PM: Image loading progress:  80%
 [2.612580] PM: Image loading progress:  90%
 [2.631157] PM: Image loading progress: 100%
 [2.632448] PM: Image loading done.
 [2.69] PM: Read 107132 kbytes in 0.53 seconds (202.13 MB/s)
 [2.641831] PM: Image successfully loaded
 [2.643767] em2884 #0: Suspending extensions
 [3.017460] Switched to clocksource tsc
 [3.820194] [ cut here ]
 [3.821254] WARNING: CPU: 1 PID: 39 at drivers/base/firmware_class.c:1124 
 _request_firmware+0x205/0x568()
 [3.823213] Modules linked in:
 [3.823813] CPU: 1 PID: 39 Comm: kworker/1:1 Not tainted 
 3.17.0-rc5-00734-g214635f-dirty #87
 [3.825412] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
 1.7.5-20140531_083030-gandalf 04/01/2014
 [3.827381] Workqueue: events request_module_async
 [3.828196]   88003dff7b38 814bc918 
 
 [3.829183

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 08:30:32AM -0600, Shuah Khan wrote:
 On 09/26/2014 08:25 AM, Johannes Stezenbach wrote:
  
  So, what is happening is that the em28xx driver still async initializes
  while the initramfs already has started resume.  Thus the rootfs in not
  mounted and the firmware is not loadable.  Maybe this is only an issue
  of my qemu test because I compiled a non-modular kernel but don't have
  the firmware in the initramfs for testing simplicity?
  
  
 
 Right. We have an issue when media drivers are compiled static
 (non-modular). I have been debugging that problem for a while.
 We have to separate the two cases - if you are compiling em28xx
 as static then you will run into the issue.

So I compiled em28xx as modules and installed them in my qemu image.
One issue solved, but it still breaks after resume:

[   20.212162] usb 1-1: reset high-speed USB device number 2 using ehci-pci
[   20.503868] em2884 #0: Resuming extensions
[   20.505275] em2884 #0: Resuming video extensionem2884 #0: Resuming DVB 
extension
[   20.533513] drxk: status = 0x439130d9
[   20.534282] drxk: detected a drx-3913k, spin A2, xtal 20.250 MHz
[   23.008852] em2884 #0: writing to i2c device at 0x52 failed (error=-5)
[   23.011408] drxk: i2c write error at addr 0x29
[   23.013187] drxk: write_block: i2c write error at addr 0x8303b4
[   23.015440] drxk: Error -5 while loading firmware
[   23.017291] drxk: Error -5 on init_drxk
[   23.018835] em2884 #0: fe0 resume 0

Any idea on this?


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 05:06:02PM +0200, Johannes Stezenbach wrote:
 On Fri, Sep 26, 2014 at 08:30:32AM -0600, Shuah Khan wrote:
  On 09/26/2014 08:25 AM, Johannes Stezenbach wrote:
   
   So, what is happening is that the em28xx driver still async initializes
   while the initramfs already has started resume.  Thus the rootfs in not
   mounted and the firmware is not loadable.  Maybe this is only an issue
   of my qemu test because I compiled a non-modular kernel but don't have
   the firmware in the initramfs for testing simplicity?
   
   
  
  Right. We have an issue when media drivers are compiled static
  (non-modular). I have been debugging that problem for a while.
  We have to separate the two cases - if you are compiling em28xx
  as static then you will run into the issue.
 
 So I compiled em28xx as modules and installed them in my qemu image.
 One issue solved, but it still breaks after resume:
 
 [   20.212162] usb 1-1: reset high-speed USB device number 2 using ehci-pci
 [   20.503868] em2884 #0: Resuming extensions
 [   20.505275] em2884 #0: Resuming video extensionem2884 #0: Resuming DVB 
 extension
 [   20.533513] drxk: status = 0x439130d9
 [   20.534282] drxk: detected a drx-3913k, spin A2, xtal 20.250 MHz
 [   23.008852] em2884 #0: writing to i2c device at 0x52 failed (error=-5)
 [   23.011408] drxk: i2c write error at addr 0x29
 [   23.013187] drxk: write_block: i2c write error at addr 0x8303b4
 [   23.015440] drxk: Error -5 while loading firmware
 [   23.017291] drxk: Error -5 on init_drxk
 [   23.018835] em2884 #0: fe0 resume 0
 
 Any idea on this?

I backed out Mauro's test patch, now it seems to work
(v3.17-rc5-734-g214635f, no patches, em28xx as modules).
But I'm not 100% sure the above was related to this,
it seemed the 930C got upset during all the testing
and I had to unplug it to get it back working.


Best Regards,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Fri, Sep 26, 2014 at 09:22:53AM -0600, Shuah Khan wrote:
  
  [   20.212162] usb 1-1: reset high-speed USB device number 2 using ehci-pci
  [   20.503868] em2884 #0: Resuming extensions
  [   20.505275] em2884 #0: Resuming video extensionem2884 #0: Resuming DVB 
  extension
  [   20.533513] drxk: status = 0x439130d9
  [   20.534282] drxk: detected a drx-3913k, spin A2, xtal 20.250 MHz
  [   23.008852] em2884 #0: writing to i2c device at 0x52 failed (error=-5)
  [   23.011408] drxk: i2c write error at addr 0x29
  [   23.013187] drxk: write_block: i2c write error at addr 0x8303b4
  [   23.015440] drxk: Error -5 while loading firmware
  [   23.017291] drxk: Error -5 on init_drxk
  [   23.018835] em2884 #0: fe0 resume 0
  
  Any idea on this?
  
 
 Looks like this is what's happening:
 during suspend:
 
 drxk_sleep() gets called and marks state-m_drxk_state == DRXK_UNINITIALIZED
 
 init_drxk() does download_microcode() and this step fails
 because the conditions in which init_drxk() gets called
 from drxk_attach() are different.
 
 i2c isn't ready.
 
 Is it possible for you to test this without power loss
 on usb assuming this test run usb bus looses power?
 
 If you could do the following tests and see if there is
 a difference:
 
 echo mem  /sys/power/state
 vs
 echo disk  /sys/power/state
 
 If it is possible, with and without reset_resume hook.

My testing time is up for today, I'll look into it
maybe tomorrow.

BTW, what about 3.17?  The patches in media_tree.git are for
3.18, right?  If so, and you have patches for 3.17 or
3.16-stable to test, let me know.


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

em28xx breaks after hibernate

[Johannes Stezenbach]

Hi Shuah,

ever since your patchset which implements suspend/resume
for em28xx, hibernating the system breaks the Hauppauge WinTV HVR 930C driver.
In v3.15.y and v3.16.y it throws a request_firmware warning
during hibernate + resume, and the /dev/dvb/ device nodes disappears after
resume.  In current git v3.17-rc6-247-g005f800, it hangs
after resume.  I bisected the hang in qemu to
b89193e0b06f media: em28xx - remove reset_resume interface,
the hang is fixed if I revert this commit on top of v3.17-rc6-247-g005f800.

Regarding the request_firmware issue. I think a possible
fix would be:

--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2568,16 +2568,8 @@ int dvb_frontend_resume(struct dvb_frontend *fe)
dev_dbg(fe-dvb-device, %s: adap=%d fe=%d\n, __func__, fe-dvb-num,
fe-id);

-   fe-exit = DVB_FE_DEVICE_RESUME;
-   if (fe-ops.init)
-   ret = fe-ops.init(fe);
-
-   if (fe-ops.tuner_ops.init)
-   ret = fe-ops.tuner_ops.init(fe);
-
-   fe-exit = DVB_FE_NO_EXIT;
fepriv-state = FESTATE_RETUNE;
-   dvb_frontend_wakeup(fe);
+   dvb_frontend_reinitialise(fe);

return ret;
 }


But of course this has the potential of breaking other drivers...

Below is a full log of the suspend + resume in qemu with
no_console_suspend.


Johannes


qemu command line:

qemu-system-x86_64 -enable-kvm -smp cpus=4 -m 1G -net nic,model=virtio -net 
user -hda debian-7.6.0.qcow2 -device usb-ehci,id=ehci -device 
usb-host,vendorid=0x2040,productid=0x1605,bus=ehci.0 -nographic -kernel 
~/src/linux/linux/arch/x86/boot/bzImage -initrd initrd.img-3.16.0 -append 
BOOT_IMAGE=/boot/vmlinuz-3.16.0 root=UUID=0ae480bd-5598-4e64-97d7-2c42f9fc181f 
ro console=ttyS0 no_console_suspend


root@debian:~# echo disk /sys/power/state
[   19.480127] PM: Syncing filesystems ... done.
[   19.668347] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   19.671188] PM: Preallocating image memory... done (allocated 28094 pages)
[   19.712341] PM: Allocated 112376 kbytes in 0.03 seconds (3745.86 MB/s)
[   19.713514] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[   19.717168] em2884 #0: Suspending extensions
[   19.717966] em2884 #0: Suspending video extensionem2884 #0: Suspending DVB 
extension
[   19.727558] em2884 #0: fe0 suspend 0[   19.729164] PM: freeze of devices 
complete after 12.270 msecs
[   19.730921] PM: late freeze of devices complete after 0.719 msecs
[   19.733542] PM: noirq freeze of devices complete after 1.502 msecs
[   19.734705] ACPI: Preparing to enter system sleep state S4
[   19.735779] PM: Saving platform NVS memory
[   19.736533] Disabling non-boot CPUs ...
[   19.741134] smpboot: CPU 1 is now offline
[   19.848207] smpboot: CPU 2 is now offline
[   19.852923] smpboot: CPU 3 is now offline
[   19.88] PM: Creating hibernation image:
[   19.856897] PM: Need to copy 27321 pages
[   19.856897] PM: Hibernation image created (27321 pages copied)
[   19.856897] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State 
[\_S0_] (20140724/hwxface-580)
[   19.856897] PM: Restoring platform NVS memory
[   19.856897] Enabling non-boot CPUs ...
[   19.856897] x86: Booting SMP configuration:
[   19.857612] smpboot: Booting Node 0 Processor 1 APIC 0x1
[   19.890484] CPU1 is up
[   19.891693] smpboot: Booting Node 0 Processor 2 APIC 0x2
[   19.924539] CPU2 is up
[   19.925693] smpboot: Booting Node 0 Processor 3 APIC 0x3
[   19.958401] CPU3 is up
[   19.961935] ACPI: Waking up from system sleep state S4
[   19.963712] PM: noirq thaw of devices complete after 0.705 msecs
[   19.965505] PM: early thaw of devices complete after 0.572 msecs
[   19.967322] rtc_cmos 00:00: System wakeup disabled by ACPI
[   20.003710] em2884 #0: Resuming extensions
[   20.004481] em2884 #0: Resuming video extensionem2884 #0: Resuming DVB 
extension
[   20.007581] [ cut here ]
[   20.008557] WARNING: CPU: 0 PID: 2061 at drivers/base/firmware_class.c:1124 
_request_firmware+0x205/0x568()
[   20.010348] Modules linked in:
[   20.011001] CPU: 0 PID: 2061 Comm: kworker/u8:11 Not tainted 3.17.0-rc6+ #78
[   20.012289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[   20.014149] Workqueue: events_unbound async_run_entry_fn
[   20.015144]   88003c233a28 814b5228 

[   20.016551]  88003c233a60 81032d75 81320b03 
fff5
[   20.018012]  88003cf10640 88003c68be80 ff00 
88003c233a70
[   20.019410] Call Trace:
[   20.019850]  [814b5228] dump_stack+0x4e/0x7a
[   20.020890]  [81032d75] warn_slowpath_common+0x7a/0x93
[   20.021976]  [81320b03] ? _request_firmware+0x205/0x568
[   20.023079]  [81032e32] warn_slowpath_null+0x15/0x17
[   20.024092]  [81320b03] _request_firmware+0x205/0x568
[   20.025063]  

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

Hi Shuah,

On Thu, Sep 25, 2014 at 07:45:37AM -0600, Shuah Khan wrote:
 On 09/25/2014 06:53 AM, Johannes Stezenbach wrote:
  ever since your patchset which implements suspend/resume
  for em28xx, hibernating the system breaks the Hauppauge WinTV HVR 930C 
  driver.
  In v3.15.y and v3.16.y it throws a request_firmware warning
  during hibernate + resume, and the /dev/dvb/ device nodes disappears after
  resume.  In current git v3.17-rc6-247-g005f800, it hangs
  after resume.  I bisected the hang in qemu to
  b89193e0b06f media: em28xx - remove reset_resume interface,
  the hang is fixed if I revert this commit on top of v3.17-rc6-247-g005f800.
  
  Regarding the request_firmware issue. I think a possible
  fix would be:

I think you should take a closer look at the code you snipped.
Maybe this fixes the root of the issue you worked around
with the DVB_FE_DEVICE_RESUME thing, namely calling
fe-ops.tuner_ops.init from wrong context.

 The request_firmware has been fixed. I ran into this on
 Hauppauge WinTV HVR 950Q device. The fix is in xc5000
 driver to not release firmware as soon as it loads.
 With this fix firmware is cached and available in
 resume path.
 
 These patches are pulled into linux-media git couple
 of days ago.
 
 http://patchwork.linuxtv.org/patch/26073/
 http://patchwork.linuxtv.org/patch/25345/

The second patch does not apply to current git master (v3.17-rc6-247-g005f800).
Maybe some other patch I need?

 The reset_resume and this request firmware problem
 might be related. Could you please try with the
 above two patches and see if the problems goes away.
 i.e without reverting
 
 b89193e0b06f media: em28xx - remove reset_resume interface
 
 Please let me know even if it works. If it doesn't could
 you please send me full dmesg. I am curious if usb bus
 is reset i.e looses power during hibernate. If it does,
 it has to go through disconnect sequence. The reason
 I removed the reset_resume is because it is a simple
 resume routine that can't handle power loss to the bus.

I tested in qemu, but my real use case is echo shutdown /sys/power/disk
which causes USB power to drop during hibernate on my PC.  Additionally
I'm usually turning off the power completely by physical switch
on the multiple socket outlet.

You can check the dmesg included in my first mail, it shows

[  240.487577]  [81416da4] em28xx_usb_disconnect+0x57/0x6a
[  240.489331]  [8136ec49] usb_unbind_interface+0x75/0x1fd
[  240.491037]  [81315190] __device_release_driver+0x84/0xde
[  240.492792]  [813151ff] device_release_driver+0x15/0x21
[  240.494371]  [8136ee14] usb_driver_release_interface+0x43/0x78
[  240.496276]  [813621ca] ? usb_for_each_dev+0x2b/0x2b
[  240.497788]  [8136ee67] usb_forced_unbind_intf+0x1e/0x25
[  240.499477]  [8136eea6] unbind_marked_interfaces.isra.9+0x38/0x42
[  240.501365]  [8136eef8] usb_resume+0x48/0x5b


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Thu, Sep 25, 2014 at 06:01:34PM +0200, Johannes Stezenbach wrote:
 Hi Shuah,
 
 On Thu, Sep 25, 2014 at 07:45:37AM -0600, Shuah Khan wrote:
  On 09/25/2014 06:53 AM, Johannes Stezenbach wrote:
   ever since your patchset which implements suspend/resume
   for em28xx, hibernating the system breaks the Hauppauge WinTV HVR 930C 
   driver.
   In v3.15.y and v3.16.y it throws a request_firmware warning
   during hibernate + resume, and the /dev/dvb/ device nodes disappears after
   resume.  In current git v3.17-rc6-247-g005f800, it hangs
   after resume.  I bisected the hang in qemu to
   b89193e0b06f media: em28xx - remove reset_resume interface,
   the hang is fixed if I revert this commit on top of 
   v3.17-rc6-247-g005f800.
   
   Regarding the request_firmware issue. I think a possible
   fix would be:
 
 I think you should take a closer look at the code you snipped.
 Maybe this fixes the root of the issue you worked around
 with the DVB_FE_DEVICE_RESUME thing, namely calling
 fe-ops.tuner_ops.init from wrong context.
 
  The request_firmware has been fixed. I ran into this on
  Hauppauge WinTV HVR 950Q device. The fix is in xc5000
  driver to not release firmware as soon as it loads.
  With this fix firmware is cached and available in
  resume path.
  
  These patches are pulled into linux-media git couple
  of days ago.
  
  http://patchwork.linuxtv.org/patch/26073/
  http://patchwork.linuxtv.org/patch/25345/
 
 The second patch does not apply to current git master 
 (v3.17-rc6-247-g005f800).
 Maybe some other patch I need?

FWIW, there are six other xc5000 patches in the queue:

http://git.linuxtv.org/cgit.cgi/media_tree.git/log/drivers/media/tuners/xc5000.c?h=devel-3.17-rc6

I'm assuming this is the development branch for the 3.18 merge window,
so the question is how will the issue be fixed in 3.17 and 3.16-stable?
If you have patches I'm ready to test.

FWIW, I tried v3.17-rc6-247-g005f800 with only my suggested
dvb_frontend_resume() change, it breaks in another place after
resume and then still hangs.  I think the b89193e0b06f revert is needed to 
fix the hang.  If you care, the dmesg after resume:

[1.561456] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[1.562745] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[1.564059] usb usb1: Product: EHCI Host Controller
[1.564941] usb usb1: Manufacturer: Linux 3.17.0-rc6+ ehci_hcd
[1.565974] usb usb1: SerialNumber: :00:04.0
[1.567946] hub 1-0:1.0: USB hub found
[1.568736] hub 1-0:1.0: 6 ports detected
[1.570949] uhci_hcd: USB Universal Host Controller Interface driver
[1.572492] usbcore: registered new interface driver usb-storage
[1.573726] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 
0x60,0x64 irq 1,12
[1.576145] serio: i8042 KBD port at 0x60,0x64 irq 1
[1.577447] serio: i8042 AUX port at 0x60,0x64 irq 12
[1.579250] mousedev: PS/2 mouse device common for all mice
[1.582207] input: AT Translated Set 2 keyboard as 
/devices/platform/i8042/serio0/input/input1
[1.583951] rtc_cmos 00:00: RTC can wake from S4
[1.586862] rtc_cmos 00:00: rtc core: registered rtc_cmos as rtc0
[1.588434] rtc_cmos 00:00: alarms up to one day, 114 bytes nvram, hpet irqs
[1.590157] piix4_smbus :00:01.3: SMBus Host Controller at 0x700, 
revision 0
[1.592999] usbcore: registered new interface driver em28xx
[1.594005] em28xx: Registered (Em28xx v4l2 Extension) extension
[1.595075] em28xx: Registered (Em28xx dvb Extension) extension
[1.596905] usbcore: registered new interface driver usbhid
[1.597934] usbhid: USB HID core driver
[1.598728] TCP: cubic registered
[1.599353] NET: Registered protocol family 17
[1.601375] registered taskstats version 1
[1.603511] rtc_cmos 00:00: setting system clock to 2014-09-25 17:27:49 UTC 
(1411666069)
[1.611018] Freeing unused kernel memory: 2668K (81adc000 - 
81d77000)
[1.612517] Write protecting the kernel read-only data: 10240k
[1.618189] Freeing unused kernel memory: 1260K (8800014c5000 - 
88000160)
[1.622896] Freeing unused kernel memory: 1100K (8800018ed000 - 
880001a0)
Loading, please wait...
[1.638167] init (73) used greatest stack depth: 13880 bytes left
[1.649393] udevd[80]: starting version 175
[1.689799] udevadm (81) used greatest stack depth: 13704 bytes left
[1.758878] ata_id (159) used greatest stack depth: 13512 bytes left
[1.804296] ata_id (168) used greatest stack depth: 12408 bytes left
[1.980161] tsc: Refined TSC clocksource calibration: 3300.000 MHz
[2.032114] usb 1-1: new high-speed USB device number 2 using ehci-pci
modprobe: chdir(3.17.0-rc6+): No such file or directory
Begin: Loading essential drivers ... modprobe: chdir(3.17.0-rc6+): No such file 
or directory
modprobe: chdir(3.17.0-rc6+): No such file or directory
done.
Begin: Running /scripts/init-premount ... done.
Begin

Re: em28xx breaks after hibernate

[Johannes Stezenbach]

On Thu, Sep 25, 2014 at 11:40:45AM -0600, Shuah Khan wrote:
 
 Right. I introduced DVB_FE_DEVICE_RESUME code to resume
 problems in drx39xxj driver. Because I had to make it not
 toggle power on the fe for resume. In other words, for it
 to differentiate between disconnect and resume conditions.
 
 dvb_frontend_resume() is used by dvb_usbv2 dvb_usb_core -
 dvb_usbv2_resume_common()
 
 Calling dvb_frontend_reinitialise() from dvb_frontend_resume()
 could break dvb_usbv2 drivers because it has handling for
 reset_resume in its core in dvb_usbv2_reset_resume()

Needs testing...

 reverting media: em28xx - remove reset_resume interface
 might be a short-term solution. I think the longterm
 solution is adding a dvb_frontend_reset_resume() that
 does dvb_frontend_reinitialise() just like you suggested.
 
 In addition, em28xx will call dvb_frontend_reset_resume()
 from its reset_resume
 
 What do you think?

The dvb_frontend_resume() is also too risky for short term
fix, but I think it does the right thing.  Let's sleep over
it a few nights.

For short term I think there is no way around the
b89193e0b06f revert.  You don't want a kernel with
hang-after-resume bugs to hit major distributions
like Ubuntu.  For the xc5000 firmware issue I think
you should get the patches from the development
branch into 3.17 (and 3.16-stable).  If you have the
patches ready, tell me and I'll test.


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patchwork down?

[Johannes Stezenbach]

On Mon, Oct 07, 2013 at 09:36:31AM +0200, Hans Verkuil wrote:
 Opening https://patchwork.linuxtv.org/ gives me:

Hoster (TUBIT) problem, just wait and hope.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patchwork down?

[Johannes Stezenbach]

On Mon, Oct 07, 2013 at 10:48:40AM +0200, Johannes Stezenbach wrote:
 On Mon, Oct 07, 2013 at 09:36:31AM +0200, Hans Verkuil wrote:
  Opening https://patchwork.linuxtv.org/ gives me:
 
 Hoster (TUBIT) problem, just wait and hope.

It's apparently OK now.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patchwork is down or only for me?

[Johannes Stezenbach]

On Mon, Sep 16, 2013 at 05:01:36PM +0200, Ricardo Ribalda Delgado wrote:
 I was looking to this one:
 https://patchwork.linuxtv.org/project/linux-media/list/
 
 Where the latest patch is https://patchwork.linuxtv.org/patch/20090/
 
 On Mon, Sep 16, 2013 at 4:58 PM, Antti Palosaari cr...@iki.fi wrote:
  On 09/16/2013 05:48 PM, Ricardo Ribalda Delgado wrote:
 
  Hello
 
  I have sent a patch and it does not appear on patchwork, it is also
  slower than usual.
 
  Also a patch from David Jedelsky is not there.
 
 
  At least for now both seems to be there:
  https://patchwork.kernel.org/project/linux-media/list/

Should be fixed now.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Johannes Stezenbach]

On Tue, Jan 15, 2013 at 12:30:46AM -0200, Mauro Carvalho Chehab wrote:
 Add DVBv5 methods to retrieve QoS statistics.

According to http://en.wikipedia.org/wiki/Qos:
Quality of service in computer network trafficking refers
to resource reservation control mechanisms

I think it is misleading to use the term QoS for DVB, what
the patch series seems to be about is receiption or signal quality.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Initial scan files troubles and brainstorming

[Johannes Stezenbach]

On Wed, Jan 09, 2013 at 10:43:23AM +0100, Oliver Schinagl wrote:
 On 08-01-13 21:01, Johannes Stezenbach wrote:
 On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
 On 07-01-13 11:46, Jiri Slaby wrote:
 On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
 Unfortunatly, I have had zero replies.
 Hmm, it's sad there is a silence in this thread from linux-media guys :/.
 In their defense, they are very very busy people ;) chatter on this
 thread does bring it up however.
 This is such a nice thing to say :-)
 But it might be that Mauro thinks the dvb-apps maintainer should
 respond, but apparently there is no dvb-apps maintainer...
 Maybe you should ask Mauro directly to create an account for you
 to implement what you proposed.
 Mauro is CC'ed and I'd ask of course for this (I kinda did) but who
 decides what I suggested is a good idea? I personally obviously
 think it is ;) and even more so if dvb-apps are unmaintained.

Well, if you become the dvb-apps maintainer, then _you_ decide
if it's a good idea.  That's part of the defintion of maintainer :-)
It doesn't hurt to listen to users, but if no one comments
you can do whatever you want with it.

But I'm only acting as kind of a webmaster, Mauro creates the accounts.
So we have to wait for him to respond.

 I guess the question now becomes 'who okay's this change? Who says
 'okay, lets do it this way. Once that is answered we can go from
 there ;)

I guess you could ask the maintainer of the dvb-apps package
of your favourite distribution for opinions, and also check
which other packages depend on dvb-apps.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Initial scan files troubles and brainstorming

[Johannes Stezenbach]

On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote:
 On 07-01-13 11:46, Jiri Slaby wrote:
 On 12/18/2012 11:01 PM, Oliver Schinagl wrote:
 Unfortunatly, I have had zero replies.
 Hmm, it's sad there is a silence in this thread from linux-media guys :/.
 In their defense, they are very very busy people ;) chatter on this
 thread does bring it up however.

This is such a nice thing to say :-)
But it might be that Mauro thinks the dvb-apps maintainer should
respond, but apparently there is no dvb-apps maintainer...
Maybe you should ask Mauro directly to create an account for you
to implement what you proposed.

Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Initial scan files troubles and brainstorming

[Johannes Stezenbach]

On Mon, Jan 07, 2013 at 01:53:25PM +0100, Christoph Pfister wrote:
 
 @Johannes: As I don't need the account anymore, please delete it.

Done.

Thanks for the work you put into it!

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cypress EZ-USB FX2 firmware development

[Johannes Stezenbach]

On Tue, Oct 04, 2011 at 11:29:01PM +0200, Johannes Stezenbach wrote:
 On Tue, Oct 04, 2011 at 10:43:59PM +0300, Antti Palosaari wrote:
  I would like to made own firmware for Cypress FX2 based DVB device.
  Is there any sample to look example?
 
 http://linuxtv.org/cgi-bin/viewvc.cgi/dvb-hw/dvbusb-fx2/termini/

PS: If you haven't found it already, there is also fx2lib:
https://github.com/mulicheng/fx2lib
http://sourceforge.net/projects/fx2lib/

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cypress EZ-USB FX2 firmware development

[Johannes Stezenbach]

On Tue, Oct 04, 2011 at 10:43:59PM +0300, Antti Palosaari wrote:
 I would like to made own firmware for Cypress FX2 based DVB device.
 Is there any sample to look example?

http://linuxtv.org/cgi-bin/viewvc.cgi/dvb-hw/dvbusb-fx2/termini/

HTH
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems cloning the git repostories

[Johannes Stezenbach]

On Mon, Sep 26, 2011 at 06:15:07PM +0800, Scott Jiang wrote:
 2011/9/26 Mauro Carvalho Chehab mauroche...@gmail.com:
  Em 25-09-2011 15:03, Johannes Stezenbach escreveu:
 
  But please don't clone from linuxtv.org, intead use
  git clone git://github.com/torvalds/linux.git
  and then add linuxtv to your repo like described on
  http://git.linuxtv.org/media_tree.git
 
  I've updated the instructions together with the git tree to point to the
  github tree.
 
 I followed your instructions using http instead, but I found it's not
 up to date.

What I meant is the follow the instructions on the
http://git.linuxtv.org/media_tree.git web page,
to use git:// protocol:

  git remote add linuxtv git://linuxtv.org/media_tree.git
  git remote update
  git checkout -b media-master remotes/linuxtv/staging/for_v3.2

Anyway, I did the git update-server-info thing so http should
work, too.  But git over http sucks, if you can then use git protocol.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wiki update

[Johannes Stezenbach]

So it seemes like MediaWiki-1.14.1 is somewhat broken with PHP-5.3.3
and there have been issues with both the VDR and V4L-DVB Wikis.
Thus I've updated MediaWiki to 1.16.5, and full functionality
seems to be restored.

Please let me know if there are still any issues.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LinuxTV.org wiki broken - won't allow edits

[Johannes Stezenbach]

On Sat, Aug 06, 2011 at 10:11:15AM -0400, Devin Heitmueller wrote:
 Well, now I understand why there hasn't been any spam on the
 linuxtv.org wiki for a couple of weeks.  Editing is broken.
 
 Attempts to edit articles shows:
 
 Internal error

Thanks for letting me know, it should be fixed now.
It was broken since the system update on July 21.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Create account on linuxtv wiki broken

[Johannes Stezenbach]

On Thu, Jul 28, 2011 at 02:14:14PM +0200, Gary van der Merwe wrote:
 
 I want to fix a url on http://linuxtv.org/wiki/ , but I got 
 an internal server error when I tried to create an account. 
 To whom/where should I report this?

To the webmaster, of course.  Anyway, thanks for reporting
and please try again, I think it is fixed.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linuxtv.org downtime

[Johannes Stezenbach]

Hi,

there will be two hours (or so) of downtime today due to software upgrades.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linuxtv.org downtime

[Johannes Stezenbach]

On Thu, Jul 21, 2011 at 11:27:54AM +0200, Johannes Stezenbach wrote:
 there will be two hours (or so) of downtime today due to software upgrades.

It's all done, please let me know if something doesn't work.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] get rid of on-stack dma buffers

[Johannes Stezenbach]

On Tue, Mar 22, 2011 at 11:59:32AM +0100, Jiri Kosina wrote:
 On Mon, 21 Mar 2011, Florian Mickler wrote:
 
  To be blunt, I'm not shure I fully understand the requirements myself. 
  But as far as I grasped it, the main problem is that we need memory 
  which the processor can see as soon as the device has scribbled upon it. 
  (think caches and the like)
  
  Somewhere down the line, the buffer to usb_control_msg get's to be a 
  parameter to dma_map_single which is described as part of the DMA API in 
  Documentation/DMA-API.txt
  
  The main point I filter out from that is that the memory has to begin
  exactly at a cache line boundary... 
  
  I guess (not verified), that the dma api takes sufficient precautions to 
  abort the dma transfer if a timeout happens.  So freeing _should_ not be 
  an issue. (At least, I would expect big fat warnings everywhere if that 
  were the case)
  
  I cc'd some people that hopefully will correct me if I'm wrong...
 
 It all boils down to making sure that you don't free the memory which is 
 used as target of DMA transfer.
 
 This is very likely to hit you when DMA memory region is on stack, but 
 blindly just converting this to kmalloc()/kfree() isn't any better if you 
 don't make sure that all the DMA transfers have been finished and device 
 will not be making any more to that particular memory region.

I think it is important that one cache line is not shared between
a DMA buffer and other objects, especially on architectures where
cache coherency is managed in software (ARM, MIPS etc.).  If you
use kmalloc() for the DMA buffer that is guaranteed.
(E.g. DMA API will do writeback/invalidate before the DMA starts, but
if the CPU accesses a variable which is next to the buffer
while DMA is still pending then the whole cacheline is read back into
the cache.  If the CPU is then trying to read the DMA buffer after
the DMA finished it will see stale data from the cache.  You lose.)

It depends on the device doing DMA if it needs special alignment.
If you meet its alignment requirements, and wait for the end of the DMA before
returning, and make sure the buffer does not share cache lines with
neighbouring objects on the stack, then you can use DMA buffers on
stack.  In practice it's simpler and much less error prone to use kmalloc().

Regarding usb_control_msg(), since it is a synchronous API which
waits for the end of the transfer I'm relatively sure there is no
DMA pending when it returns, even if it aborts with timeout or any
other error code.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Debug code in HG repositories

[Johannes Stezenbach]

On Mon, Jan 10, 2011 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
 Em 07-01-2011 21:42, Theodore Kilgore escreveu:
  
  Have you tried Mauro's media_build tree? I had to use it today to test a
  driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we 
  should
  promote this more. 
  
  Probably a good idea. I have been too busy to know about it, myself. And I 
  even do try to keep up with what is going on.
  
  I could add backwards compatibility builds to my 
  daily
  build script that uses this in order to check for which kernel versions
  this compiles if there is sufficient interest.
...
 I think Hans can enable it. The backport effort on media-build is a way
 easier than with -hg. For example, in order to support kernel 2.6.31 (the 
 oldest
 one on that tree), we need only 10 patches. The patches themself are simple:
 
 $ wc -l *.patch
61 v2.6.31_nodename.patch
   540 v2.6.32_kfifo.patch
42 v2.6.33_input_handlers_are_int.patch
70 v2.6.33_pvrusb2_sysfs.patch
40 v2.6.34_dvb_net.patch
22 v2.6.34_fix_define_warnings.patch
16 v2.6.35_firedtv_handle_fcp.patch
   104 v2.6.35_i2c_new_probed_device.patch
   145 v2.6.35_work_handler.patch
   104 v2.6.36_input_getkeycode.patch
  1144 total
 
 And almost all patches are trivial.

FWIW, linux-wireless developers maintain a generic compat tree used
for backporting wireless drivers:
http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat.git;a=summary

I suppose it might be useful to share this between linux-wireless
and linux-media?


(It is used together with three other trees to autobuild
the compat-wireless releases.
http://wireless.kernel.org/en/users/Download

It works like that:
- compat.git: generic backporting layer
- compat-wireless-2.6.git: build system
- compat-user.git: autobuild scripts called via cron
- wireless-testing.git: linux-wireless development tree

(wireless-testing.git is based on latest stable kernel but with
the wireless code from linux-next)

compat-wireless releases are not meant for development, but
they can be used as a build system together with a wireless-testing.git
tree and a few symlinks.)


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to handle independent CA devices

[Johannes Stezenbach]

Hi Ralph,

On Thu, Sep 09, 2010 at 11:52:25PM +0200, rjkm wrote:
 
 cards like the Digital Devices DuoFlex S2, cineS2 and upcoming 
 hardware (octuple, network, etc.) have independent CA devices.
 This means that instead of having the stream routed from the frontend 
 through the CI and only then into memory a stream can be sent from
 memory through the CI and back. So, the current device model does not
 fit this hardware.
 
 One could hide this fact inside the driver and send the stream from
 the frontend through the CI transparently to the API but this would
 prevent people from implementing new features like decoding a stream from 
 a different DVB card, decoding streams from hard disk or even decoding
 several sub-streams from different transponders.
 The latter works with the current Windows driver but I have not
 implemented it in Linux yet. It also has to be supported by the CI
 modules. Some can decode 12 streams (6 times video/audio) at once.
 
 But decoding single streams already works fine. Currently, I am 
 registering a different adapter for the CI.
 On a CineS2 with CI attached at the IO port I then have
 
 /dev/dvb/adapter[01] for the two DVB-S2 frontends and
 /dev/dvb/adapter2 just for the ca0 device.
 
 I am abusing the unused sec0 to write/read data to/from the CI module.
 For testing I hacked zap from dvb-apps to tune on adapter0 but 
 use adapter2/ca0 to talk to the CI module.
 I then write the encrypted stream from adapter0/dvr0 into 
 adapter2/sec0 and read the decoded stream back from adapter2/sec0.
 The encrypted stream of course has to contain all the PIDs of the
 ca_pmt. 
 
 So, I would like to hear your opinions about how to handle such CA devices 
 regarding device names/types, the DVB API and user libraries.

it looks like there isn't much interest from DVB developers
in that topic...  I'll try...


IMHO there are three sub topics:

1. be compatible with existing applications
   (I guess this means: feed stream from frontend through CI transparently)
2. create an API which would also work for CI-only
   devices like this Hauppauge WinTV-CI USB thingy
3. how to switch between these modes?

This sec0 device is history (unused and deprecated for years), right?
How about the following:
Rename it to ci0.  When ci0 is closed the stream is routed
transparently from frontend through CI, if it's opened one needs to
read/write the stream from userspace.


If you can't get responses here I guess you could talk to
vdr or other application developers.  After all they'll have
to use the API.


Cheers,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DIKOM DK300: Kernel hangs after suspend to ram

[Johannes Stezenbach]

On Tue, Sep 07, 2010 at 10:47:55PM +0200, andrea.amoros...@gmail.com wrote:
 I'm trying to use my Dikom DK-300 usb dvb-t device connected to an
 old laptop used as media player.
 The device works well but if I suspend the pc to ram (S3) when the
 Dikom usb stick is plugged in, the system hangs during the resume
 phase.
 So I've tried to create two scripts. The first one removes the driver
 before sleeping (the script is in the /etc/acpi/suspend.d directory)
 and the second one reloads it during the resume phase (this script is
 in /etc/acpi/resume.d directory).
 I've also inserted in the scripts some logs and it seems that the
 driver is correctly removed before the suspension, but then the pc
 hangs when resuming.
 Do you have some suggestion on how to resolve?
 I suspect that something in the GPIO setting is not corrected, but I
 don't know very well how to check that (now I've access to a windows
 xp virtualbox machine and a real windows vista system which maybe I
 can use to test/debug the correctness of the patch I postes some
 time ago).

Can't help you with the driver, but for general suspend/resume debug:
Did you try no_console_suspend to see if there are any errors?
See Documentation/kernel-parameters.txt for more info.
There are also some debugging hints in Documentation/power/s2ram.txt
and basic-pm-debugging.txt.

HTH
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] linuxtv.org server move Wed, 10 Feb 2pm CET

[Johannes Stezenbach]

On Wed, Feb 10, 2010 at 06:29:37PM +0100, Johannes Stezenbach wrote:
 On Mon, Feb 08, 2010 at 11:51:14PM +0100, Johannes Stezenbach wrote:
  
  the linuxtv.org server is going to be moved to a new location
  on Wednesday, around 2pm CET (UTC+1:00).
 
 As you might have noticed, that point in time came and went
 and nothing happened.
 
 Next try tomorrow, around the same time.

The move is complete, the new IP address is 130.149.80.248.
Please report if something doesn't work.

(Note that you can't access git.linuxtv.org via the IP address
because it is a named virtual server.  You can add it to
/etc/hosts if you don't want to wait until DNS updates
have propagated.)


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] linuxtv.org server move Wed, 10 Feb 2pm CET

[Johannes Stezenbach]

On Mon, Feb 08, 2010 at 11:51:14PM +0100, Johannes Stezenbach wrote:
 
 the linuxtv.org server is going to be moved to a new location
 on Wednesday, around 2pm CET (UTC+1:00).

As you might have noticed, that point in time came and went
and nothing happened.

Next try tomorrow, around the same time.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linuxtv.org server move Wed, 10 Feb 2pm CET

[Johannes Stezenbach]

Hi,

the linuxtv.org server is going to be moved to a new location
on Wednesday, around 2pm CET (UTC+1:00).
There'll be a bit of downtime.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] git tree repositories

[Johannes Stezenbach]

On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote:
 
 BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to 
 mention right now, that one big difference to HG in the way we have used it, 
 is 
 that one developer now can do all the work only with one clone of v4l-dvb and 
 using branches for each development.

Please note that you SHOULD NOT clone from linuxtv.org.
Please follow the description on the top of
http://linuxtv.org/git/

Most linux developers will have a clone of Linus' tree already,
and you can add as many remotes to that tree as you like.
It's much faster and more flexible that way.  If you once pulled
a clone of Linus' tree there is simply no need to ever clone
any other Linux tree ever again.

Oh, and if you manage to get your git tree in a state where
you don't know how to fix the mess, don't throw it away.
Go to the git mailing list and ask for advice. They love
customer feeedback. Helps them to improve their product
and make it more user friendly ;-)


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] git tree repositories

[Johannes Stezenbach]

Hi,

may I humbly request to make it mandatory to enter a description
when a user creates a new tree on linuxtv.org?
IMHO foobar development repository isn't useful at all.

If I look at http://linuxtv.org/hg/ many times I have no
clue what a repo is about or why it exists at all.
Let's not repeat the same mistake with git.

OTOH, since with git it is common to have multiple branches
within one repository, I'm not sure how it works. It would
be cool if git would support per-branch descriptions,
and git web could display them.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hyperlinks in linuxtv.org mercurial RSS feeds broken

[Johannes Stezenbach]

On Fri, Sep 11, 2009 at 02:59:22PM +0200, Matthias Schwarzott wrote:
 
 After having reported this some weeks ago, the hyperlinks in the linuxtv.org 
 mercurial RSS feeds are still broken.
 
 In this feed: http://linuxtv.org/hg/v4l-dvb?cmd=changelog;style=rss
 a link looks like this:
 http://linuxtv.orghttp//linuxtv.org/hg/v4l-dvb/rev/13c47deee3b1

I'm sorry, I forgot to come back to you on this.  I reported
this bug upstream and I'm still waiting for a fix.
http://mercurial.selenic.com/bts/issue1772


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Johannes Stezenbach]

On Tue, Aug 18, 2009 at 10:07:04AM -0400, Devin Heitmueller wrote:
  The risk of
 trusting some random Linux developer's driver work is a reason why
 some vendors don't want to support Linux.  If I were a vendor, and I
 endorsed a Linux driver written by someone without the appropriate
 knowledge of the hardware, I could end up with large number of product
 returns, and I would incur the cost of those losses.

This is an interesting statement.  Let me rephrase it:

If I were a vendor selling ill-designed hardware which can
be permanently damaged by buggy software, I'd make sure
as hell that I get the information about how to avoid the
damage out to every Open Source developer.  Otherwise
I would have to live with the risk of seeing an increased
rate of product returns.


BTW, there is a big difference of after I plugged the device
in under Linux it was dead and it runs hot under Linux, that might
shorten the life span.  I hope there is no hardware of the first
kind.  For the second kind you can fairly safely experiment until
you solved the problem.


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]

[Johannes Stezenbach]

On Mon, Aug 17, 2009 at 04:59:42PM -0400, Michael Krufky wrote:
 
 variations, nobody has ever verified that the GPIO programming is safe
 to use, and there is no way to prevent the potentially harmful code
 from running on the wrong device.
 
 I, personally, do not want the responsibility of explaining to users
 that their usb sticks may be damaged because of code that got merged

I would be interested to know if someone _actually_ managed
to break their hardware by using buggy drivers.  IANAL but
I think that consumer electronics hardware which can be damaged by
software is broken by design.  A vendor selling such hardware is
stupid because people would return the broken hardware and get
a replacement.  I don't see how a vendor could proof that the device
was not damaged by an obscure bug in the Windows driver to get
around their responsibility to replace broken hardware within
the warranty period.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cinergy T2 stopped working with kernel 2.6.30

[Johannes Stezenbach]

On Fri, Jul 31, 2009 at 08:44:59PM +0200, emag...@magic.ms wrote:
 
 static int cinergyt2_fe_set_frontend(struct dvb_frontend *fe,
 struct dvb_frontend_parameters *fep)
 {
   struct cinergyt2_fe_state *state = fe-demodulator_priv;
   struct dvbt_set_parameters_msg param;
   char result[2];
   int err;
 
   param.cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
   param.tps = cpu_to_le16(compute_tps(fep));
   param.freq = cpu_to_le32(fep-frequency / 1000);
   param.bandwidth = 8 - fep-u.ofdm.bandwidth - BANDWIDTH_8_MHZ;
 
   err = dvb_usb_generic_rw(state-d,
   (char *)param, sizeof(param),
   result, sizeof(result), 0);
 
 
 As dvbt_set_parameters_msg is declared with __attribute__((packed)), its
 alignment is 8 bits.  In fact, cinergyt2_fe_set_frontend()'s param variable
 is not aligned on a 32-bit boundary. Note that param is passed to 
 usb_bulk_msg().
 This seems to cause DMA problems on my hardware (Atom N270 + 945GSE + ICH7M).

I doubt that.  AFAIK EHCI has no alignment requirements on data, and the
x86 architecture has DMA consistent caches.  The code in question is
broken on ARM. MIPS etc. but it should work (and according to you has
worked up to 2.6.29) on x86.  (I'm not at all against fixing the
code for MIPS/ARM but I don't think that would fix the problem for you.)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patch for stack/DMA problems in Cinergy T2 drivers (2)

[Johannes Stezenbach]

On Fri, Jul 31, 2009 at 10:25:20PM +0200, emag...@magic.ms wrote:
 Here's a patch for cinergyT2-core.c:
 
 --- a/drivers/media/dvb/dvb-usb/cinergyT2-fe.c2009-06-10 
 05:05:27.0 +0200
 +++ b/drivers/media/dvb/dvb-usb/cinergyT2-fe.c2009-07-31 
 22:02:48.0 +0200
 @@ -146,66 +146,103 @@
   fe_status_t *status)
  {
   struct cinergyt2_fe_state *state = fe-demodulator_priv;
 - struct dvbt_get_status_msg result;
 - u8 cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
 + struct dvbt_get_status_msg *result;
 + static const u8 cmd0[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
 +u8 *cmd;
   int ret;
 
 - ret = dvb_usb_generic_rw(state-d, cmd, sizeof(cmd), (u8 *)result,
 - sizeof(result), 0);
 - if (ret  0)
 +cmd = kmalloc(sizeof(cmd0), GFP_KERNEL);
 +if (!cmd) return -ENOMEM;
 +memcpy(cmd, cmd0, sizeof(cmd0));
 +result = kmalloc(sizeof(*result), GFP_KERNEL);
 +if (!result) {
 +kfree(cmd);
 +return -ENOMEM;
 +}
 + ret = dvb_usb_generic_rw(state-d, cmd, sizeof(cmd0), (u8 *)result,
 + sizeof(*result), 0);
 +kfree(cmd);
 + if (ret  0) {
 +kfree(result);
   return ret;
 +}

There is a fair amount of code duplication.  A better aproach would
be to allocate buffers once in cinergyt2_fe_attach()
(add them to struct cinergyt2_fe_state).

And please observe http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linuxtv.org downtime today due to software updates

[Johannes Stezenbach]

Hi,

sorry for short notice, but today I have enough spare time
to do the long overdue Etch - Lenny update on linuxtv.org.
ssh and http access wil be blocked during the update.
I'll start in one or two hours from now and expect it to
take about two hours.


Cheers,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linuxtv.org downtime today due to software updates

[Johannes Stezenbach]

On Sun, Jul 26, 2009 at 02:37:09PM +0200, Johannes Stezenbach wrote:
 
 sorry for short notice, but today I have enough spare time
 to do the long overdue Etch - Lenny update on linuxtv.org.
 ssh and http access wil be blocked during the update.
 I'll start in one or two hours from now and expect it to
 take about two hours.

Mission accomplished.

Please note that I installed mercurial-1.3.1 on the server
and used the default paper style in favour of the
linuxtv-customized gitweb style, because it has this nice
merge graph feature.

Let me know if something isn't working as expected.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ancient hg repositories: delete?

[Johannes Stezenbach]

Hi,

A number of user repositories on linuxtv.org haven't
been updated for years:

http://linuxtv.org/hg?sort=-lastchange

I suspect that most of them have become totally irrelevant
and just clutter up the repository list, making it less
user friendly, and using up disk space. Probably the changes
they contain have been merged long ago and the user just forgot
to delete the repo?


Can somebody tell me please why I shouldn't go and
just delete all repositories which haven't been touched
in the last 12 months?  IOW, unless I hear otherwise,
I'm going to delete the cruft after Sep. 1.


Thanks,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

old V4L Wiki

[Johannes Stezenbach]

Hi,

the merge of the content from the old V4L Wiki into
the V4L-DVB Wiki has been nearly completed, but seems
to have come to a halt?  I would like to kill off the
old V4L Wiki soon.  IMHO most of the remaining pages
are old user discussions, maybe it's best
if the users themselves take care of copying it over
to the V4L-DVB Wiki if they think their content is
still relevant.

My plan is to delete the old Wiki soon after Sep. 1.

New account creation in the V4L Wiki has been disabled.


List of remaining pages:
http://linuxtv.org/v4lwiki/index.php/Special:AllPages

  Namespace Main:
Em2880/remote
Firewire devices
People behind V4L
Wiki merger

  Namespace Talk:
Em2820

  Namespace User:
Fabien
Gouchi
Hthevath
IDamir
Jkrzyszt
Lucarasp
Lux
MarkusRechberger/Bugs
Mpapet
Navratil
Peter
Sakis
Satarsa
SunnyBUG
Tobru
TvY2k
Varogami

  Namespace User-talk:
Heiner
Liplianin
Luckyboy
Nvicf
Santod
Satarsa
Uniface


Thanks
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Wiki software update

[Johannes Stezenbach]

Hi Hermann,

On Mon, Jun 01, 2009 at 02:08:07AM +0200, hermann pitton wrote:
 Am Montag, den 01.06.2009, 01:28 +0200 schrieb Johannes Stezenbach:
  
  I just updated the V4L-DVB Wiki and the old V4L Wiki
  to MediaWiki-1.14.0. Please let me know in case
  something broke.
 
 did not test all links, but on this one some older issues seem to still
 perpetuate.
 
 http://www.linuxtv.org/wiki/index.php?title=How_to_Perform_a_Bisectaction=edit
 
 I get, that I'm not allowed to do that.

Well, you need to be logged in to create or edit pages. Or are
you saying that you cannot edit this page even though you are logged in?


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Wiki software update

[Johannes Stezenbach]

On Mon, Jun 01, 2009 at 12:14:08PM +1000, Robin Perkins wrote:
 On 01/06/2009, at 9:28 AM, Johannes Stezenbach wrote:

 I just updated the V4L-DVB Wiki and the old V4L Wiki
 to MediaWiki-1.14.0. Please let me know in case
 something broke.

 Is there any possibility of renaming the v4l-dvb wiki to perhaps the  
 Linux-media Wiki just to get some persistence in names ? (I have had  
 people on irc ask if v4l-dvb can only do dvb.) Perhaps reflect that  
 Linux-media does more than just DVB on the LinuxTV main page as well?

I'd be fine with a rename, but I leave it up the Wiki power
users to decide. The links on http://wiki.kernel.org/ should
also be changed.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wiki software update

[Johannes Stezenbach]

Hi,

I just updated the V4L-DVB Wiki and the old V4L Wiki
to MediaWiki-1.14.0. Please let me know in case
something broke.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wiki on linixtv.org locked

[Johannes Stezenbach]

On Tue, Apr 28, 2009 at 01:21:51AM +0200, H. Langos wrote:
 On Tue, Apr 28, 2009 at 12:14:16AM +0200, Johannes Stezenbach wrote:
  On Mon, Apr 27, 2009 at 10:29:25PM +0200, H. Langos wrote:
   
   if i remember right, the linuxtv wiki only allows editing to registered 
   users. therefore you could simply temporarily disable new user 
   registration
   and enable editing again for registered users.
  
  I will do the update first.

...and of course I ran into problems when updating the extensions,
and then ran out of time. So for the moment I followed your suggestion
and enabled editing but disabled account creation.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wiki on linixtv.org locked

[Johannes Stezenbach]

On Mon, Apr 27, 2009 at 06:43:21PM +0200, H. Langos wrote:
 
 Yesterday a stupid kid vandalized a bunch of pages on the linuxtv wiki and 
 a sysop locked to database to undo the damage. 
 
 I would have preferred to undo that damage by simply taking a look at 
 the users contribution page and using the handy-dandy undo function as a
 mere wiki user. 
 
 It would have deprived that individual the satifaction of gaining the 
 sysop's attention with his anti-social behavior, but thats probably a 
 policy decision that is not mine to make.

The damage was done by a bot script and it affected as many pages
as the edit rate limiter would allow it to do until I noticed it.
If you search for GRAWP'S MASSIVE you'll see this is not
limited to linuxtv.org.

 Anyway .. Now, after about 24h the wiki is still locked.
 Any reason for that?

It is locked until I had time to take measures to prevent
similar damage from happening again right away. I'm
open to suggestions if someone has experience with this.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wiki on linixtv.org locked

[Johannes Stezenbach]

On Mon, Apr 27, 2009 at 10:29:25PM +0200, H. Langos wrote:
 
 the next step would be to update the mediwiki software to 1.11.1 if you have
 $wgEnableAPI = true, that is. (i know it is only a XSS that hits internet 
 explorer users ..  but hey, they are people, too ;-)

I will update to 1.14.0. This is the current version, and it is
also used by wiki.kernel.org (there is a secret plan to eventually
move the wiki there). And all the shiny new anti-spam extensions
don't seem to work with 1.11 anymore...

 if i remember right, the linuxtv wiki only allows editing to registered 
 users. therefore you could simply temporarily disable new user registration
 and enable editing again for registered users.

I will do the update first.

 then i'd suggest installing the reCAPTCHA extention. not only will it
 prevent bots from registering, you also help to digitize old books.
 
 http://recaptcha.net/plugins/mediawiki/

Looked at that and noticed they don't provide any statement
regarding confidentiality / data protection. Who knows if
they aren't creating a huge database of who did what in Wikis
and Blogs around the net...

Besides that, this wouldn't have stopped the present attack
since the bot used does a manual login assisted by a human user.
To thwart that I'd have to enable the captcha for every page save...


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] [ADMIN] linuxtv.org is moving

[Johannes Stezenbach]

On Fri, Mar 27, 2009 at 10:44:33AM +1000, Torgeir Veimo wrote:

 So how do I unsubscribe from linux-dvb? It seems that I still gets some 
 mails from this list, but information on how to unsubscribe is lost from 
 the website.

Every mail from the list contains the link for the
Mailman web interface.

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ADMIN] linuxtv.org is moving

[Johannes Stezenbach]

On Fri, Mar 27, 2009 at 02:20:58AM +0200, Antti Palosaari wrote:

 [cr...@localhost v4l-dvb]$ hg push  
 ssh://ant...@linuxtv.org/hg/~anttip/af9015
 pushing to ssh://ant...@linuxtv.org/hg/~anttip/af9015
 searching for changes
 remote: abort: No space left on device
 [cr...@localhost v4l-dvb]$ host linuxtv.org
 linuxtv.org has address 217.160.6.122

 I removed 5-6 my old devel trees, still no space :o

This issue should be resolved now, /tmp had insufficient space.

BTW: it is faster and uses less disk space to use hg-menu to
clone the v4l-dvb tree on the server (hg then uses hardlinks),
and push your changes on top of it.

  ssh -t ant...@linuxtv.org hg-menu

Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ADMIN] linuxtv.org is moving

[Johannes Stezenbach]

On Wed, Mar 25, 2009 at 05:25:41PM +0100, Johannes Stezenbach wrote:
 
 linuxtv.org will move to a new server machine tomorrow. Expect
 some downtime during the move and please be patient. Everything
 on the old machine will be rsynced to the new machine right before
 the switch so nothing should get lost.

The move is done, but the DNS updates are not out there yet,
so especially mail won't work yet until the caches are updated,
but everything else should.

The new IP address is 217.160.6.122.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ADMIN] linuxtv.org is moving

[Johannes Stezenbach]

Hi,

linuxtv.org will move to a new server machine tomorrow. Expect
some downtime during the move and please be patient. Everything
on the old machine will be rsynced to the new machine right before
the switch so nothing should get lost.


Cheers,
Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html