Skip to content

L
linux
Switch branch/tag
  1. 05 Jan, 2017 2 commits
  3. 04 Jan, 2017 4 commits
    • Takashi Iwai's avatar
      ALSA: vx: Don't try to update capture stream before running · ed3c177d
      Takashi Iwai authored 
      The update of stream costs significantly, and we should avoid it
unless the stream really has started.  Check pipe->running flag
instead of pipe->prepared.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ed3c177d
    • Takashi Iwai's avatar
      ALSA: vx: Fix possible transfer overflow · 874e1f6f
      Takashi Iwai authored 
      The pseudo DMA transfer codes in VX222 and VX-pocket driver have a
slight bug where they check the buffer boundary wrongly, and may
overflow.  Also, the zero sample count might be handled badly for the
playback (although it shouldn't happen in theory).  This patch
addresses these issues.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=141541Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      874e1f6f
    • Takashi Iwai's avatar
      ALSA: hda - Fix deadlock of controller device lock at unbinding · ab949d51
      Takashi Iwai authored 
      Imre Deak reported a deadlock of HD-audio driver at unbinding while
it's still in probing.  Since we probe the codecs asynchronously in a
work, the codec driver probe may still be kicked off while the
controller itself is being unbound.  And, azx_remove() tries to
process all pending tasks via cancel_work_sync() for fixing the other
races (see commit [0b8c8219: ALSA: hda - Cancel probe work instead
of flush at remove]), now we may meet a bizarre deadlock:

Unbind snd_hda_intel via sysfs:
  device_release_driver() ->
    device_lock(snd_hda_intel) ->
      azx_remove() ->
        cancel_work_sync(azx_probe_work)

azx_probe_work():
  codec driver probe() ->
     __driver_attach() ->
       device_lock(snd_hda_intel)

This deadlock is caused by the fact that both device_release_driver()
and driver_probe_device() take both the device and its parent locks at
the same time.  The codec device sets the controller device as its
parent, and this lock is taken before the probe() callback is called,
while the controller remove() callback gets called also with the same
lock.

In this patch, as an ugly workaround, we unlock the controller device
temporarily during cancel_work_sync() call.  The race against another
bind call should be still suppressed by the parent's device lock.
Reported-by: default avatarImre Deak <imre.deak@intel.com>
Fixes: 0b8c8219 ("ALSA: hda - Cancel probe work instead of flush at remove")
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ab949d51
    • Kailang Yang's avatar
      ALSA: hda/realtek - Add new codec ID ALC299 · 28f1f9b2
      Kailang Yang authored 
      ALC299 was similar as ALC225.
Add headset support for ALC299.
ALC3271 was for Dell rename.
Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      28f1f9b2
  5. 03 Jan, 2017 6 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 337ccfce
      Takashi Iwai authored
      337ccfce
    • Takashi Sakamoto's avatar
      ALSA: dice: ensure transmission speed for transmitted packets · b0e159fe
      Takashi Sakamoto authored 
      As of kernel 4.10, ALSA dice driver is expected to be used in default
speed. In most cases, it's S400. While, IEEE 1394 specification describes
the other speed such as S800.

According to 'TCD30XX User Guide', its link layer controller supports
several transmission speed up to S800[0]. In Dice software interface,
transmission speed in output direction can be configured by asynchronous
transaction to 'TX_SPEED' offset in its address space. S800 may be
available.

This commit improves configuration of transmission unit before starting
packet streaming for this purpose. The value of 'max_speed' in 'fw_device'
data structure has available maximum speed decided in bus arbitration,
thus it's within capacity of the unit.

[0] TCD3xx User Guide - TCAT 1394 LLC, Revision 0.9.0-41360 (TC Applied Technologies, May 6 2015)
http://www.tctechnologies.tc/index.php/support/support-hardware/dice-iii-detailed-documentationSigned-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b0e159fe
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: change structure member with proper type · 6b7e95d1
      Takashi Sakamoto authored 
      The 'amdtp_stream' structure is initialized by a call of
'amdtp_stream_init()'. Although a parameter of this function is for bit
flags of packet attributes, its type is enumerator.

This commit changes the type so that it's proper for a bit flags.
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6b7e95d1
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: Fix to handle error from initialization of stream data · 6a2a2f45
      Takashi Sakamoto authored 
      This module has a bug not to return error code in a case that data
structure for transmitted packets fails to be initialized.

This commit fixes the bug.

Fixes: 35efa5c4 ("ALSA: firewire-tascam: add streaming functionality")
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6a2a2f45
    • Takashi Sakamoto's avatar
      ALSA: fireworks: fix asymmetric API call at unit removal · e2eb31d7
      Takashi Sakamoto authored 
      ALSA fireworks driver has a bug not to call an API to destroy
'cmp_connection' structure for input direction. Currently this causes no
issues because it just destroys 'mutex' structure, while it's better to
fix it for future work.

Fix: d23c2cc4 ("ALSA: fireworks/bebob/dice/oxfw: allow stream destructor after releasing runtime")
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e2eb31d7
    • Takashi Sakamoto's avatar
      ALSA: oxfw: add support for Mackie Onyx 1640i · 03abd33a
      Takashi Sakamoto authored 
      As of kernel 4.10,  ALSA OXFW driver has no entry for Onyx 1640i produced
by Mackie (Loud Technologies). This commit supplement it.

I note that there're two models produced by Mackie (Loud Technologies),
which have the same name 'Onyx 1640i'. The former model based on OXFW970,
the latter model based on Dice. This is probably due to low quality of
communication of OXFW series.

Additionally, the tester reports his or her experiences to get unexpected
result at higher sampling transmission frequency as 88.2/96.0 kHz. We
didn't have further investigation yet[0].

$ ./linux-firewire-utils/src/crpp < config_rom
               ROM header and bus information block
               -----------------------------------------------------------------
400  042525ce  bus_info_length 4, crc_length 37, crc 9678
404  31333934  bus_name "1394"
408  20ff5003  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 5 (64)
40c  000ff205  company_id 000ff2     |
410  00000fcf  device_id 0500000fcf  | EUI-64 000ff20500000fcf

               root directory
               -----------------------------------------------------------------
414  0006c1b7  directory_length 6, crc 49591
418  03000ff2  vendor
41c  8100000a  --> descriptor leaf at 444
420  17001640  model
424  81000011  --> descriptor leaf at 468
428  0c0083c0  node capabilities per IEEE 1394
42c  d1000001  --> unit directory at 430

               unit directory at 430
               -----------------------------------------------------------------
430  00040b97  directory_length 4, crc 2967
434  1200a02d  specifier id: 1394 TA
438  13010001  version: AV/C
43c  17001640  model
440  81000010  --> descriptor leaf at 480

               descriptor leaf at 444
               -----------------------------------------------------------------
444  0008a886  leaf_length 8, crc 43142
448  00000000  textual descriptor
44c  00000000  minimal ASCII
450  4c6f7564  "Loud"
454  20546563  " Tec"
458  686e6f6c  "hnol"
45c  6f676965  "ogie"
460  7320496e  "s In"
464  632e0000  "c."

               descriptor leaf at 468
               -----------------------------------------------------------------
468  00059fcf  leaf_length 5, crc 40911
46c  00000000  textual descriptor
470  00000000  minimal ASCII
474  4f6e7978  "Onyx"
478  20313634  " 164"
47c  30690000  "0i"

               descriptor leaf at 480
               -----------------------------------------------------------------
480  00059fcf  leaf_length 5, crc 40911
484  00000000  textual descriptor
488  00000000  minimal ASCII
48c  4f6e7978  "Onyx"
490  20313634  " 164"
494  30690000  "0i"

[0]: [FFADO-user] Mackie 1640i issues (finer details)
https://sourceforge.net/p/ffado/mailman/message/35229260/Tested-by: default avatarSeth O'Bannion <saobannion@gmail.com>
Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      03abd33a
  7. 01 Jan, 2017 2 commits
    • Linus Torvalds's avatar
      Linux 4.10-rc2 · 0c744ea4
      Linus Torvalds authored
      0c744ea4
    • Linus Torvalds's avatar
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · 4759d386
      Linus Torvalds authored 
      Pull DAX updates from Dan Williams:
 "The completion of Jan's DAX work for 4.10.

  As I mentioned in the libnvdimm-for-4.10 pull request, these are some
  final fixes for the DAX dirty-cacheline-tracking invalidation work
  that was merged through the -mm, ext4, and xfs trees in -rc1. These
  patches were prepared prior to the merge window, but we waited for
  4.10-rc1 to have a stable merge base after all the prerequisites were
  merged.

  Quoting Jan on the overall changes in these patches:

     "So I'd like all these 6 patches to go for rc2. The first three
      patches fix invalidation of exceptional DAX entries (a bug which
      is there for a long time) - without these patches data loss can
      occur on power failure even though user called fsync(2). The other
      three patches change locking of DAX faults so that ->iomap_begin()
      is called in a more relaxed locking context and we are safe to
      start a transaction there for ext4"

  These have received a build success notification from the kbuild
  robot, and pass the latest libnvdimm unit tests. There have not been
  any -next releases since -rc1, so they have not appeared there"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  ext4: Simplify DAX fault path
  dax: Call ->iomap_begin without entry lock during dax fault
  dax: Finish fault completely when loading holes
  dax: Avoid page invalidation races and unnecessary radix tree traversals
  mm: Invalidate DAX radix tree entries only if appropriate
  ext2: Return BH_New buffers for zeroed blocks
      4759d386
  9. 30 Dec, 2016 2 commits
  11. 29 Dec, 2016 2 commits
    • Olof Johansson's avatar
      mm/filemap: fix parameters to test_bit() · 98473f9f
      Olof Johansson authored 
       mm/filemap.c: In function 'clear_bit_unlock_is_negative_byte':
  mm/filemap.c:933:9: error: too few arguments to function 'test_bit'
    return test_bit(PG_waiters);
         ^~~~~~~~

Fixes: b91e1302 ('mm: optimize PageWaiters bit use for unlock_page()')
Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
Brown-paper-bag-by: default avatarLinus Torvalds <dummy@duh.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      98473f9f
    • Linus Torvalds's avatar
      mm: optimize PageWaiters bit use for unlock_page() · b91e1302
      Linus Torvalds authored 
      In commit 62906027 ("mm: add PageWaiters indicating tasks are
waiting for a page bit") Nick Piggin made our page locking no longer
unconditionally touch the hashed page waitqueue, which not only helps
performance in general, but is particularly helpful on NUMA machines
where the hashed wait queues can bounce around a lot.

However, the "clear lock bit atomically and then test the waiters bit"
sequence turns out to be much more expensive than it needs to be,
because you get a nasty stall when trying to access the same word that
just got updated atomically.

On architectures where locking is done with LL/SC, this would be trivial
to fix with a new primitive that clears one bit and tests another
atomically, but that ends up not working on x86, where the only atomic
operations that return the result end up being cmpxchg and xadd.  The
atomic bit operations return the old value of the same bit we changed,
not the value of an unrelated bit.

On x86, we could put the lock bit in the high bit of the byte, and use
"xadd" with that bit (where the overflow ends up not touching other
bits), and look at the other bits of the result.  However, an even
simpler model is to just use a regular atomic "and" to clear the lock
bit, and then the sign bit in eflags will indicate the resulting state
of the unrelated bit #7.

So by moving the PageWaiters bit up to bit #7, we can atomically clear
the lock bit and test the waiters bit on x86 too.  And architectures
with LL/SC (which is all the usual RISC suspects), the particular bit
doesn't matter, so they are fine with this approach too.

This avoids the extra access to the same atomic word, and thus avoids
the costly stall at page unlock time.

The only downside is that the interface ends up being a bit odd and
specialized: clear a bit in a byte, and test the sign bit.  Nick doesn't
love the resulting name of the new primitive, but I'd rather make the
name be descriptive and very clear about the limitation imposed by
trying to work across all relevant architectures than make it be some
generic thing that doesn't make the odd semantics explicit.

So this introduces the new architecture primitive

    clear_bit_unlock_is_negative_byte();

and adds the trivial implementation for x86.  We have a generic
non-optimized fallback (that just does a "clear_bit()"+"test_bit(7)"
combination) which can be overridden by any architecture that can do
better.  According to Nick, Power has the same hickup x86 has, for
example, but some other architectures may not even care.

All these optimizations mean that my page locking stress-test (which is
just executing a lot of small short-lived shell scripts: "make test" in
the git source tree) no longer makes our page locking look horribly bad.
Before all these optimizations, just the unlock_page() costs were just
over 3% of all CPU overhead on "make test".  After this, it's down to
0.66%, so just a quarter of the cost it used to be.

(The difference on NUMA is bigger, but there this micro-optimization is
likely less noticeable, since the big issue on NUMA was not the accesses
to 'struct page', but the waitqueue accesses that were already removed
by Nick's earlier commit).
Acked-by: default avatarNick Piggin <npiggin@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Bob Peterson <rpeterso@redhat.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Andrew Lutomirski <luto@kernel.org>
Cc: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b91e1302
  13. 28 Dec, 2016 8 commits
  15. 27 Dec, 2016 14 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7