<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lwn.git/drivers/firewire/ohci.c, branch v3.13-rc8</title>
<subtitle>Linux kernel documentation tree maintained by Jonathan Corbet</subtitle>
<id>http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v3.13-rc8</id>
<link rel='self' href='http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v3.13-rc8'/>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/'/>
<updated>2013-08-29T20:35:05+00:00</updated>
<entry>
<title>firewire: ohci: Fix deadlock at bus reset</title>
<updated>2013-08-29T20:35:05+00:00</updated>
<author>
<name>Stephan Gatzka</name>
<email>stephan.gatzka@gmail.com</email>
</author>
<published>2013-08-26T18:50:05+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=db9ae8fec7b19f0ac6c60d998cac968d801a998d'/>
<id>urn:sha1:db9ae8fec7b19f0ac6c60d998cac968d801a998d</id>
<content type='text'>
Put bus_reset_work into its own workqueue.  By doing this, forward
progress of bus_reset_work() is guaranteed if the work is switched over
to a rescuer thread.

Switching work to a rescuer thread happens if a new worker thread could
not be allocated in certain time (MAYDAY_INITIAL_TIMEOUT, typically 10
ms).  This might not be possible under high memory pressure or even on a
heavily loaded embedded system running a slow serial console.

The former deadlock occured in the following situation:
The rescuer thread ran
fw_device_init-&gt;read_config_rom-&gt;read_rom-&gt;fw_run_transaction.
fw_run_transaction blocked waiting for the completion object.
This completion object would have been completed in bus_reset_work,
but this work was never executed in the rescuer thread due to its
strictly sequential behaviour.

[Stefan R.:  Removed WQ_NON_REENTRANT flag from allocation because
it is no longer needed in current kernels.  Add it back if you backport
to kernels older than 3.7, i.e. one which does not contain dbf2576e37da
"workqueue: make all workqueues non-reentrant".  Swapped order of
destroy_workqueue and pci_unregister_driver.]

Signed-off-by: Stephan Gatzka &lt;stephan.gatzka@gmail.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: Change module_pci_driver to module_init/module_exit</title>
<updated>2013-08-29T20:30:54+00:00</updated>
<author>
<name>Stephan Gatzka</name>
<email>stephan.gatzka@gmail.com</email>
</author>
<published>2013-08-26T18:50:04+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=7a723c6ed9e92bf91db5c65542c78106030afdbe'/>
<id>urn:sha1:7a723c6ed9e92bf91db5c65542c78106030afdbe</id>
<content type='text'>
This is a prerequisite to allocate a per driver self_id workqueue.
This reverts the ohci.c part of patch
fe2af11c220c7bb3a67f7aec0594811e5c59e019.

Signed-off-by: Stephan Gatzka &lt;stephan.gatzka@gmail.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: beautify some macro definitions</title>
<updated>2013-08-19T07:02:05+00:00</updated>
<author>
<name>Stefan Richter</name>
<email>stefanr@s5r6.in-berlin.de</email>
</author>
<published>2013-08-05T13:14:36+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=0dbe15f88be5b2cdf4ca4145797861dfb0d583a5'/>
<id>urn:sha1:0dbe15f88be5b2cdf4ca4145797861dfb0d583a5</id>
<content type='text'>
a) Sort device IDs by vendor -- device -- revision.

b) Write quirk flags in hexadecimal.  This affects the user-visible
output of "modinfo firewire-ohci".  Since more flags have been added
recently, it is now easier to cope with them in hexadecimal represen-
tation.  Besides, the device-specific combination of quirk flags is
shown in hexadecimal in the kernel log too.  (And firewire-sbp2
presents its own quirk flags in modinfo as hexadecimals as well.)

Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: change confusing name of a struct member</title>
<updated>2013-08-19T07:02:05+00:00</updated>
<author>
<name>Stefan Richter</name>
<email>stefanr@s5r6.in-berlin.de</email>
</author>
<published>2013-08-05T13:10:38+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=af53122a2a6239ef235e55cedc324499e31dad87'/>
<id>urn:sha1:af53122a2a6239ef235e55cedc324499e31dad87</id>
<content type='text'>
We have got

	struct descriptor *descriptors;
	dma_addr_t         descriptors_bus;

	dma_addr_t         buffer_bus;
	struct descriptor buffer[0];

	void      *misc_buffer;
	dma_addr_t misc_buffer_bus;

	__be32    *config_rom;
	dma_addr_t config_rom_bus;
	__be32    *next_config_rom;
	dma_addr_t next_config_rom_bus;

But then we have got

	__le32    *self_id_cpu;
	dma_addr_t self_id_bus;

Better apply the pattern of xyz vs. xyz_bus to self_id vs. self_id_bus
as well.  The _cpu suffix looks particularly weird in conversions from
little endian to CPU endian.

Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: fix libdc1394/FlyCap2 iso event regression</title>
<updated>2013-07-27T18:24:36+00:00</updated>
<author>
<name>Clemens Ladisch</name>
<email>clemens@ladisch.de</email>
</author>
<published>2013-07-22T19:32:09+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=0699a73af3811b66b1ab5650575acee5eea841ab'/>
<id>urn:sha1:0699a73af3811b66b1ab5650575acee5eea841ab</id>
<content type='text'>
Commit 18d627113b83 (firewire: prevent dropping of completed iso packet
header data) was intended to be an obvious bug fix, but libdc1394 and
FlyCap2 depend on the old behaviour by ignoring all returned information
and thus not noticing that not all packets have been received yet.  The
result was that the video frame buffers would be saved before they
contained the correct data.

Reintroduce the old behaviour for old clients.

Tested-by: Stepan Salenikovich &lt;stepan.salenikovich@gmail.com&gt;
Tested-by: Josep Bosch &lt;jep250@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.4+
Signed-off-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: dump_stack() for PHY regs read/write failures</title>
<updated>2013-04-30T18:30:16+00:00</updated>
<author>
<name>Peter Hurley</name>
<email>peter@hurleysoftware.com</email>
</author>
<published>2013-03-27T10:57:40+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=6fe9efb9c9fbce690018c31e652924ae28019868'/>
<id>urn:sha1:6fe9efb9c9fbce690018c31e652924ae28019868</id>
<content type='text'>
A stack trace is an invaluable tool in determining the basis
and cause of PHY regs read/write failures.

Include PHY reg addr (and value for writes) in the diagnostic.

[Stefan R:  changed whitespace]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: Improve bus reset error messages</title>
<updated>2013-04-30T18:30:16+00:00</updated>
<author>
<name>Peter Hurley</name>
<email>peter@hurleysoftware.com</email>
</author>
<published>2013-03-27T10:56:01+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=67672134aaafd520a61dda448a662336e8fde236'/>
<id>urn:sha1:67672134aaafd520a61dda448a662336e8fde236</id>
<content type='text'>
Many of the error messages possible from bus_reset_work() do not
contain enough information to distinguish which error condition
occurred nor enough information to evaluate the error afterwards.

Differentiate all error conditions in bus_reset_work(); add
additional information to make error diagnosis possible.

[Stefan R:  fixed self-ID endian conversion]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: Alias dev_* log functions</title>
<updated>2013-04-30T18:30:16+00:00</updated>
<author>
<name>Peter Hurley</name>
<email>peter@hurleysoftware.com</email>
</author>
<published>2013-03-26T15:54:06+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=de97cb64a959fe5ccf828b02d3a78de9f9defb67'/>
<id>urn:sha1:de97cb64a959fe5ccf828b02d3a78de9f9defb67</id>
<content type='text'>
Convert dev_xxxx(ohci-&gt;card.device, ...) log functions to
ohci_xxxx(ohci, ...).

[Stefan R:  Peter argues that this increases readability of the code.]
[Stefan R:  changed whitespace]

Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8</title>
<updated>2013-04-30T18:30:15+00:00</updated>
<author>
<name>Peter Hurley</name>
<email>peter@hurleysoftware.com</email>
</author>
<published>2013-04-28T21:24:08+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=bd972688eb2404239a8f1255db26b0bb6b604686'/>
<id>urn:sha1:bd972688eb2404239a8f1255db26b0bb6b604686</id>
<content type='text'>
With the LSI FW643 rev 8 [1], the first commanded bus reset at
the conclusion of ohci_enable() has been observed to fail with
the following messages:

[    4.884015] firewire_ohci 0000:01:00.0: failed to read phy reg
....
[    5.684012] firewire_ohci 0000:01:00.0: failed to read phy reg

With drivers/firewire/ohci.c instrumented, the error condition [2]
indicates the PHY arbitration state machine has timed out prior to
enabling PHY LCtrl.

Furthermore, instrumenting ohci_enable() shows that LPS has been
enabled within 1 ms.

Test LPS latching every 1 ms rather than every 50ms.

[1]  lspci -v

01:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08) (prog-if 10 [OHCI])
	Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller
	Flags: bus master, fast devsel, latency 0, IRQ 92
	Memory at fbeff000 (64-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 3
	Capabilities: [4c] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [60] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [170] Device Serial Number 08-14-43-82-00-00-41-fc
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci

[2] instrumented WARNING in read_phy_reg()

[    4.576010] ------------[ cut here ]------------
[    4.576035] WARNING: at ./drivers/firewire/ohci.c:570 read_phy_reg+0x93/0xe0 [firewire_ohci]()
[    4.576050] Hardware name: Precision WorkStation T5400
[    4.576058] failed to read phy reg:1 (phy(5) @ config enhance:19)
[    4.576068] Modules linked in: hid_logitech_dj hid_generic(+) usbhid &lt;...snip...&gt;
[    4.576140] Pid: 61, comm: kworker/2:1 Not tainted 3.8.0-2+fwtest-xeon #2+fwtest
[    4.576149] Call Trace:
[    4.576160]  [&lt;ffffffff8105468f&gt;] warn_slowpath_common+0x7f/0xc0
[    4.576168]  [&lt;ffffffff81054786&gt;] warn_slowpath_fmt+0x46/0x50
[    4.576178]  [&lt;ffffffffa00caca3&gt;] read_phy_reg+0x93/0xe0 [firewire_ohci]
[    4.576188]  [&lt;ffffffffa00cae19&gt;] ohci_read_phy_reg+0x39/0x60 [firewire_ohci]
[    4.576203]  [&lt;ffffffffa00731ff&gt;] fw_send_phy_config+0xbf/0xe0 [firewire_core]
[    4.576214]  [&lt;ffffffffa006b2d6&gt;] br_work+0x46/0xb0 [firewire_core]
[    4.576225]  [&lt;ffffffff81071e0c&gt;] process_one_work+0x13c/0x500
[    4.576238]  [&lt;ffffffffa006b290&gt;] ? fw_card_initialize+0x180/0x180 [firewire_core]
[    4.576248]  [&lt;ffffffff810737ed&gt;] worker_thread+0x16d/0x470
[    4.576257]  [&lt;ffffffff81073680&gt;] ? busy_worker_rebind_fn+0x100/0x100
[    4.576266]  [&lt;ffffffff8107d160&gt;] kthread+0xc0/0xd0
[    4.576275]  [&lt;ffffffff816a0000&gt;] ? pcpu_dump_alloc_info+0x1cb/0x2c4
[    4.576284]  [&lt;ffffffff8107d0a0&gt;] ? kthread_create_on_node+0x130/0x130
[    4.576297]  [&lt;ffffffff816b2f6c&gt;] ret_from_fork+0x7c/0xb0
[    4.576305]  [&lt;ffffffff8107d0a0&gt;] ? kthread_create_on_node+0x130/0x130
[    4.576313] ---[ end trace cbc940994b300302 ]---

[Stefan R:  Peter also reports a change of behavior with LSI FW323.
Before the patch, there would often occur a lock transaction failure
during firewire-core startup:
[    6.056022] firewire_core 0000:07:06.0: BM lock failed (timeout), making local node (ffc0) root
This failure no longer happens after the patch, without an obvious
reason for the failure or the fix.]

[Stefan R:  Added quirk flag, quirk table entry, and comment.]

Reported-by: Tim Jordan &lt;tim@insipid.org.uk&gt;
Signed-off-by: Peter Hurley &lt;peter@hurleysoftware.com&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
<entry>
<title>firewire: ohci: fix VIA VT6306 video reception</title>
<updated>2013-04-28T21:36:44+00:00</updated>
<author>
<name>Andy Leiserson</name>
<email>andy@leiserson.org</email>
</author>
<published>2013-04-24T16:10:32+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=be8dcab942e1c0ec2aa13eb2af2a79ab51b46293'/>
<id>urn:sha1:be8dcab942e1c0ec2aa13eb2af2a79ab51b46293</id>
<content type='text'>
Add quirk for VT6306 wake bit behavior.

VT6306 seems to reread the wrong descriptor when the wake bit is
written. work around by putting a copy of the branch address in the
first descriptor of the block.

[Stefan R:  This fixes the known broken video reception via gstreamer
on VIA VT6306.  100% repeatable testcase:
$ gst-launch-0.10 dv1394src \! dvdemux \! dvdec \! xvimagesink
with a camcorder or other DV source connected.  Likewise for MPEG2-TS
reception via gstreamer, e.g. from TV settop boxes.
Perhaps this also fixes dv4l on VT6306, but this is as yet untested.
Kino, dvgrab or FFADO had not been affected by this chip quirk.
Additional comments from Andy:]

I've looked into some problems with the wake bit on a vt6306 family
chip (1106:3044, rev 46).

I used this firewire card in a mythtv setup (ISO receive MPEG2 stream)
with Debian 2.6.32 kernels for ~2 years without problems.

Since upgrading to 3.2, I've been having problems with the input stream
freezing -- input data stops until I restart mythtv (I expect closing
and reopening the device would be sufficient). This happens
infrequently, maybe one out of 20 recordings. I eventually determined
that the problem is more likely to occur if the system is loaded.

I isolated the kernel version as the triggering SW factor and then
specifically the change from dualbuffer back to packet-per-buffer DMA
mode.

The possibility that the controller does not properly respond to the
wake bit was suggested in
https://bugzilla.redhat.com/show_bug.cgi?id=415841, but not proven.

Based on the fact that dualbuffer mode worked while packet-per-buffer
has trouble, I guessed that upon seeing the wake bit written, the vt6306
controller only checks the branch address in the first descriptor of the
block, even if that is not the correct place to look (because the block
has multiple descriptors).

This theory seems to be correct. When the ISO reception is hung, I am
able to resume it by manually writing the branch address to the first
descriptor in the block, and then writing the wake bit.

I've had luck so far with the attached patch, so I'm including it. It's
probably not a complete solution -- I haven't tested transmit modes to
see whether they have a similar issue.

I doubt that the quirk test is any cheaper than just writing the extra
branch address in all cases, but it does reduce the risk of breaking
other hardware.

[Stefan R:  omitted QUIRK_NO_MSI from VT6306 quirks table entry,
changed whitespace]

Signed-off-by: Andy Leiserson &lt;andy@leiserson.org&gt;
Signed-off-by: Stefan Richter &lt;stefanr@s5r6.in-berlin.de&gt;
</content>
</entry>
</feed>
